(anybody else unable to post to users@ from certain accounts?) Sylvain Wallez schrieb:
>> >> 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. > > Agreed, maybe except (4) - AJAX is all about making the client more complex. Could we think of submitting a form like doing a Web-Service call ? All data will be validated by the web service anyway, but the more I make sure it is valid *before* submitting, the less latency ... Of course this means code duplication, but it adds value in user experience IMHO. Is (1) actually on the developer's roadmap ? >> >> 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. > > Agreed, although "inputs" and "buttons" might be defined more loosely - i'd say "a group of UI elements designed to produce a set of closely related input" >> >> 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? > > I think I got your point. Morevorer, In an AJAX application, many forms might be already preloaded in the background, without actually being used until the user "activates" them (e.g. by selecting a menu item). It would be certainly impractical to define all those "input areas" in one single CForms definition. Of course we could emulate such behaviour now by placing each form in a seperate IFrame ... but the more critical point is the "multi"-interaction tracking as you pointed out. It does not fit the classical, linear interaction model of flow script well. Users might type some input in one area, try to submit, get a validation error, but then switch to another area. We should be able to track each input area seperately ... but this is the kind of work I would now move to the client, for a lack of better ideas, and since it somehow feels like UI logic to me. But if there was a way to use CForms in a service-call-like fashion, (e.g. call form rendering service, which returns xhtml you can place in a div - call validation service - call data update service which implies validation service - and so on), as such somehow decoupling the form object form interaction flow, this would still seem nice to me ... Regards, Johannes --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
