cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mratl...@collegenet.com
Subject Re: [Announcement] XMLForm 0.8.2 released
Date Thu, 16 May 2002 21:20:10 GMT

Hello,

Let's say I have an instance data node called MOTHERS_STREET_ADDRESS.  I want to
create a constraint that says these characters are illegal:  ^ # *( ), but these
are ok . (period) @ &.  The xf:caption of the xf:textbox is "Street"

I would like to write rule that looks like:
      <rule context="/MOTHERS_STREET_ADDRESS">
            <assert><value-of select="xf:caption"/> contains an illegal
character.</assert>
      </rule>

AFAIK, "normal" Schematron implementation would produce "Street contains an
illegal character."  But XMLForm is vaidating against the data model, not the
form description, so there is no <xf:caption> child to get the <value-of>.

I thought this was big problem last night at 2:30 AM, but now I think I just
need to get more sleep :-)   Why not assert "contains an illegal character" and
have some downstream xslt "violation template" append the proper <xf:caption>,
or whatever else is needed .  Duh!   Of course, each UI widget might have to
invoke a different violation template...

A lesser problem:  I want a more detailed message than "contains an illegal
character."  This message leaves the user wondering "which character is
illegal?"  Period? Ampersand?, Number-sign (#)?.  I wish there were a way to
produce:
      Street cannot contain a "#" or "Street cannot contain a "^";  or Street
cannot contain a "("  etc.
without resorting to:
      <assert test="not(contains(.,'*')">Street cannot contain an asterisk
(*)</assert>
      <assert test="not(contains(.,'^')">Street cannot conatain a caret
(^)</assert>
      <assert test="not(contains(.,'(')">Street cannot contain a parenthesis "
("</assert>...etc.
which would become very tedious with a large number of exceptions.

But this is maybe asking too much of Schematron?

<snip>
>If we make ai18n-enabled form then this approach can be a problem as we
>should have translations for all the possible cases and values. Haven't yet
>time to investigate the possibilities better, but I think that one can use
>dictionary keys instead of a real message, e.g.:

><rule context="/email">
>    <assert test="contains( string(.),'@')">
>        error.email.wrongformat
>    </assert>
></rule>
>
>and have a translation like this in dictionary:
><message key="error.email.wrongformat">Wrong email format. Email should look
>like {0}.</message>
>
>then have this in the form:
><i18n:translate>
>    <i18n:text><xf:violation ref="/email"/></i18n:text>
>    <i18n:param>user@hostname.com</i18n:param>
></i18n:translate>
>
>The other problem here would be to know what are the needed params for a
>particular case.
</snip>

Didn't get the part about "needed params".  Haven't had time to study the i18n
stuff yet, but all this looks *very* cool.

Cheers,
--Michael



                                                                                         
                 
                      "Konstantin                                                        
                 
                      Piroumian"               To:       <cocoon-dev@xml.apache.org>
                      
                      <kpiroumian@apach        cc:                                    
                    
                      e.org>                   Subject:  Re: [Announcement] XMLForm 0.8.2
released         
                                                                                         
                 
                      05/16/02 04:50 AM                                                  
                 
                      Please respond to                                                  
                 
                      cocoon-dev                                                         
                 
                                                                                         
                 
                                                                                         
                 




Hi!

From: <mratliff@collegenet.com>
>

I'd like to comment on this:

>
> Do you plan to support Schematron <report> element?  Would make it easier
to
> write rules like "/foo is invalid if it contains any of the following
> characters: #, &, *, %",  or "/foo may contain only digits 0-9 and decimal
> point".
>
> Is there any way to implement Schematron <name> and <value-of> elements?
Since
> XMLForm validates against instance data rather than the entire form
description,
> I don't see how it can retrieve this sort of context.  Still, it would be
nice
> to be able to write rules like this:
>       <name ref="../xf:caption> cannot contain <value-of select
> ="/some/xpath/expression">
> to produce a violation like this:
>       "Street Name cannot contain a "$"

If we make ai18n-enabled form then this approach can be a problem as we
should have translations for all the possible cases and values. Haven't yet
time to investigate the possibilities better, but I think that one can use
dictionary keys instead of a real message, e.g.:

<rule context="/email">
    <assert test="contains( string(.),'@')">
        error.email.wrongformat
    </assert>
</rule>

and have a translation like this in dictionary:
<message key="error.email.wrongformat">Wrong email format. Email should look
like {0}.</message>

then have this in the form:
<i18n:translate>
    <i18n:text><xf:violation ref="/email"/></i18n:text>
    <i18n:param>user@hostname.com</i18n:param>
</i18n:translate>

The other problem here would be to know what are the needed params for a
particular case.

Regards,
  Konstantin

>
> Cheers,
> --Michael
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org






---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message