Michael,
Why don't you consider donating some of your "twisted" examples to the
mount/xmlform sitemap?
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 17, 2002 4:16 AM
Subject: Re: [Announcement] XMLForm 0.8.2 released
>
> 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.
That was the reason why I've opted to replace the original xslt based
implementation
with a java version. Kudos to Dmitri and his JXPath.
> 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.
Exactly. That's the gist of Schematron. Start easy and grow on demand.
> 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.
Agreed. Heidi is writing a Howto document, which I can't wait to commit.
> 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.
Very curious to see these "tricks".
>
> 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).
Silly me.
>
> >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.
Understood. I have an idea how to refactor the implementation and patch it
back in.
Will send a notification when ready.
>
> 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?
Actually the displayText will have to be in the model in order for the
repeat to match the checkboxes correctly to their labels.
>
> >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" !
True.
We can use the multi box tag as a reality check for introducing such
controls within the framework vs. custom implementations.
>
> <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).
Agreed. Point taken.
>
> >> 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...
Good point.
I was thinking that when you want to highlight the association, you would
place the violations near the
failing fields.
Will consider an implementation which preserves the document order.
>
> >> 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've tested it a bit but maybe there is a bug. Feel free to save XMLForm
again :)
The implementation is one line, so I can't immediately see where the problem
might be.
>
> 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?).
Strange. Not intentional. Maybe another bug that waits to be busted.
Thanks for all your cooperation,
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]
