Re: tapestry critique

>1. I find it awkward that component parameters have to be repeated with 
>every page/component that uses that component, even if the

You can use Tapestry component composition to solve this problem. In the 
case of a menu (or any Shell-like components) that appears on every page, 
you can take a generic "menu bar" component, and compose it into an 
application-specific "menu bar" component that knows how to find the state 
it needs to present itself. In this case, the application-specific parent 
component would have the binding that ultimately goes back to the engine 
class and so you can use this specialized component on every page without 
having to specify any parameters for it. In essence, the Component carries 
it's own parameters.

Joseph Panico
[email protected]




>From: Christian Sell <[email protected]>
>To: Tapestry-Developer <[email protected]>
>Subject: [Tapestry-developer] tapestry critique
>Date: Sun, 15 Dec 2002 14:22:28 +0100
>
>Hello,
>
>I have finally managed to get my first little evaluation to run, and would 
>like to share some of my findings about tapestry so far. Let me first 
>briefly describe my program:
>
>I use the border menu component from the examples, and nest a calendar 
>component inside. By this, I wanted to test creating a component and using 
>it in a nested context.
>
>Now to my findings/suggestions:
>
>1. I find it awkward that component parameters have to be repeated with 
>every page/component that uses that component, even if the parameters are 
>always the same. In the case of the border menu component mentioned above, 
>this becomes very obvious: It has 3 menu items, which are always the same 
>(in fact, they are determined statically). Yet, on every page which uses 
>this component, I have to repeat the parameters that set the menu items. In 
>the Tapestry examples this is done with a binding that goes back to the 
>engine class, which returns a static array with the item names.
>
>That is obviously totally redundant. There should not be 3 places where the 
>border menu is configured, and it should not have to call into the engine 
>class via reflection to get a statically defined list of values.
>
>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.
>Also, there should be a way to configure static lists, like:
>
><static-binding name="menu">
>   <list>
>     <item>Item 1</item<
>     <item>Item 2</item>
>   </list>
></static-binding>
>
>
>2. I find handling persistent state overly complex. I can accept the 
>fireObservedChange call, but why the detach()? Why doesnt the framework 
>simply associate the java object with the session as soon as persistent 
>state is registered, and otherwise re-instatiate it for every call? I am 
>pretty sure that pooling simple java objects, like those implementing 
>tapestry components, is a total waste and a lot less efficient than just 
>re-instantiating (not to mention the burden put on the developer).
>
>3. This is already being addressed, as Howard wrote earlier: handling those 
>3 files (HTML, JWC and Java) can get extermely tedious, and in many cases 
>there is no value gained.
>
>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/
>_______________________________________________
>Tapestry-developer mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/tapestry-developer


_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963



-------------------------------------------------------
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/