Konstantin,
How do you manage to be working on so many things, pal?
I could only focus efficiently at one thing at a time.
Definitely want to put some work in Forrest and the CallBackHandlers, but to
be sure that the Form Handling gets done, I can only focus on it.
> Not at all. Thank you for your work.
> I've been concentrating on Cocoon release and i18n and JSP samples/docs,
so
> I hadn't time even to see latest updates to Forrest. Now when release is
> issued (with non-working JSP samples and outdated i18n docs!) I had time
to
> look at your sample.
Thanks!
> > > That's great!
> >
> > Did you have a chance to look at the new demo?
>
> Yes, although I didn't go deep into the source.
Going through the examples source, should be enough for you to understand
the principles.
Looking at the actual impl of the Binder and Validator won't be of much
interest to you or the future users.
> > I like your XSLT!
>
> Me too ;)
Now that you've agreed to extend it, I like it even better ;)
> It was just a sample of how a form in XForms markup can be displayed, but
I
> tried to keep it rather generic forseeing the need for overriding. The
most
> custom template is 'group' template as I remember, you can override it to
> generate a custom layout (I have attached a sample for that: groups are
> presented with 'div's and not tables). Colors can be customized by CSS
(it's
> embedded now, but I will move it to an external file).
Great! Make that next step !
> Error messages layout
> is a little more complicated thing. Customizing it will require
duplication
> of templates for all the input fields.
Actually I think this may not be so big of an issue:
Remember the format of a validationResult that is generated by the
Validator. It is a JavaBean and can be easily inserted in the SAX stream as
my 2nd demo shows ?
<validationResult>
<pattern name="Name fields">
<rule context="firstname">
<assert test="str-length(.) > 0">Firstname is required</asserrt>
...
</rule>
...
</pattern name>
Now from your xform:
<input ref="firstname">
<!--- You can use the ref as a xsl select against the validationResult:
/validationResult/pattern/rule[context="$ref"] to find Reports or Asserts
which failed -->
<caption>First name</caption>
<hint>Your first name</hint>
<isValid>false</isValid> <!--- then you can
populate this -->
<!-- and also one of these for each assert/report -->
<message type="info" class="Report | Assert">
<xsl:value-of select="assert"><!-- Firstname is required-->
</message>
</input>
If you do this, then all that's left to the user is to figure how to
customize the rendering of the XForm markup.
How do you like this?
>
> Although as soon as I have a little free time I'll concentrate on your
> application to make it look a little better and more real-life. What about
a
> wizard for customer registration?
> Scenario:
> - Enter Personal Info (name, date of birth)
> - Enter Contact/Address Info (phone(s), address)
> - Confirm registration (a page, that displays all the entered
> information and two buttons 'Confirm' and 'Cancel')
> - A success/error pages
I think this would be great for a first iteration. Just add a 3rd input page
for some feedback:
- How did you learn about Cocoon?
- Was the installation experience good ?
- What problems do you expect Cocoon to help you resolve?
Once we get this done, we can extend it more.
>
> User should be able to navigate forward and back between first two forms
and
> cancel the process in every state (except, of course, success page).
Yes.
<next> on the first page
<previous> <next> <cancel> on the following pages
<previous> <finish> <cancel> on the last input page
<previous> <cancel> on the confirmation page
> Actions, events and validation would be possible on the client side if
> JavaScript had XPath/XML capabilities, but implementing it (even a
> simplified version) would require a lot of time and I gave it up, although
> you can see some hooks for 'relevant' attribute in my sample. Try to
change
> instance data to make car info relevant and you'll get according fields
> enabled.
>From digging through the archives, previous projects like Schemox,
Exformula, etc. probably failed because they targeted full server-side
implementation of XForms. That's why I prefer an iterative approach,
starting with things which we absolutely thing should be in. Then wait for
people to ask for more.
> Microsoft IE (5.0+) has built-in ActiveX for DOM parsing and maybe XPath
> evaluation with JavaScript, but it's too browser specific, although it's a
> great feature.
Correct. By the time we finish integrating/testing with IE5, Mozilla will
probably implement XForms.
Not worth it.
> I'll further my work on that (although, I can be back to my paid work at
any
> time and I don't want to leave unfinished stuff).
We're all on the same train.
> > Another fundamental problem is nested and overlapping forms.
>
> What is the practical use for nested or overlapping forms? I can
understand
> 'nested' as a sub-set of fields that can be submitted independently (I
think
> this can be achieved with 'relevant' attribute or 'submitInfo'
descriptor),
> but what are 'overlapped' forms?
XForms allows input fields for a form to be scattered everywhere on the
screen.
They don't have to be all under one <form> tag. So you can end up with
<form1field>
<form2field>
<form1field>
<form2field>
Well you can't do that with HTML, can you?
> In XForms specification I haven't seen any 'form' element, all field
> grouping is processed using 'group' and 'submitInfo' elements. So, did I
get
> you right, that the question is 'how do we generate HTML forms based on
> XForms markup'?
Sorry for being unclear.
I know you have no problems rendering XForms to HTML.
I just wanted to prevent problems with generated HTML which overlaps forms.
<form action="survey">
<form action="login">
<input type="text" name="username"/>
</form>
<input name="age">
</form>
Which form does the username field belong to?
> > So to summarize: XForm markup is good for uniformness. XForm Actions,
> > Events, validation and nesting should be left out for the
> > days when clients
> > will support those.
>
> Agree. We'll try to implement everything that is possible on the server
> side.
Glad to have you onboard !
Starting with the minimum and doing one iteration at a time.
Frequent releases so people can evaluate and give feedback often.
> > With the Schematron libs we now have, we're pretty well
> > covered with server
> > side validation, don't you think?
>
> If it supports dependecy checks then 'yes'. An example: is it possible to
> implement such a validation rule "validate 'car-model' required field only
> if the user indicated that he owns one (has set 'has-car' field to true)"?
Yes. Short answer: test="not(../has-car) | model"
Schemattrin was designed to solve this kind of problems and fill in the
holes in XML Schema.
I would strongly enourage you to read Rick's interview on xmlhack.com if you
haven't already:
http://www.xmlhack.com/read.php?item=121
This is a possible markup for your problem:
<shchema>
<phase id="firstpage">
<active pattern="userbasic"/>
<active pattern="carinfo"/>
</phase>
... other phases
<pattern name="Car info validation" id="carinfo">
<rule context="customer/car-info">
<assert test="not(../has-car) | model">Car model is required</assert>
... more asserts & reports on car-info
</rule>
.. more rules ...
</pattern>
... more patterns
</pattern>
</schema>
Does this help?
> So, let's start work on a web app now! Your work fills me with enthusiasm
;)
Your enthusiasm makes me work ; )
Cheers,
Ivelin
>
> Regards,
> Konstantin
>
> >
> >
> > Cheers,
> >
> > Ivelin
> >
> >
> >
> >
> >
> >
> > > > I would also like to encourage readers to see Torsten's code
> > > > and share their
> > > > thoughts on how they'd like to see form binding/validation
> > > > done in Cocoon.
> > > > As the general lesson of live states, if you want to see
> > > > something done in a
> > > > way you like, say it !
> > >
> > > Ok.
> > >
> > > Konstantin
> > >
> > > >
> > > > Ivelin
> > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, email: [EMAIL PROTECTED]
> > > >
> > >
> > >
> >
> >
> > --------------------------------------------------------------
> > --------------
> > ----
> >
> >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, email: [EMAIL PROTECTED]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
>
>
----------------------------------------------------------------------------
----
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
