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. 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 ... :) Regards, Johannes --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
