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