cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: [Announcement] XMLForm 0.8.2 released
Date Fri, 17 May 2002 05:29:47 GMT
Michael,


Thanks for hammering on XMLForm and sending more valuable feedback.


see below:

----- Original Message -----
From: <mratliff@collegenet.com>
To: <cocoon-dev@xml.apache.org>
Sent: Thursday, May 16, 2002 4:49 AM
Subject: Re: [Announcement] XMLForm 0.8.2 released


>
> Ivelin,
>
> I am having problems writing Schematron rules for multiple-select widgets.
For
> example, imagine you have an <xf:selectMany ref="/color"> widget which
presents
> as a set of four checkboxes whose captions are "red", "blue", "green", and
"
> yellow".  You want to write two validation rules 1) At least one color
must be
> selected and 2) No more than two colors may be selected.

As a side note, you may consider using a radio button group.

You might not have noticed, but I have patched XMLForm to support selectMany
for multiple select controls,
but not for a set of checkboxes. It seemed like a set of checkboxes cannot
be universally rendered because of the layout issue you pointed out (which
side of the box to place the text).
Additionally a multi check box selection can be rendered with xf:repeat. For
example:

<xf:repeat nodeset="/color">
  <xf:selectBoolean ref="selected"/>
  <xf:output ref="displayText"/>
</xf:repeat>

Provided that you have a collection of Color objects with 2 attributes:
selected: boolean and
displayText: String

The sample markup can be transformed in whatever layout is desired and it
has a predictable serialization to html.

If there is a strong demand though, we will add selectMany with checkbox
option.


>
> The only way that seems to work is:
>       <rule context="/">
>             <assert test="color[1]='red' or color[1]='blue' or
color[1]='green'
> or color[1]='yellow'">
>                   At least one color must be selected.
>             </assert>
>       </rule>
>       <rule context="/">
>             <assert test="color[3]=''">No more than two colors may be
> selected.</assert>
>       </rule>
>
> (Hereafter "global violation set" refers to the <violation ref=...> tags
> generated whenever a <violations/> element is *outside* of an xf widget;
"local
> violation set" refers to the <violation> tags generated whenever a
<violations/>
> element is *inside* of an xf widget.)
>
> PROBLEMS:
>       1)  the context of these rules is "/", so @ref in global violation
set is
> ""
>       2)  violations appear only in the global violations set and *not*
in the
> local violations set within the <xf:selectMany>.  There seems to be a
problem in
> XMLFormTransformer.java, startElementViolations method.  This line:
>       if ( !currentRef.equals (nextViolation.getPath () ) ) break
> is intended to insure that only <violation> elements matching the
containing
> context element are generated.  However in the case of the example given
above,
>       currentRef="/color"
>       nextViolation.getPath()="/color[1]"
>
> This is only a problem with <xf:selectMany>.  All other xf widgets
correctly
> generate violations in both the global violation set and the local
violation
> set.
>
> QUESTIONS:
> Is there some better way to write these rules?

If you the example above suites your needs. The rules can be rewritten to:

  <rule context="/">
       <rule context="/">
             <assert test="count(color[selected='true'])=1">Exactly one
color must be
 selected.</assert>
       </rule>

This is a global rule which applies for all nodes and logicly belongs to the
global context.
If you need a rule that is specific for each color, then we can think of a
local color context.

>
> Is there a problem with the way selectMany is put on the Entry stack?  Or
is it
> the value getPath() is returning?

This is another inherent issue with the way multiple checkboxes are
rendered.
Consider using a multi select list or the example above.
If neither works, let me know, so we can discuss an appropriate
implementation for selectMany with checkboxes.

>
> Is there a compelling reason to use a SortedSet for violations?  (cursory
> examination of code suggests "yes", but...).  Global violations end up
sorted
> alphabetically.  Makes it difficult to display them in document order (the
> "natural" order IMHO).

The driving force was that it is easy to enumerate all violations related to
a node when they are kept in a sorted set. Another option was a map, however
map is not always needed.

>
> 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".

Report is supported. Report is simply a negation of assert.

>
> 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 "$"

You should be able to use xml markup withing the assert and then transform
it into the actual node value.

<assert >cannot contain <myns:name/> </assert>

<xsl:template map="violation"/>
    <xsl:call-template name="replace-name" with violation ref or whatever
you like...
</violation>


Hope this helps. Let me know if I missed your point.


Cheers,

Ivelin




>
> 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


Mime
View raw message