On 8/20/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
>
> That's close to my opinion.
>
> I appreciate how people would like to create a new component on the
> fly, and I understand the use cases involving that.
>
> However, it goes against the grain of Tapestry. I've finally
> documented this, the concept of static structure and dynamic behavior.
>
> Once you allow "some" pages to have a different structure but the same
> name, much of what Tapestry is capable of doing is thrown away. It
> can't cache effectively, it can't operate in a cluster effectively.
> There's so much going on in the design that says "if I know the page
> name, I can trust that the structure is identical" even when its a
> different page instance and a different server in the cluster.
But my opinion is the Page concept is not good enough. For me the main
concept in Component (actual ComponentPageElement)
If I can cache a Page why I can't cache a Component ?
I think it's very important that Tapestry store as little as possible
> in the session. The new in T5 redirect-after-action pattern does force
> you to store more data in the session (with huge benefits, and the
> option to store on the client instead) so there's a bit of a
> compromise going on. However, doing as Wicket and JSF and storing big
> chunks of page structure in the session (necessary to support runtime
> dynamic page structure) is something I'm fundamentally opposed to,
> given that there are quite satisfactory solutions, based on blocks and
> other structures.
For me the first target of Tapestry should be to focus on users concern and
actually Ajax
is the new way to build large web application. Maybe Seams is not "cluster
ready"
due to the use of Conversation through Statefull Session Bean but it resolve
users concern.
When I manipulate some concepts (in this case the two concept of Page and
ComponentPageElement)
and my feeling is "humm it's seems to me very close concept" so I try to
find an other way to express my concept.
So in my humble opinion I think the main concept is the EventManager, Ajax
web application need to be driven by an event bus.
So some use cases :
1 - Start Page use case
User send request -> no event -> T5 generate a default event : call
Start Component -> Start Component is rendered.
My Start component is like the actually page with html template and sub
component.
2 - Simple Page use case
User send request -> with event call:MyPageTwo (who is in fact a
component) -> MyPageTwo Component is rendered.
2 - Simple Ajax call
User send a request -> with event call:myCompnent -> if myComponent is
not in the cache it's created (like a page actualy).
My component is rendered like the actually page.
What some crazy things can I do with that ?
A node substitution on a html page :
I call a NodeSubstitutionComponent -> the component is created and
cached after that is rendered.
This component contain other component and is main function is to
encapsulate the html return in, for example, a json call like :
{execute: function() {Ext.DomHelper.createTemplate('" +
SubComponentsRendering+ "').overwrite( Ext.get('" +
idOfMyComponentOrPreviousComponent + "'));}}";
3 - Another Ajax call
User send a request on a component with and event
The event is propaged only on the targeted Component
4 - Complex Ajax call
User send only a event. Tapestry transmit the event though all the
registered component for this event.
We can make complex case with this approach make ordered render
response, trigger some other inter component event....
So "voila" my 2 cents on the debat, Ajax web application have few pages and
many components so keep Page as central in T5
maybe will be an handicap for the futur !
