Howard M. Lewis Ship <hlship <at> comcast.net> writes: > Basically, I want to effectively eliminate the rewind cycle. No more > false rendering.
This is probably a silly question, but why woud you like to eliminate the rewind cycle? Or rather, what problem are you trying to solve? > As components render, they will register a submit-time callback. The > callback identifies the component (i.e., ComponentAddress) and allows an > additional arbitrary object to be stored as well. Somehow, integrated > into this, will be code in the Form to re-tell the fields what their > element name is. In other words, new method on IFormComponent and IForm. It sounds like a DirectLink. Why not store the field name in that arbitrary object and let the form field (if it is one) extract it without bothering the Form? Then the Form is only responsible for deseralizing the callbacks and then call them without having to deal with the differences between form field components (eg, TextField) and non-form field components (eg, For). If I understand your proposed solution correctly, it may have an interesting effect on how a FieldLabel may work. It can find a way to register its callback after the form field component registers its. > I suspect that volatile For's will still register callbacks with the Form > for each iteration, but the callback will be a bit different. To check for errors? > If components will no longer need any interaction with the enclosing Form. I see this is a benefit of the proposed solution. Are there others? > I believe that there will no longer be the possibility of a > StaleLinkException. The situations that may cause StaleLinkExceptions > today may cause NPEs under this scheme. The For and If components are already taking care of that today. Am I missing something? > For my day contract, I'm starting to look a > jWebUnit ... I hope to find a way to merge jWebUnit tests with > Tapestry's mock servlet container. That would be an optimum solution! I am with Jesse here: I'd also recommend HtmlUnit over HttpUnit (or a derivative like jWebUnit). Its code is cleaner and its developers are much more responsive. I've been using it to unit test my pages with fair success. The only wish I have is to be able to run the app and Tapestry code in the same process of the client. This will allow JUnit's AssertionFailedError to go back to the JUnit Test Runner which can then show the location of the failure clearly. Now it will be caught by Tapestry and return an Exception page to the test client and the location info is lost. I'm sure it is possible to run the HtmlUnit WebClient in the same process as the server because that's how the unit tests for HtmlUnit itself are executed. -- Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
