Inline - but keep in mind what i would really like to discuss here is if the radio components should extend from AbstractField. The details for supporting zone parameter in AbstractFields should be discussed in separate thread.
On Wed, Aug 17, 2011 at 00:17, Denis Stepanov <denis.stepa...@gmail.com> wrote: > Not all form fields support zone update, Out of scope, but i hasten to add that i've already got that to work >TextField doesn't What do you mean? Why not update a zone on change? Or on key press? > and Radio shouldn't too, I mentioned about Radios, that's why i'm ok with them not being AbstractFields. But in either case [see next] > all radios will be binded by the RadioGroup and because of that it can't use > an abstract JS init. If the client code is smart enough, this doesn't really matter - it'll be handled for you. > > By adding the zone parameter to the AbstractField you are forcing all > subclasses to implement it and in some cases it just doesn't makes sense. No subclass needs to change, all work happens inside AbstractField > > Just commit my patch and I will then add support for the RadioGroup. :) Your patch is ok - it's basically a copy of the Select code that did the same thing - but what i'd like to do is investigate how to further improve on that. One way is by generalizing and reusing (instead of copy&pasting) and the other relates to reusing AbstractField#processSubmission (that's what really allows impementing this without touching subclasses) > > Denis > -- Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr Apache Tapestry PMC / http://chesstu.be owner Open Source / JEE Consulting --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
