----- Original Message -----
From: "Christian Sell" <[EMAIL PROTECTED]>
To: "Tapestry-Developer" <[EMAIL PROTECTED]>
Sent: Sunday, December 15, 2002 8:22 AM
Subject: [Tapestry-developer] 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.
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.
> 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>
>
You can accomplish this using OGNL syntax:
<binding name="menu" expression='{ "Item 1", "Item 2" }'/>
(But check me, that's off the top of my head). OGNL is very good at create
lists ... it even has "slicing" operations to extract a subset of a list
(using a predicate function!).
>
> 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).
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).
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.
>
> 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.
There's value gained in both cases. On the one hand is ease of adoption for
new users, especially those who need to escape the "templates 'n scripting"
mindset. On the other hand is keeping the presentation separate from the
logic (very useful when HTML and Java are done by separate teams).
Tapestry will give you the choice, allowing you to mix and match to your
comfort level.
----
Howard Lewis Ship
[EMAIL PROTECTED]
http://tapestry.sf.net
>
> 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
>
-------------------------------------------------------
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
