You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by James Sherwood <js...@rgisolutions.com> on 2006/06/13 18:41:15 UTC
Can dynamic tapestry be done?
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@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Can dynamic tapestry be done?
Posted by ZedroS Schwart <ze...@gmail.com>.
Thanks for the precisions, I see better the difference now.
Cheers,
ZedroS
On 6/14/06, James Carman <ja...@carmanconsulting.com> wrote:
>
> JSP pages are not really the same type of beast as Tapestry pages. JSP
> pages are compiled into servlet classes and a single instance (unless
> otherwise specified) of the servlet class is used to serve client
> requests.
> Remember, JSPs are just short-hand for writing plain ole' servlets. All
> other rules about writing servlets apply.
>
> -----Original Message-----
> From: ZedroS Schwart [mailto:zedros.schwartz@gmail.com]
> Sent: Wednesday, June 14, 2006 5:19 PM
> To: Tapestry users
> Subject: Re: Can dynamic tapestry be done?
>
> Just a side question about Tapestry's pooling : normal jsp pages are, as
> far
> as I understand it, pooled as well. The jsp is compiled once and then is
> used for all the access to this page.
>
> I don't know exactly the behaviour of jsp page when there are multiple
> concurrent access, so I may not spot where the poolable parf of Tapestry.
> Could you please provide more info ?
>
> Thanks in advance
> ZedroS
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Can dynamic tapestry be done?
Posted by Howard Lewis Ship <hl...@gmail.com>.
JSPs are compiled into singleton objects.
Individual JSP tags are individually pooled. Thus for a given request, a
single JSP servlet will be invoked (possibly by multiple threads), but
individual threads will store transient state within per-thread instances of
the JSP tag objects.
Take a peek at the code generated by a typical JSP container. Eeeks!
There's a lot of code in there to extract tag objects from pools, initialize
them from their attributes, use them (within deeply nested try/catch
blocks), then reset and return them to their pool.
This is an area where Tapestry has a big performance advantage, IMHO.
There's lots of opportunity for Tapestry components to cache data,
especially the kind of invariant data from literal and message parameter
bindings.
On 6/14/06, ZedroS Schwart <ze...@gmail.com> wrote:
>
> Just a side question about Tapestry's pooling : normal jsp pages are, as
> far
> as I understand it, pooled as well. The jsp is compiled once and then is
> used for all the access to this page.
>
> I don't know exactly the behaviour of jsp page when there are multiple
> concurrent access, so I may not spot where the poolable parf of Tapestry.
> Could you please provide more info ?
>
> Thanks in advance
> ZedroS
>
>
--
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
RE: Can dynamic tapestry be done?
Posted by James Carman <ja...@carmanconsulting.com>.
JSP pages are not really the same type of beast as Tapestry pages. JSP
pages are compiled into servlet classes and a single instance (unless
otherwise specified) of the servlet class is used to serve client requests.
Remember, JSPs are just short-hand for writing plain ole' servlets. All
other rules about writing servlets apply.
-----Original Message-----
From: ZedroS Schwart [mailto:zedros.schwartz@gmail.com]
Sent: Wednesday, June 14, 2006 5:19 PM
To: Tapestry users
Subject: Re: Can dynamic tapestry be done?
Just a side question about Tapestry's pooling : normal jsp pages are, as far
as I understand it, pooled as well. The jsp is compiled once and then is
used for all the access to this page.
I don't know exactly the behaviour of jsp page when there are multiple
concurrent access, so I may not spot where the poolable parf of Tapestry.
Could you please provide more info ?
Thanks in advance
ZedroS
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Table sorting issue
Posted by Matt Walsh <mw...@schnucks.com>.
Currently, the tables example provided by John Reynolds
(http://weblogs.java.net/blog/johnreynolds/archive/2004/10/learn_by_teachi_1.html) has a bug where a user can enter an invalid field, then click a column header to resort the table. Once submitted, the validation kicks in, but the table is sorted with the wrong values highlighted. Is there a way to not sort unless validation is okay?
______________________________________________________________________
The information transmitted (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is intended only for the person(s) or entity/entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Can dynamic tapestry be done?
Posted by ZedroS Schwart <ze...@gmail.com>.
Just a side question about Tapestry's pooling : normal jsp pages are, as far
as I understand it, pooled as well. The jsp is compiled once and then is
used for all the access to this page.
I don't know exactly the behaviour of jsp page when there are multiple
concurrent access, so I may not spot where the poolable parf of Tapestry.
Could you please provide more info ?
Thanks in advance
ZedroS
Re: Can dynamic tapestry be done?
Posted by Jesse Kuhnert <jk...@gmail.com>.
Then what Mike suggested (perhaps with some dynamic css selection as
well...it's still pretty powerful - even for changing page layout ) sounds
like the best option.
Break your page up into definable quadrants/sections/whatever you want to
call them. Ie SectionA-E ...In each section use a RenderBlock as previously
suggested to ask your page layout component which item should be rendered
for this particular layout.
It will still be pretty damn performant unless your method of determining
which thing gets rendered in each block is overly slow. (Hard to imagine
that would be the case).
On 6/13/06, James Sherwood <js...@rgisolutions.com> wrote:
>
> I dont have to keep track of the components as they are always the same, I
> just want to change where they are in the html and the html itself to give
> the page a different look according to which site layout they choose.
>
>
> James
>
> ----- Original Message -----
> From: "Jesse Kuhnert" <jk...@gmail.com>
> To: "Tapestry users" <us...@tapestry.apache.org>
> Sent: Tuesday, June 13, 2006 6:10 PM
> Subject: Re: Can dynamic tapestry be done?
>
>
> > Wouldn't it be easier to do something like this by changing the
> stylesheet
> > on the fly instead?
> >
> > Even if you did have dynamic component stuff somehow I still wouldn't
> want
> > to maintain something like that....or maybe it's a requirement you don't
> > have a choice in ?
> >
> > On 6/13/06, James Sherwood <js...@rgisolutions.com> wrote:
> >>
> >> 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" <hl...@gmail.com>
> >> To: "Tapestry users" <us...@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 <js...@rgisolutions.com> 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: users-unsubscribe@tapestry.apache.org
> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > 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: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > Jesse Kuhnert
> > Tacos/Tapestry, team member/developer
> >
> > Open source based consulting work centered around
> > dojo/tapestry/tacos/hivemind.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
Re: Can dynamic tapestry be done?
Posted by James Sherwood <js...@rgisolutions.com>.
I dont have to keep track of the components as they are always the same, I
just want to change where they are in the html and the html itself to give
the page a different look according to which site layout they choose.
James
----- Original Message -----
From: "Jesse Kuhnert" <jk...@gmail.com>
To: "Tapestry users" <us...@tapestry.apache.org>
Sent: Tuesday, June 13, 2006 6:10 PM
Subject: Re: Can dynamic tapestry be done?
> Wouldn't it be easier to do something like this by changing the stylesheet
> on the fly instead?
>
> Even if you did have dynamic component stuff somehow I still wouldn't want
> to maintain something like that....or maybe it's a requirement you don't
> have a choice in ?
>
> On 6/13/06, James Sherwood <js...@rgisolutions.com> wrote:
>>
>> 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" <hl...@gmail.com>
>> To: "Tapestry users" <us...@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 <js...@rgisolutions.com> 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: users-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > 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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Jesse Kuhnert
> Tacos/Tapestry, team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Can dynamic tapestry be done?
Posted by Jesse Kuhnert <jk...@gmail.com>.
Wouldn't it be easier to do something like this by changing the stylesheet
on the fly instead?
Even if you did have dynamic component stuff somehow I still wouldn't want
to maintain something like that....or maybe it's a requirement you don't
have a choice in ?
On 6/13/06, James Sherwood <js...@rgisolutions.com> wrote:
>
> 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" <hl...@gmail.com>
> To: "Tapestry users" <us...@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 <js...@rgisolutions.com> 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: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
Re: Can dynamic tapestry be done?
Posted by Mi...@expeditors.com.
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" <js...@rgisolutions.com>
06/13/2006 06:08 PM
Please respond to
"Tapestry users" <us...@tapestry.apache.org>
To
"Tapestry users" <us...@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" <hl...@gmail.com>
To: "Tapestry users" <us...@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 <js...@rgisolutions.com> 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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Can dynamic tapestry be done?
Posted by James Sherwood <js...@rgisolutions.com>.
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" <hl...@gmail.com>
To: "Tapestry users" <us...@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 <js...@rgisolutions.com> 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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Can dynamic tapestry be done?
Posted by Jesse Kuhnert <jk...@gmail.com>.
Could it be that people are trying to force an external sense of design from
another system before understanding how this one works?
For example, you mention not being able to create links to wiki pages.
If I were tasked with such a thing, I would probably create a "component"
with a "page" parameter. You could store your wiki page content however you
liked, all you have to do is find the best method for your uses and make the
component serve it up.
Or, are there other requirements needed that I've not understood?
On 6/14/06, Stephen Todd <st...@agilestudios.com> wrote:
>
> 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 <st...@agilestudios.com> 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 < jsherwood@rgisolutions.com> 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: users-unsubscribe@tapestry.apache.org
> > >> For additional commands, e-mail: users-help@tapestry.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > 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
>
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
Re: Can dynamic tapestry be done?
Posted by adasal <ad...@gmail.com>.
That must be possible.
You can write HiveMind so that is expects a componant defined in a module
but can cope with the situation when it is not present, probably with some
dummies. Part of the trick would be to use quartz in a repetative process so
that the app will find a new or extended config. I think at the point of
change there would have to be an automatic restart, though.
You would have to know that what you append is suitable using a test
environment.
(I think something like this is right?)
But if you really mean on the fly then I would have thought there are things
that can be done w.r.t. typing and AOP. AOP would recognise unknown sub
types, those that you define "on the fly" - what ever you mean by that. You
would have to define what is done with these unknown types.
So far you have not been very specific as to what your requirement really
is.
Adam
On 14/06/06, Stephen Todd <st...@agilestudios.com> wrote:
>
> 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 <st...@agilestudios.com> 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 < jsherwood@rgisolutions.com> 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: users-unsubscribe@tapestry.apache.org
> > >> For additional commands, e-mail: users-help@tapestry.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > 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
>
>
>
RE: Can dynamic tapestry be done?
Posted by James Carman <ja...@carmanconsulting.com>.
It sounds like what you want is a portal. So, why not use a portal?
-----Original Message-----
From: Stephen Todd [mailto:stephen@agilestudios.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
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 <st...@agilestudios.com> 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 < jsherwood@rgisolutions.com> 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: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Can dynamic tapestry be done?
Posted by Stephen Todd <st...@agilestudios.com>.
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 <st...@agilestudios.com> 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 < jsherwood@rgisolutions.com> 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: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > 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
Re: Can dynamic tapestry be done?
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <st...@agilestudios.com> 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 <js...@rgisolutions.com> 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: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > 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
Re: Can dynamic tapestry be done?
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <js...@rgisolutions.com> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
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