Re: 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?

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.


> 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!).

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/