JSF is having scalability problems because they don't use the
static structure model.
There are other approaches.
For example, if you have multiple skins, you could incorporate the
skin name into the page name.
To be honest, I prefer Jesse's approach of supporting skins
primarily by changing stylesheets. That's incredibly powerful.
Much of what Tapestry offers is based on it having a "map" of the
application; this map is the names of pages, and the ids of
components within pages (often nested within other components).
This map is how Tapestry bridges from the concept of actions to the
concept of components ... because a limited number of actions have
the ability to "name" pages and components to operate upon.
On 6/14/06, Stephen Todd <[EMAIL PROTECTED]> wrote:
Howard,
I didn't want to start another debate on the list but I wanted to ask
personally. Could another solution be to also pool components in the
same way that pages are pooled? Then store a proxy for the component
tree such that the component is pulled from the pool when asked for
from the proxy. You could have a special proxy that allowed for the
component to be selected at run time based on the name of the
component. If the component wasn't loaded, this might incur a one
time setup cost, but you are going to have that some time anyway.
To me, it would seem that the additional cost would be increased from
going by reference to searching through a short list of components
and then getting an object from the pool. You could separate this
into the special case proxy class so that the performance loss would
be localized to the dynamic component.
I might have made some huge assumptions here, but sometimes the
mantra around here of "dynamic content, static structure" makes it
sound like the developers are stuck in a paradigm. I hope you don't
take that personally because I realize I am not as intimately
familiar with the code and I don't have much time right now to
contribute (though I would like to). I am impressed with the
framework and think its great — I just want it to be better.
We are all busy, so I will understand if you don't want to explain.
There definitely isn't enough time for you to answer everyone's
concerns about each design decision.
Thanks,
Stephen
On Jun 13, 2006, at 2:39 PM, Howard Lewis Ship wrote:
> This goes against the grain of Tapestry.
>
> Here's some copy from the new Tapestry 5 web site (not yet
> available) that
> conveys the reasoning behind this:
>
> Tapestry is designed to be extremely scalable in several dimensions:
>
> - Tapestry applications may contain many pages and many custom
> components.
> - Tapestry applications may contain very complex functionality.
> - Tapestry applications may be created by large, diverse teams.
> - Tapestry applications can service large numbers of concurrent
> users.
>
> One core architecture decision in Tapestry exists to service many
> of the
> above goals (and others that are harder to describe). *Static
> Structure,
> Dynamic Behavior*
>
> In Tapestry, the structure of any particular page is *static*.
This is
> necessary for several reasons, most importantly because Tapestry
> pages are *
> pooled*. Creating and Tapestry page is an involved process, because
> the page
> object is simply the root of a large tree of other objects
> including user
> provided components, many kinds of structural objects, template
> objects, and
> others. Creating a new page instance for each request is simply
not *
> scalable*.
>
> Instead, Tapestry *pools* pages. Once created, a page instance
will be
> stored in a pool for that particular type of page, and reused in
later
> requests. An incoming request, the result of a user clicking a
link or
> submitting a form, will be processed by *some* server within a
> cluster, and
> will use *some* page instance within the page pool. Because page
> instances
> are static and uniform across instances and servers, Tapestry can
> use any
> available page instance, or create a new one as needed.
>
> Tapestry does not need to store page instances inside the
> HttpSession. At
> most, it stores a smattering of *persistent properties* of the page
> in the
> session, but not the entire page instance. This lean use of the
> HttpSession
> is key to Tapestry's very high scalability, especially in a
clustered
> configuration.
>
> In some Tapestry-like frameworks, such as Faces and Wicket, the page
> structure is more dynamic, at the cost of storing much, much more
> data in
> the HttpSession.
>
> This static structure is not so limiting as you might think. With
> different
> kinds of conditional and looping components, and the ability to
> "jump out of
> the flow" and render components in an arbitrary order, you will not
> find
> Tapestry to be rigid ... anything but!
>
>
>
>
> On 6/13/06, James Sherwood < [EMAIL PROTECTED]> wrote:
>>
>> This is the situation:
>>
>> I would like to create a page in such a way that the jwcid's in
>> the html
>> are
>> standard but I can produce the html any way I wish.
>>
>> To do this there would have to be a way to pass tapestry the html
>> of a
>> page
>> from a database for instance.
>>
>> Something to the effect of a <jwc id="insertTapestry"/> in a page
>> which
>> inserts the html and tapestry tags but the html tags and tapestry
>> tags
>> that
>> are inserted are still rendered by the engine.
>>
>> Is this possible?
>>
>> Thanks,
>> James
>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator and PMC Chair, Apache Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
