It sounds like what you want is a portal. So, why not use a portal? -----Original Message----- From: Stephen Todd [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 12:48 PM To: Howard Lewis Ship Cc: Tapestry users Subject: Re: Can dynamic tapestry be done?
My concern isn't so much about theming as it is to provide the ability to not have any idea of what component I might possibly use. I want to be able to drop in a jar that contains components into a certain folder and make the components available for use without having to write code( and maybe even without a restart). I want to be able to, for example, create a flexible system that has drop-in components (not in the tapestry sense, but in a systems sense) and be able to use those parts throughout the application just through live configuration. I think that the current setup excludes being able to make a wiki that has links to other pages. I need to be able to create components in a component on the fly. Stephen On Jun 14, 2006, at 10:34 AM, Howard Lewis Ship wrote: > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
