On 1/26/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > In case this was missed on the dev boards, I did put out a proposed solution > before today's new > discussion came up: > > http://issues.apache.org/bugzilla/show_bug.cgi?id=38374 > > It's for Struts 1.2.x. Is there a different approach that we should seriously > consider? Please say > so, and I will contribute a patch for this. > > The reason <set-property> was chosen is because it's identical to having a > parameter listed in the > DTD, functionaly speaking, except for DTD autocompletion.
I very much dislike changing the default behavior within a minor release or a milestone. But, if we can restrain the changes to the configuration, I suppose we could live with it. It does seem like the simplest solution, and at least the Java code and JSP would not change. I don't know if anyone is up for rolling a 1.2.9 release or not. I know I won't be able to do it. For a 1.2.9, I suppose the set-property thing would be OK. But for 1.3.0 it should be elevated to the DTD, and both ways of setting the property could be observed. In any case, we should not just ignore the cancel token. If the token is present, and Cancellable is not set, then we should log the error and throw an exception so that the developer knows the contract is not being observed (or that the website is being spoofed). If we just ignore it, there will be endless questions of why my cancel button doesn't work. An alternative to the exception might be to post a validation error, so that people have some clue of what is going wrong. In the patch, can shorten the property name to "Cancellable", with two l's (like NetBeans). We should also add a test case to the taglib-exercise application demonstrating that the patch works. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
