I could see the valid argument to ~not~ having it turned on by default. Perhaps a good compromise might be something such as Andreas suggested, allowing a global application property that turns it on/off for all forms.
The semantic details of what happens with client validation I would argue more strongly isn't something people should be opposed to as much. Even the current validation system sets a default for you that you can choose to override by defining your own Tapestry.default_invalid_field_handlerjavascript object. Maybe this too should be an application property? I was trying to brainstorm patterns for doing things like this. In dojo I've seen a few, one that sticks out is definining a javascript "class" string property of the object to create to handle whatever interface you are trying to get it to do. In this case we could have something along the same lines, where we create the default handler at runtime via new "classNameStr"() and use it. On 6/13/06, Andreas Andreou <[EMAIL PROTECTED]> wrote:
Perhaps we could have a place for globally configuring such defaults... So, <parameter name="clientValidationEnabled"> in Form.jwc could become <parameter name="delegate" default-value="componentConfigs:defaultClientValidationState"> In a similar way, the ajaxEnabled parameter of @Shell could be manipulated... Cliff Zhao wrote: > I'm afraid that I can not see the big benefit for introducing the > incompatible default. > > In my Tapestry application, I hooked up many javascript event handlers > to do > the business-related validating, formatting and styling. > > I like to keep the same default as before. > > Thanks. > > On 6/12/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: >> >> In its current form this seems somewhat understandable (ie alert >> dialogs), >> but is it in the realm of possibilities that we might be able to turn >> this >> on by default for 4.1? >> >> I've begun my overhaul of the client side stuff already and am hoping to >> come up with a default client side scheme that does UI related >> decorations >> on the form in question. >> >> Most of it is fairly simple to start with, fields with missing data have >> the >> css class fieldMissing applied to them , those with invalid data have >> fieldInvalid applied to them. In the demo TimeTracker application I've >> setup >> the fieldMissing/Invalid css styles to set the background of the input >> field >> to a certain color. (very light blue for missing - a sort of orange/red >> for >> invalid). >> >> I still have to figure out the hardest part - displaying error >> messages - >> but think it's doable. Thought I'd ask ahead of time as long as I >> remembered >> it. >> >> The existing system that Paul/Howard put in place actually fit in >> with the >> dojo way of validating things like a glove so it wasn't as hard as might >> have been expected :) Overriding the UI semantics of displaying >> validation >> error messages should also be pretty simple, this is what the current >> javascript "object" looks like that handles the default UI stuff: >> >> >> http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/framework/src/js/tapestry/form/validation.js?view=markup >> >> >> -- >> Jesse Kuhnert >> Tacos/Tapestry, team member/developer >> >> Open source based consulting work centered around >> dojo/tapestry/tacos/hivemind. >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
