Simplifying development using disposable Pages?

["MacLeod, Kenny" <Ke...@AIG.com>]

Folks,

Reading through the Tapestry Dev Guide as a relative newbie, it strikes me
that certain tasks the developer must perform would be rather error-prone,
leading to weird bugs.  For example, the need for a Page object to fire
persistent property events and implement detach() correctly.  In a large
team of variably-skilled developers, this seems like a whole host of bugs
just waiting to happen.

Apologies if I'm over-simplifying here, but this seems like a lot of effort
to achieve the pooling of Page instances.  Is Page pooling really that good
an optimisation?  Surely the overhead of instantiating and discarding Page
objects is not significant, compared to large number of objects instantiated
by the servlet container on each request?

If the Page object were not re-used, then there would be no need to detach()
correctly.  To take it further, the framework could automatically read the
persistent page properties at the end of the cycle, instead of requiring the
page recorder to be explicitly informed.  That would allow the develop to
write the Page as a simple bean, with no knowledge of the framework.  

Perhaps Tapestry could have a different Page type, which allowed you to
develop in this fashion?  The developer could pick and choose as they saw
fit.

I assume I'm making a bad assumption somewhere here, or that this issue has
been raised before (although there's nothing in the recent jakarta archive
about it), but it does seem odd considering the excellent usability of the
rest of the framework.

cheers
kenny

IMPORTANT NOTICE: 
The information in this email (and any attachments) is confidential. If you
are not the intended recipient, you must not use or disseminate the
information. If you have received this email in error, please immediately
notify me by "Reply" command and permanently delete the original and any
copies or printouts thereof. Although this email and any attachments are
believed to be free of any virus or other defect that might affect any
computer system into which it is received and opened, it is the
responsibility of the recipient to ensure that it is virus free and no
responsibility is accepted by American International Group, Inc. or its
subsidiaries or affiliates either jointly or severally, for any loss or
damage arising in any way from its use.