Perhaps you could create all the components on the screen and place them
in different div sections. You could then hide the ones you don't want
to see. I frequently do this. It means more processing on the submit,
but that's ok by me.
If you want to limit which components you see (with a post back to the
server) you could use RenderBlock to present custom components for each
submit.
- Mike
James Sherwood [EMAIL PROTECTED]
06/13/2006 06:08 PM
Please respond to
Tapestry users users@tapestry.apache.org
To
Tapestry users users@tapestry.apache.org
cc
Subject
Re: Can dynamic tapestry be done?
Thanks for the feedback,
This does, however, pose a problem for me.
I am building a site and I wish to make it diverse enough to change its
appearance with the 'flick of a switch'.
Is is possible then to create several border components and call a
different
one according to which site layout you have designated without using the
idea of:
jwc id=checklayout1
jwc id=insertBorderComponent1/
/jwc
but instead, using the idea:
jwc id=insertBorder/
where the insertBorder component used a different component dependant on
the
site layout?
Thanks,
James
- Original Message -
From: Howard Lewis Ship [EMAIL PROTECTED]
To: Tapestry users users@tapestry.apache.org
Sent: Tuesday, June 13, 2006 5:39 PM
Subject: Re: Can dynamic tapestry be done?
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
