It sounds like what you want is a portal. So, why not use a portal?
Message
From: Stephen Todd [mailto:stephen (AT) agilestudios (DOT) com]
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
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.
--
6/14/06, Stephen Todd <stephen (AT) agilestudios (DOT) comwrote:
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
--
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.
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. 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!
>
>
>
>
6/13/06, James Sherwood < jsherwood (AT) rgisolutions (DOT) comwrote:
>>
>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: users-unsubscribe (AT) tapestry (DOT) apache.org
>For additional commands, e-mail: users-help (AT) tapestry (DOT) apache.org
>>
>>
>
>