Michael,
Thanks for hammering on XMLForm and sending more valuable feedback.
see below:
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
