Re: tapestry critique

----- Original Message -----
From: "Christian Sell" <[email protected]>
To: "Howard M. Lewis Ship" <[email protected]>
Cc: "Tapestry-Developer" <[email protected]>
Sent: Sunday, December 15, 2002 1:36 PM
Subject: Re: [Tapestry-developer] tapestry critique


> >>Instead, there should be a way to configure components globally (in the
> >>application specification, or even optionally in an external, reusable
> >>file which can be included in the application specification. These
> >>definitions should be accessible to all pages (components?) in the
> >>application.
> >
> >
> > Since you are new to Tapestry, you are missing some of the subtleties.
> >
> > The Border component from the Tutorial exists, not to be reused, but to
> > demonstrate how you can use the RenderWrapped component to create a new
> > component that wraps around existing components, and not even have to
write
> > Java code to do it.
> >
> > In a real application, you might still have some form of  Border
component,
> > but it will be specific to your application.
> >
> > If you look at the Workbench, it does just that.  It has a Border
component
> > that provides the tabbed navigation across the top.  Because it is
specific
> > to the Workbench application, the pages within the application merely
used
> > the Border, without configuring it.  It figures out the rest from the
name
> > of the renderring page.
>
> I dont understand. Lets suppose I have a 3rd party library which gives
> me a component (e.g., a calendar) that is to be included on every page
> of my application. This component requires a few parameters which
> control the appearance. These are the same all across my app. Would I
> have to re-specify the component and parameters on every page?

Typically, you'll create a standard Border component for your application,
and configure the Calendar just once, inside your app-specific Border.
Every page that uses the Border gets the Calendar as well, configured
identically.


>
> And even if I tried to solve this with component composition, like
> Joseph Panico suggested, I would still have to create the new component,
> and add a reference in every page file using it. What I want to do is
> define/configure the component only once, and then reference it from
> HTML templates without having to add references to every jwc and page
file.
>
> Am I making sense?
>
> > Almost everything you see in a Tapestry specification page
specification,
> > its template, and the specifications and templates of embedded
components
> > turns into objects.  Objects to represent the static template, component
> > instances for the embedded components, objects to represent bindings,
> > assets, connected parameters.  In many cases, Maps are used so that
objects
> > can be retrieved by name or id.
> >
> > So, a page instance is the root of a complex, tangled tree.
> >
> > To reserve that tree of objects to a single session is problematic.
First,
> > there's the memory usage; each client will have its own copies of each
page
> > that is ever visited by the user ... that adds up (1000's of users X
dozens
> > of pages).
>
> Of course I am not talking about all the page data (HTML and all) - just
> about the java object that holds the state. That should be rather small
> - probably not bigger than the wrapper you have to create to maintain
> the state elsewhere. About serializablility - it seems totally
> reasonable to require/recommend that all non-persistent variables be
> declared transient, and all persistent ones be of serializable types.

In Tapestry, these two things merge together; so you don't talk about
"page.persistentState.myProperty", you just talk about "myProperty" or
"page.myProperty".

This is much  more natural, for me and most others I think, than to keep
them separate.  You need properties, you code accessor methods like any
other JavaBean.

But there are costs, as we've discussed.

>
>
> > More importantly, in a cluster environment, all server-side state must
be
> > Serializable, to allow it to be shared and moved between servers in the
> > cluster.  That means the page instances and everything within must be
> > serializable.  It also means the HttpSession will bloat (and large
> > HttpSessions are not handled well by most application servers).
> >
> > When you get down to it, few pages have more than one or two persistant
> > differences between HttpSession ... so Tapestry concentrates on those
tiny
> > differences rather than duplicating the whole enchilada.
> >
> > If you check on the Wiki, you'll see that this is one of the main areas
> > being investigated for 2.4.  There will be some kind of mechanism that
will
> > allow you to simply define, in your specification, which JavaBeans
> > properties are transient and which are persistant.  Tapestry will take
care
> > of the rest.  The current thinking is it will create a subclass, on the
fly,
> > that implements or overrides your accessor methods to take care of value
> > tracking, initialization, and cleanup.
>
> but if the (Java) page object is pooled, there would still have to be
> that detach() method, which would have to clean up all transient state
> variables, right? So the declaration you mention above would only take
> care of the fireObservedChange calls - which I said I dont mind at all.
> In fact I would rather keep coding them myself than have some subclass
> generated (reminds me of EJBs, yuck!).

You'll have the option, of course.  If you want Tapestry to generate the
correct methods in a subclass, you will need to specify your properties.
If you want to code initialize() and detach(), you can do that as you would
today.

>
> BTW, your statement in the other thread about the XML not being visible
> due to Spindle does not always hold - many people are not using
> Eclipse/Spindle, and some (like me) prefer editing the XML even then.
>
> regards,
> Christian
>
>



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/