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 18:42:16 GMT

Michael,

Why don't you consider donating some of your "twisted" examples to the
mount/xmlform sitemap?


----- Original Message -----
From: <mratliff@collegenet.com>
To: <cocoon-dev@xml.apache.org>
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: 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