Ivelin,
>Thanks for hammering on XMLForm and sending more valuable feedback.
Glad you understand I'm trying to help make XMLForm better. I plan to
be much more critical when I get caught up; I've been doing lots of
twisted things with XMLForm I haven't had time to discuss. Of course,
I wouldn't be expending all this effort if I didn't think XMLForm
was *very* cool:
1) Amazing, hard-to-believe, validation speed. Sometimes I
validate things just to watch it happen. Seems 5-10 times faster
than anything else I have used. Really, really fast.
2) Easy to learn Schematron rules. I'm not entirely convinced
Schematron is the total answer, but at least you can get validation
"up and running" with a minimum of effort.
3) Flexible, loosely coupled violation reporting. Presentation
component is just given a <violations> container and can decide for itself
what to do with its contents: display violations at top of the screen,
next to widget, inside a javascript alert, within a separate window, inside
a pop-up layer, etc, etc. Nice SoC.
4) Demo's well. This is more important than you would think
because of Cocoon's "unpolished" appearance, lack of documentation,
white papers, market "presence" etc. Non-techies aren't interested in
Cocoon's intellectual beauty. They just want to see impressive results.
5) Overall "potential". I mention this only because I have
been able to trick XMLForm into doing things you probably never intended
it to do. This makes me believe that other, more clever individuals
could develop XMLForm into a really complete forms solution. Sort of
a "critical app" for the web-application-server side of cocoon.
But all this is sort of OT...
>> 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.
I need a many-of-many selector. Radio button group is one-of-many (selectOne).
>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).
Yeah, didn't notice that. Don't think you can avoid implementing selectMany
as checkbox set. Almost none of our customers use multiple select listbox
for selectMany: they all use checkbox sets. And the reason is *because*
of the flexible (i.e., nightmarish) layout possibilities. You can arrange
checkbox sets horizontal or vertical, have lots of white-space or explanatory
text where needed, align them to arbitrary grids, etc, etc. The result is
that they convey information visually better than multiple-select lists.
But implementation is painful.
><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
Clever. But shouldn't this just be a collection of simple boolean objects?
You're not saying to put displayText (==caption?) in the data model are you?
>The sample markup can be transformed in whatever layout is desired and it
>has a predictable serialization to html.
Actually, anything that presents as a uncontained widget (a widget not in
its own bounding box) creates layout issues. So select list, multiple
select-list,
textarea, and textbox are pretty easy to deal with, because each has its own
bounding rectangle circumscribing the content. But all radio-button sets,
checkbox
sets, or boolean widgets have layout issues because they can be rendered in
so many ways. I have seen radio buttons arranged every which way; same with
checkboxes. Even booleans: "click here to toggle foo" where widget may be
above, below, right, or left of caption, and seperated from caption
by arbitrary amount of "white space" !
<snip />
>If you the example above suites your needs. The rules can be rewritten to:
>
> <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.
I understand your argument about this being a global rule, but I don't entirely
agree. The rule is not about a relationship among completely unrelated instance
nodes. The nodes are part of one logical group (and are often presented as
such).
So a rule that says "CLASS_RANK must be <= CLASS_SIZE" I see as "global" because
1) two different instance nodes and 2) not possible to decide whether to display
the violation message near CLASS_RANK widget or near CLASS_SIZE widget. But
checkbox
group is often a logical and visual unit, so even though there *may* be
different
instance nodes, it is usually possible to decide where to display violation
message.
Which is just what I want to do:
<xf:selectMany selectUIType="checkboxGroup">
<xf:item>...</xf:item>
<violations class="error" />
</xf:selectMany>
It seems to me that I should be able to bind a "violations" container to this
widget
without regard to its presentation style (selectUIType).
>> 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.
Thought it might be something like that. But I have this beautiful form wherein
all errors are displayed in a nicely formatted section at top of page. Each
violation message serves as a link which 1) takes user right to the place on the
form where the error occurred, 2) selects the contents of the widget, and 3)
places
the text-insert cursor at the appropriate location. Trouble is, everybody I
have
showed this to expects list of error messages to be in *document* order: they
don't
understand why they are in alphabetical order. If you retained document order,
user could apply <xsl:sort> to impose any order they wish: once you destroy
the original ordering information there is no going back...
>> Do you plan to support Schematron <report> element? Would make it easierto
>> 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.
Just double checked this again. Report doesn't work for me. This works:
<assert test="contains(not(.,'$'))">
but this doesn't:
<report test="contains(.,'$')">
I realize report is just not(assert). But sometimes it is more clear to describe
what should *not* be in a field than what *should* be in a field. Like "any char
but one of {!,@,#,$,%,^,&,*,(,),_,+.=,-.}" You may also wish to use *both*
assert
and report, for example /PHONE must *include* {0,1,2,3,4,5,6,7,8,9} and
*exclude*
"555" in chars 1-3 (No U.S. phone numbers begin with a "555" exchange).
Does <report> work for you?
>>
>> Is there any way to implement Schematron <name> and <value-of> elements?
<snip/>
>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>
This would be *great* !! But unfortunately, doesn't work for me. Thought it
might be because I my tags didn't have their own namespace so I tried:
<assert test=".!=''">Please provide a <cnet:some_tag /></assert>
but the <some_tag> element just gets stripped out (by the validation
transformer?).
Cheers,
--Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
