Johannes Textor wrote:
Sylvain Wallez schrieb:
I disagree with the statement that Ajax makes CForms obsolete. Even
with Ajax, you still need to input some data, validate it and relate
it to back-end data.
Now the way we interact with forms will change, and rather than
filling everything and submitting to see what is wrong, we will want
validation to happen on the fly.
[snip]
by sending individually input to the server for validation each time
it has changed. A prototypic Google-suggest like autocompletion is
also available in the SVN since last week.
OK but this means one client-server interaction each time some input is
changed - and what about more complex multi-field dependencies that are
difficult to treat even with the current CForms framework ? Many people
are "hacking" these things on top of the CForms validation definitions.
Hacking? Is it hacking to use what the framework allows you to do? I
mean CForms is built to allow custom validators that are related to some
specific business data that lives outside the form.
Maybe there should be at least the option to move validation to the
client - with scripts that are generated from the CForms def. but
executed on the client side, without client/server trips. When something
incorrect is then submitted to the server by an AJAX client, is it
unsafe to assume that a) the client is playing foul or b) there is a
programming error in the client ?
Some validations can be moved on the client-side. There are a number of
different kinds of validations:
1 - individual syntactic/format validations (e.g. number / date / regexp)
2 - individual semantic validations (e.g. checking that a purchase order
id actually exist in the database)
3 - simple inter-field validations (e.g. the classical password/confirm
password fields or start-date < end-date)
4 - complex inter-field validations
5 - complex validations involving several fields and back-end data
1 can be easily moved on the client. It's merely about writing a JS
library that understands the type definition and format that is already
produced in the form instance.
2 must happen on the server but can happen whenever the widget value
changes.
3 can happen on the client.
4 could happen on the client, but is IMO better done on the server to
avoid complex client-side processing and code duplication between (i.e.
a JS and a Java implementation of the validator)
5 obviously happens on the server.
Continuations still have an important role to play, as they track user
interaction through a set of "screens" (let just not call them pages,
as the interaction can occur in an area of the page). Now what will
change with Ajax is that you may have several continuations running
concurrently in a single page, possibly interacting.
The same here, I think what you suggest is one way of design, but some
people (like me) might want to move user interaction tracking to the
client. I see the necessity for *sessions*, but when a multi-screen user
interaction takes place without a client/server trip at each step, what
is then the role of continuations ?
I think we have two different design paradigms in mind, maybe I'm
over-simplistic but let me illustrate mine by the classic "calculator" -
example that illustrated continuations in the Cocoon samples.
We need 2 numbers and an operand. The "calc" sample used 3 screens for
this scenario. This would correspond to 3 CForms. A continuation would
take track of the input made so far. If at any stage you'd input
nothing, CForms validation would not let you through.
Now an AJAX approach might be to actually render a calculator on the
screen, with buttons that look like real buttons, and the first number
disappearing when you enter the second, but stored in memory to perform
the actual calculation - then when clicking "=", the numbers (keep in
mind the first one is no longer on the screen!) alongside with the op
are sent to the server, the calc is performed there, the result returned.
- Generate CForms definition for 2 values + 1 op. alongside with
validation info
- Do whatever you want on the client (might come from a form template,
might be something else) that in the end submits those values to the server
- Provide JS Function for validation to the client
- Reject invalid input
I know this is not how it's supposed to be - I should better create a
template and then write a complicated stylesheet that does the trick of
there just being one input field on the screen which corresponds to two
hidden fields which are the actual CForms fields - then convert the
"fd:validation-error" messages to whatever I need. But sincerely all
this work is what makes CForms so difficult for me to use, and
impossible to convince any of my colleagues to ever use it for some
straightforward "simple CMS"-type project we usually do. That's why I'm
looking for a "CForms light" approach, using AJAX as an excuse ... :)
I think we have to think about "pages" differently, and consider more
"input areas" that exist in the page. An input area is a group of
closely related inputs and buttons, and a page can contain several of
them, the various group having some looser relation.
Let's consider an example. In a CMS application, you may have an
htmlarea containing a document and some "dialogs" to add various things
in the document. Among them you can have a dialog for adding an image.
This is group of related fields, including the image path, an alternate
text and some optional width and height information. Now this group
impacts the document only when the group is valid. This mean that you
can have a form for the image dialog, and have the image actually added
to the document when the image form is fully validated.
So the Ajax model means a different approach to form definitions. Rather
than having large forms defining each and every possible imput on a
page, you will have smaller forms, invoked only when the "page" needs
them. That's what I meant with having several interaction flows running
concurrently withing the same page.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
