Friday, January 21, 2005

Persistent properties in Tapestry

Learned a couple things this week in Tapestry, one of which will require quite a bit of refactoring.

First, the LinkSubmit will solve many problems in the UI that the client requires. Up to this point we were planning on writing custom JavaScript to facilitate submitting a form from a hyperlink.

Secondly, I've misunderstood the Tapestry In Action book and have coded a couple pages wrong--which has been the cause of frustration and irritation in some of the behavior. My foul-up has been that I've coded all of the page properties as instance variables. My interpretation of the material in the book was wrong--I has presumed that page properties could be handled through Tapestry Page specification entries (.page file) or as members of the Page's class. Same presumption for Tapestry's handling of the variable.

Bad presumption.

Tapestry handles the two QUITE differently. In order for the client state to be preserved (between clients) Tapestry must *own* the property. That is, it must be declared in the .page specification and also be (to my experience thus far) an abstract value. This way, Tapestry manage the properties' persistence rather in the extended class that Tapestry manages. Otherwise, when the page is available in the pool, everyone shares the instance variables. That's where we began to notice strange things.

Next thing to figure out is initialization necessities (some properties will need to be initialized to different values according to some set of logic) and detachment (resetting the properties).

Overall, I think the refactoring will make the pages a bit more intuitive at first glance. And, it'll save space in the code where we (by necessity) need to define abstract methods purely for the use of other in-class routines. Thus making the page class abstract for Tapestry to manage the persistent properties *and * keeping our code to a minimum. Slick setup. Despite the learning curve and twisting my mind around the concept, kudos to the Tapestry team for developing such an efficient model.

Some links of clarification on the matter:
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)