tapestry critique

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/