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
