cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes Textor <>
Subject Re: AJAX and Cocoon - Design Patterns
Date Wed, 05 Oct 2005 09:51:27 GMT
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.


> 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.

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 ?

> 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 ... :)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message