[ http://issues.apache.org/jira/browse/TAPESTRY-599?page=comments#action_12320125 ]
Ron Piterman commented on TAPESTRY-599: --------------------------------------- I would still consider the following model, rather the one you already implemented in 20 minutes. When you define cancel, success, refresh aso, you define concrete events, instead of letting the programmer define its own. If you 1. create one listener: validate="listener:" which performs the rest of the validation 2. enable both submit and form listeners to perform optionally only if validation is ok, Than you have the same model as above, but less xml (which you should like) and a greater abstruction level, which means flexiblity. What you call "cancel","success" aso is actually a submit listener. which its call is dependant on validation. What you implemented is much like struts, but lucks the flexibility struts offers, making the complex of form listeners not so clear: when is success called? after the submit listener? after the form listener? so if I have 5 submits? all end with success? I don't really understand what for, and what is the separation target here. Also adding 4 new parameters to form? imo this is an overkill, and looses a needed abstruction level. > Form (and submit) Listeners to enable conditional call, dependant on the > form's delegate errors > ----------------------------------------------------------------------------------------------- > > Key: TAPESTRY-599 > URL: http://issues.apache.org/jira/browse/TAPESTRY-599 > Project: Tapestry > Type: Wish > Reporter: Ron Piterman > Fix For: 4.0 > > It would be great if Submit and Form listener methods will enable making the > method call conditional, dependant on the form's delegate validation errors > condition. > This will enable a further declarative behaviour, and a kind of conditional > chaining. > A Submit's listener can do further validation and perform an action. > A Form's listener can then do the page flow job, and will also (optionally) > only be called if the form has no validation errors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
