[Tapestry-developer] tapestry critique

[Christian Sell]

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