You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Jone.hwk" <jo...@yahoo.com.cn> on 2005/08/04 04:21:22 UTC
How to change templates on the fly in tapestry 4 ?
Hi,
Since tapestry rely on page template to render html,so is there a way to chang
templates on the fly?I tried rewriting the method in class TemplateSourceImpl,
and contruct the tempalate loading path based on user's setting,e.g
visit.getTemplatePathA(),visit.getTemplatePathB().However,it doesn't work,why?
Could anyone help me?
thanks in advance.
Jone.hwk
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: How to change templates on the fly in tapestry 4 ?
Posted by "Jone.hwk" <jo...@yahoo.com.cn>.
Thank you Todd,
In my project,I'd like to provide my customers choices to select their favorite
page templates set on the fly.For example,there are a seires of templates as
following:
[context]
templtes
aaa
login.html
view.html
go.html
.....
bbb
login.html
view.html
go.html
.....
ccc
login.html
view.html
go.html
.....
The visitors can store their selction in "visit",and in class
TemplateSourceImpl I rewrited the "loadTemplate()" to load selected favorite
tempate such as "aaa" or "bbb".There is no problem when first loading,but how
to apply the selected template on the fly is a big problem.I'v look into source
code,the getTemplate() method invoked only once when loading component.
Is there a way to go?
thanks in advance
Jone.hwk
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: How to change templates on the fly in tapestry 4 ?
Posted by Todd O'Bryan <to...@mac.com>.
Tapestry doesn't really use templates, per se. The HTML files you
write with Tapestry are very powerful and can include conditional
parts as well as components that are very customizable depending on
the current state of the application.
Rather than changing the HTML file on the fly, you probably want to
write a file that renders correctly based on the state of the
application. If you could tell us what exactly you're trying to do,
maybe we could explain more clearly...
Todd
On Aug 3, 2005, at 10:21 PM, Jone.hwk wrote:
> Hi,
> Since tapestry rely on page template to render html,so is there a
> way to chang
> templates on the fly?I tried rewriting the method in class
> TemplateSourceImpl,
> and contruct the tempalate loading path based on user's setting,e.g
> visit.getTemplatePathA(),visit.getTemplatePathB().However,it
> doesn't work,why?
> Could anyone help me?
>
> thanks in advance.
> Jone.hwk
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Best Practice (Hibernate, Spring, Tapestry)
Posted by Massimo Lusetti <ml...@gmail.com>.
On 1/11/06, Cosmin Bucur <co...@gmail.com> wrote:
> It just blows my mind , that Spring or Tapestry or Hivemind do not
> offer anything standard that can do this .
You're right that there's confusion but derived by people not looking
in the right direction.
HiveMind and Tapestry are not focused on offering integration with
Hibernate nor any other framework of any kind, HiveMind offers
infrastructure to build it up while Tapestry offer premium support for
build web app (which are not all backed up by a dbms, even not by
definition).
On the other side Spring offer smooth integration with Hibernate and i
find it fun that you can access Spring beans from Tapestry pages as
HiveMind services as easly as HiveMind 'native' services.
So i guess we have all the tools you need to do the job, just use them
as you think they should be used.
If you whant hints there're plenty of them just look for them, a good
kickstart is the newly released kickstart.sf.net which follow a patter
of this tools usage, if you don't like that pattern is up to you to
find another one or... write another one.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Best Practice (Hibernate, Spring, Tapestry)
Posted by Konstantin Ignatyev <kg...@yahoo.com>.
There is not much need to be Tapestry specific IMO.
This article describes good approach to Hibernate + Spring integration
http://www.onjava.com/pub/a/onjava/2005/05/18/swingxactions.html?page=1
Simpler solutions are possible too:
http://sandbox.sourcelabs.com/kosta/hb-beyond-hw/java/com/sourcelabs/hibernate/bhw/haop/doc/haop.html
Cosmin Bucur <co...@gmail.com> wrote: It just blows my mind , that Spring or Tapestry or Hivemind do not
offer anything standard that can do this .
Is such a common need , and it's such a common question , with so much
general confusion arround it .
I've been trying to get this working for a while . I find that most
documentation available is poor and confusing , mostly because it
never deals with the SPECIFIC combination : hibernate + spring +
tapestry .
Cosmin
On 1/11/06, Paul Cantrell wrote:
> The Hibernate folks are a lot more excited about long sessions and
> detached objects than I am. (It's hard not to get attached to a fun
> feature once you've implemented it!) Personally, I think they make
> the app harder to write: there's much more worrying about stale data
> and scalability. For many apps, caching give the same kinds of
> performance benefits with fewer programmer headaches and hidden
> concurrency issues.
>
> The session-per-request model is probably the simplest and easiest
> default to start with. I like to begin there, keeping in mind the
> other options, thinking carefully about where transaction boundaries
> need to be -- and then depart from session-per-request when specific
> situations require something different.
>
> Cheers,
>
> Paul
>
>
> On Jan 11, 2006, at 1:20 AM,
> wrote:
>
> > I just went thru Hibernate In Action (edition 1), chapter 8.2
> > (Implementing Application Transactions). This chapter talks about
> > the two options we talked about, and a third option: Long Session.
> >
> > It seems that "Hibernate in Action" recommends Long session on a
> > web application over other two. The next preferred option is
> > "Detached Persistent Object Strategy" (same as option 1 in my
> > original email).
> >
> > Will this new information change your opinions on these options?
> >
> > Thanks ....
> >
> > Shovon
> >
> > ----- Original Message ----
> > From: Patrick Casey
> > To: Tapestry users
> > Sent: Tuesday, January 10, 2006 6:40:29 PM
> > Subject: RE: Best Practice (Hibernate, Spring, Tapestry)
> >
> >
> > I'd generally be inclined to go with Option #2. Loading an object in
> > session A, then reattaching it to session B (with, for example,
> > Session.lock()) is a bit of a code smell with hibernate, especially if
> > there's any chance the object might have been changed by another
> > thread
> > between initial load and reattachment.
> >
> > Likewise there's the issue that if you're storing the whole
> > thing in
> > the HTTPSession that burns memory *and* requires that all your POJO's
> > implement serializable.
> >
> > All in all, I'd go with key and reload; it's what I do about
> > 95% of
> > the time except for a few special cases where I need to keep the
> > object and
> > session between screen renders, in which case I just store store the
> > Hibernate session in the HTTPSession (which I wouldn't recommend as a
> > general case solution).
> >
> > --- Pat
> > -user-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
> _________________________________________________________________
> Piano music podcast: http://inthehands.com
> Other interesting stuff: http://innig.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Konstantin Ignatyev
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
Re: Best Practice (Hibernate, Spring, Tapestry)
Posted by Cosmin Bucur <co...@gmail.com>.
It just blows my mind , that Spring or Tapestry or Hivemind do not
offer anything standard that can do this .
Is such a common need , and it's such a common question , with so much
general confusion arround it .
I've been trying to get this working for a while . I find that most
documentation available is poor and confusing , mostly because it
never deals with the SPECIFIC combination : hibernate + spring +
tapestry .
Cosmin
On 1/11/06, Paul Cantrell <ca...@pobox.com> wrote:
> The Hibernate folks are a lot more excited about long sessions and
> detached objects than I am. (It's hard not to get attached to a fun
> feature once you've implemented it!) Personally, I think they make
> the app harder to write: there's much more worrying about stale data
> and scalability. For many apps, caching give the same kinds of
> performance benefits with fewer programmer headaches and hidden
> concurrency issues.
>
> The session-per-request model is probably the simplest and easiest
> default to start with. I like to begin there, keeping in mind the
> other options, thinking carefully about where transaction boundaries
> need to be -- and then depart from session-per-request when specific
> situations require something different.
>
> Cheers,
>
> Paul
>
>
> On Jan 11, 2006, at 1:20 AM, <m....@yahoo.com>
> <m....@yahoo.com> wrote:
>
> > I just went thru Hibernate In Action (edition 1), chapter 8.2
> > (Implementing Application Transactions). This chapter talks about
> > the two options we talked about, and a third option: Long Session.
> >
> > It seems that "Hibernate in Action" recommends Long session on a
> > web application over other two. The next preferred option is
> > "Detached Persistent Object Strategy" (same as option 1 in my
> > original email).
> >
> > Will this new information change your opinions on these options?
> >
> > Thanks ....
> >
> > Shovon
> >
> > ----- Original Message ----
> > From: Patrick Casey <pa...@adelphia.net>
> > To: Tapestry users <ta...@jakarta.apache.org>
> > Sent: Tuesday, January 10, 2006 6:40:29 PM
> > Subject: RE: Best Practice (Hibernate, Spring, Tapestry)
> >
> >
> > I'd generally be inclined to go with Option #2. Loading an object in
> > session A, then reattaching it to session B (with, for example,
> > Session.lock()) is a bit of a code smell with hibernate, especially if
> > there's any chance the object might have been changed by another
> > thread
> > between initial load and reattachment.
> >
> > Likewise there's the issue that if you're storing the whole
> > thing in
> > the HTTPSession that burns memory *and* requires that all your POJO's
> > implement serializable.
> >
> > All in all, I'd go with key and reload; it's what I do about
> > 95% of
> > the time except for a few special cases where I need to keep the
> > object and
> > session between screen renders, in which case I just store store the
> > Hibernate session in the HTTPSession (which I wouldn't recommend as a
> > general case solution).
> >
> > --- Pat
> > -user-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
> _________________________________________________________________
> Piano music podcast: http://inthehands.com
> Other interesting stuff: http://innig.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Best Practice (Hibernate, Spring, Tapestry)
Posted by Paul Cantrell <ca...@pobox.com>.
The Hibernate folks are a lot more excited about long sessions and
detached objects than I am. (It's hard not to get attached to a fun
feature once you've implemented it!) Personally, I think they make
the app harder to write: there's much more worrying about stale data
and scalability. For many apps, caching give the same kinds of
performance benefits with fewer programmer headaches and hidden
concurrency issues.
The session-per-request model is probably the simplest and easiest
default to start with. I like to begin there, keeping in mind the
other options, thinking carefully about where transaction boundaries
need to be -- and then depart from session-per-request when specific
situations require something different.
Cheers,
Paul
On Jan 11, 2006, at 1:20 AM, <m....@yahoo.com>
<m....@yahoo.com> wrote:
> I just went thru Hibernate In Action (edition 1), chapter 8.2
> (Implementing Application Transactions). This chapter talks about
> the two options we talked about, and a third option: Long Session.
>
> It seems that "Hibernate in Action" recommends Long session on a
> web application over other two. The next preferred option is
> "Detached Persistent Object Strategy" (same as option 1 in my
> original email).
>
> Will this new information change your opinions on these options?
>
> Thanks ....
>
> Shovon
>
> ----- Original Message ----
> From: Patrick Casey <pa...@adelphia.net>
> To: Tapestry users <ta...@jakarta.apache.org>
> Sent: Tuesday, January 10, 2006 6:40:29 PM
> Subject: RE: Best Practice (Hibernate, Spring, Tapestry)
>
>
> I'd generally be inclined to go with Option #2. Loading an object in
> session A, then reattaching it to session B (with, for example,
> Session.lock()) is a bit of a code smell with hibernate, especially if
> there's any chance the object might have been changed by another
> thread
> between initial load and reattachment.
>
> Likewise there's the issue that if you're storing the whole
> thing in
> the HTTPSession that burns memory *and* requires that all your POJO's
> implement serializable.
>
> All in all, I'd go with key and reload; it's what I do about
> 95% of
> the time except for a few special cases where I need to keep the
> object and
> session between screen renders, in which case I just store store the
> Hibernate session in the HTTPSession (which I wouldn't recommend as a
> general case solution).
>
> --- Pat
> -user-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Best Practice (Hibernate, Spring, Tapestry)
Posted by Sergiy Kyrylkov <ky...@sac.com.ua>.
The best references here are Open Session in View pattern
http://hibernate.org/43.html and, if you use Hibernate 3.1, generic DAO
pattern http://hibernate.org/328.html and the latest Caveat Emptor (alpha 5)
http://caveatemptor.hibernate.org/ constantly updated for Hibernate in
Action 2nd edition covering Hibernate 3.0 and 3.1
It is up to you to choose between session-per-request or
session-per-conversation. Using generic DAO pattern you minimize your DAO
layer as much as possible.
Sergiy
==================
Multiplex Systems LLC
http://www.mpxsys.com
-----Original Message-----
From: m.shovon@yahoo.com [mailto:m.shovon@yahoo.com]
Sent: Wednesday, January 11, 2006 9:20 AM
To: Tapestry users
Subject: Re: Best Practice (Hibernate, Spring, Tapestry)
I just went thru Hibernate In Action (edition 1), chapter 8.2 (Implementing
Application Transactions). This chapter talks about the two options we
talked about, and a third option: Long Session.
It seems that "Hibernate in Action" recommends Long session on a web
application over other two. The next preferred option is "Detached
Persistent Object Strategy" (same as option 1 in my original email).
Will this new information change your opinions on these options?
Thanks ....
Shovon
----- Original Message ----
From: Patrick Casey <pa...@adelphia.net>
To: Tapestry users <ta...@jakarta.apache.org>
Sent: Tuesday, January 10, 2006 6:40:29 PM
Subject: RE: Best Practice (Hibernate, Spring, Tapestry)
I'd generally be inclined to go with Option #2. Loading an object in session
A, then reattaching it to session B (with, for example,
Session.lock()) is a bit of a code smell with hibernate, especially if
there's any chance the object might have been changed by another thread
between initial load and reattachment.
Likewise there's the issue that if you're storing the whole thing in the
HTTPSession that burns memory *and* requires that all your POJO's implement
serializable.
All in all, I'd go with key and reload; it's what I do about 95% of the
time except for a few special cases where I need to keep the object and
session between screen renders, in which case I just store store the
Hibernate session in the HTTPSession (which I wouldn't recommend as a
general case solution).
--- Pat
-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Best Practice (Hibernate, Spring, Tapestry)
Posted by m....@yahoo.com.
I just went thru Hibernate In Action (edition 1), chapter 8.2 (Implementing Application Transactions). This chapter talks about the two options we talked about, and a third option: Long Session.
It seems that "Hibernate in Action" recommends Long session on a web application over other two. The next preferred option is "Detached Persistent Object Strategy" (same as option 1 in my original email).
Will this new information change your opinions on these options?
Thanks ....
Shovon
----- Original Message ----
From: Patrick Casey <pa...@adelphia.net>
To: Tapestry users <ta...@jakarta.apache.org>
Sent: Tuesday, January 10, 2006 6:40:29 PM
Subject: RE: Best Practice (Hibernate, Spring, Tapestry)
I'd generally be inclined to go with Option #2. Loading an object in
session A, then reattaching it to session B (with, for example,
Session.lock()) is a bit of a code smell with hibernate, especially if
there's any chance the object might have been changed by another thread
between initial load and reattachment.
Likewise there's the issue that if you're storing the whole thing in
the HTTPSession that burns memory *and* requires that all your POJO's
implement serializable.
All in all, I'd go with key and reload; it's what I do about 95% of
the time except for a few special cases where I need to keep the object and
session between screen renders, in which case I just store store the
Hibernate session in the HTTPSession (which I wouldn't recommend as a
general case solution).
--- Pat
-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Best Practice (Hibernate, Spring, Tapestry)
Posted by Patrick Casey <pa...@adelphia.net>.
I'd generally be inclined to go with Option #2. Loading an object in
session A, then reattaching it to session B (with, for example,
Session.lock()) is a bit of a code smell with hibernate, especially if
there's any chance the object might have been changed by another thread
between initial load and reattachment.
Likewise there's the issue that if you're storing the whole thing in
the HTTPSession that burns memory *and* requires that all your POJO's
implement serializable.
All in all, I'd go with key and reload; it's what I do about 95% of
the time except for a few special cases where I need to keep the object and
session between screen renders, in which case I just store store the
Hibernate session in the HTTPSession (which I wouldn't recommend as a
general case solution).
--- Pat
> -----Original Message-----
> From: Moshiul Shovon [mailto:m.shovon@yahoo.com]
> Sent: Tuesday, January 10, 2006 4:33 PM
> To: Tapestry users
> Subject: Best Practice (Hibernate, Spring, Tapestry)
>
> Hello:
>
> I am using Tapestry + Spring + Hibernate (based on Appfuse 1.8.2).
>
> I had earlier posted a message in the Spring forum:
> http://forum.springframework.org/showthread.php?t=21231
>
> I was trying to figure out how to transparently re-attach hibernate
> sessions to objects saved in the http session.
>
> After checking various forums, I realized there are probably few options.
> Below is one related thread:
>
> http://www.mail-archive.com/tapestry-user@jakarta.apache.org/msg11105.html
>
> However, now I have a question about the best practice. Here are two
> options:
>
> 1) Save persistent POJOs in the http session and rettach hibernate session
> to those POJOs before using them
> 2) Save only primary keys of persistent POJOs in http session, and reload
> them on each http request cycle
>
> Which approach is better, and why?
>
> Orignially, I wanted to use option 1. It seemed natural. For example, If I
> have a shopping cart, I would have actual Item objects already loaded in
> the shopping cart, and this cart will be saved in http session (thru
> Tapestry).
>
> In the 2nd option, I would have to store only the primary keys of the
> Items and use some other methods to the load the objects when displaying
> or updating them. But, I am willing to go this route if this is the best
> practice considering how hibernate works.
>
> Thanks ...
>
> Shovon
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Best Practice (Hibernate, Spring, Tapestry)
Posted by Moshiul Shovon <m....@yahoo.com>.
Hello:
I am using Tapestry + Spring + Hibernate (based on Appfuse 1.8.2).
I had earlier posted a message in the Spring forum: http://forum.springframework.org/showthread.php?t=21231
I was trying to figure out how to transparently re-attach hibernate sessions to objects saved in the http session.
After checking various forums, I realized there are probably few options. Below is one related thread:
http://www.mail-archive.com/tapestry-user@jakarta.apache.org/msg11105.html
However, now I have a question about the best practice. Here are two options:
1) Save persistent POJOs in the http session and rettach hibernate session to those POJOs before using them
2) Save only primary keys of persistent POJOs in http session, and reload them on each http request cycle
Which approach is better, and why?
Orignially, I wanted to use option 1. It seemed natural. For example, If I have a shopping cart, I would have actual Item objects already loaded in the shopping cart, and this cart will be saved in http session (thru Tapestry).
In the 2nd option, I would have to store only the primary keys of the Items and use some other methods to the load the objects when displaying or updating them. But, I am willing to go this route if this is the best practice considering how hibernate works.
Thanks ...
Shovon
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org