You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by a7...@telus.net on 2003/06/26 20:55:10 UTC

template and associated class pairing problem

If there is a class (say A.java) associated with a Velocity template (A.vm), 
the class will be called first to bild template if A.vm is requested in URL. 
What I found out in Turbine 2.2.1 TDK is that if I redirect to another template 
(B.vm) in an Action or a template class (A.java) by calling 
data.setScreenTemplate("B.vm"), then B.vm's associated class (B.java) is not 
called! 
This posed a big problem because major content rendering logic could be and 
should be implemented in B.java. 
I also found (but not tested yet) there is an API named data.setRedirectURI() 
that might solve the problem. But I am not sure if $data is passed to the 
called template correctly. Even if data.setRedirectURI() works fine in this 
case, I still believe it is a major bug for data.setScreenTemplate skipping 
doBuildTemplate of the called template.

Any solutions please?



---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


Re: template and associated class pairing problem

Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
a7b46501@telus.net writes:

> It's good to know that. But the caveat is still a result of bad
> design. The template and associated class are supposed to have a
> more tight bond. What I recommend is adopting Microsoft .Net's
> strategy: to create a class out of the the template A.vm (using
> similar technology of jsp), and let this class derive from A.java.

Well, discussing the merits of good and bad design... :-)

It comes from the fact that the View of Turbine (in the dark ages
before we had _any_ templating solution and templating service)
consisted of java classes which were referenced by parameters. These
classes were mapped onto URIs by the mechanism that you can find today
in the AssemblerBroker service.

However, then someone decided, that it would be nice to use just one
java class as page/screen/layout, which in turn pulls a template file
and processes it through a template engine. This is how
VelocityScreen, VelocityPage and VelocityECSLayout/VelocityOnlyLayout
were born. Now it was decided that it would be nice to have a _second_
mapper built into the Template Service which does the template
pulling.

If you write a screen class, you normally extend VelocityScreen or
VelocitySecureScreen. So in the end, you do not really 'run' a
templating service as View for Turbine but a default Java class
(VelocityScreen and its decendants) which in turn uses a template as
View.

Mind boggling? You guess. ;-) 

Our power (which I don't know whether .NOT can match it or not) is,
that you can have a single screen class that decides which template to
show. And that you can have templates that map to a common screen
class (let's call it "Default".  Or "VelocityScreen ;-) ) that not
only is used by many different templates but is also actively searched
in a package tree manner.

However, if you want to compile your template into java classes and
extend them, well, that's what JSPs are for. Velocity Templates are
not Java Templates.

	Regards
		Henning

(Am I writing "However" too often? My wife thinks so. Well, that's
what you get for watching too much "Enterprise". ;-) )


>> >If there is a class (say A.java) associated with a Velocity template (A.vm),
>> 
>> >the class will be called first to bild template if A.vm is requested in URL.
>> 
>> >What I found out in Turbine 2.2.1 TDK is that if I redirect to another
>> template 
>> >(B.vm) in an Action or a template class (A.java) by calling 
>> >data.setScreenTemplate("B.vm"), then B.vm's associated class (B.java) is not
>> 
>> >called! 
>> 
>> If you do this in an Action, it is. If you do this in a screen class,
>> it is not.
>> 
>> Once you're in the screen class (A.java) and you change the Template,
>> the engine that matches a class to your template already ran and gave
>> you a result (A.java), the class that you're currently running. :-)
>> 
>> If you do this in an action, then this engine is just about to be
>> run. So it should work.
>> 
>> 	Regards
>> 		Henning
>> 
>> -- 
>> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
>> hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/
>> 
>> Java, perl, Solaris, Linux, xSP Consulting, Web Services 
>> freelance consultant -- Jakarta Turbine Development  -- hero for hire
>> 
>> --- Quote of the week: "It is pointless to tell people anything when
>> you know that they won't process the message." --- Jonathan Revusky
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>> 
>> 





>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-user-help@jakarta.apache.org

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

--- Quote of the week: "It is pointless to tell people anything when
you know that they won't process the message." --- Jonathan Revusky

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


Re: template and associated class pairing problem

Posted by a7...@telus.net.
It's good to know that. But the caveat is still a result of bad design. The 
template and associated class are supposed to have a more tight bond. What I 
recommend is adopting Microsoft .Net's strategy: to create a class out of the 
the template A.vm (using similar technology of jsp), and let this class derive 
from A.java. 

Fred


Quoting "Henning P. Schmiedehausen" <hp...@intermeta.de>:

> a7b46501@telus.net writes:
> 
> >If there is a class (say A.java) associated with a Velocity template (A.vm),
> 
> >the class will be called first to bild template if A.vm is requested in URL.
> 
> >What I found out in Turbine 2.2.1 TDK is that if I redirect to another
> template 
> >(B.vm) in an Action or a template class (A.java) by calling 
> >data.setScreenTemplate("B.vm"), then B.vm's associated class (B.java) is not
> 
> >called! 
> 
> If you do this in an Action, it is. If you do this in a screen class,
> it is not.
> 
> Once you're in the screen class (A.java) and you change the Template,
> the engine that matches a class to your template already ran and gave
> you a result (A.java), the class that you're currently running. :-)
> 
> If you do this in an action, then this engine is just about to be
> run. So it should work.
> 
> 	Regards
> 		Henning
> 
> -- 
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
> hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/
> 
> Java, perl, Solaris, Linux, xSP Consulting, Web Services 
> freelance consultant -- Jakarta Turbine Development  -- hero for hire
> 
> --- Quote of the week: "It is pointless to tell people anything when
> you know that they won't process the message." --- Jonathan Revusky
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
> 
> 





---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


Re: template and associated class pairing problem

Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
a7b46501@telus.net writes:

>If there is a class (say A.java) associated with a Velocity template (A.vm), 
>the class will be called first to bild template if A.vm is requested in URL. 
>What I found out in Turbine 2.2.1 TDK is that if I redirect to another template 
>(B.vm) in an Action or a template class (A.java) by calling 
>data.setScreenTemplate("B.vm"), then B.vm's associated class (B.java) is not 
>called! 

If you do this in an Action, it is. If you do this in a screen class,
it is not.

Once you're in the screen class (A.java) and you change the Template,
the engine that matches a class to your template already ran and gave
you a result (A.java), the class that you're currently running. :-)

If you do this in an action, then this engine is just about to be
run. So it should work.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

--- Quote of the week: "It is pointless to tell people anything when
you know that they won't process the message." --- Jonathan Revusky

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


Re: AW: template and associated class pairing problem

Posted by a7...@telus.net.
More investigation reveals using doRedirect instead of setTemplate solves the 
problem.

> My test shows setTemplate() doesn't fare better than
> data.setScreenTemplate(). 
> The simplest way you can test by yourself is in TDK, create a class
> Login.java 
> and override method doBuildTemplate to put some debug. In 
> SecureScreen.isAuthorized method, change the code
> data.setScreenTemplate(TurbineResources.getString("template.login"));
> to 
> setTemplate(data, TurbineResources.getString("template.login"));
> 
> The result is the same: Login.java never got called!
> 
> 
> Quoting Jürgen Hoffmann <jh...@byteaction.de>:
> 
> > Hi,
> > 
> > data.setScreenTemplate() sets the Template to be used to render the
> > screen you are in. If you want to redirect a request to another
> > Screen+Template inside a VelocityAction or VelocitySecureScreen you have
> > to use setTemplate() This will invoke the class and the screen.
> > See:
> > http://jakarta.apache.org/turbine/turbine-2.2.0/apidocs/org/apache/turbi
> > ne/modules/actions/VelocityAction.html#setTemplate(org.apache.turbine.ut
> > il.RunData, java.lang.String)
> > http://jakarta.apache.org/turbine/turbine-2.2.0/apidocs/org/apache/turbi
> > ne/modules/screens/TemplateScreen.html#setTemplate(org.apache.turbine.ut
> > il.RunData, java.lang.String)
> > 
> > Kind regards
> >  
> > Jürgen Hoffmann
> > ByteACTION GmbH
> >  
> > cert. Perl Programmer
> > cert. Linux System Administrator
> > cert. Java Programmer
> > 
> > 
> > 
> > -----Ursprüngliche Nachricht-----
> > Von: a7b46501@telus.net [mailto:a7b46501@telus.net] 
> > Gesendet: Donnerstag, 26. Juni 2003 21:32
> > An: Turbine Users List
> > Betreff: Re: template and associated class pairing problem
> > 
> > 
> > I know you can use pull model to stuff data into context and let
> > template 
> > decide which one to pick. But it doesn't cure all. 
> > The problem is what and when do you stuff data into context? In some
> > cases the 
> > data is only associated with that screen. The most logical place to
> > populate 
> > the data is in the associated class. Anywhere else (actions etc) will
> > result in 
> > code duplication.
> > 
> > 
> > > > This posed a big problem because major content
> > > > rendering logic could be and
> > > > should be implemented in B.java. 
> > > 
> > > Check out the pull model. In this approach you pull
> > > all the data into each template therefore eliminating
> > > the need to put any content rendering logic in a
> > > screen.  my turbine app uses the pul model and the
> > > only code in any screens is for security purposes.
> > > 
> > > Push vs. Pull: 
> > > http://jakarta.apache.org/turbine/turbine-2.2.1/pullmodel.html
> > > 
> > > Pull HowTo: 
> > > http://jakarta.apache.org/turbine/turbine-2.2.1/howto/pullmodel-howto.
> > > html
> > > 
> > > -Lou
> > > 
> > > __________________________________
> > > Do you Yahoo!?
> > > SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: turbine-user-help@jakarta.apache.org
> > > 
> > > 
> > 
> > 
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-user-help@jakarta.apache.org
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-user-help@jakarta.apache.org
> > 
> > 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
> 
> 





---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


Re: AW: template and associated class pairing problem

Posted by a7...@telus.net.
My test shows setTemplate() doesn't fare better than data.setScreenTemplate(). 
The simplest way you can test by yourself is in TDK, create a class Login.java 
and override method doBuildTemplate to put some debug. In 
SecureScreen.isAuthorized method, change the code
data.setScreenTemplate(TurbineResources.getString("template.login"));
to 
setTemplate(data, TurbineResources.getString("template.login"));

The result is the same: Login.java never got called!


Quoting Jürgen Hoffmann <jh...@byteaction.de>:

> Hi,
> 
> data.setScreenTemplate() sets the Template to be used to render the
> screen you are in. If you want to redirect a request to another
> Screen+Template inside a VelocityAction or VelocitySecureScreen you have
> to use setTemplate() This will invoke the class and the screen.
> See:
> http://jakarta.apache.org/turbine/turbine-2.2.0/apidocs/org/apache/turbi
> ne/modules/actions/VelocityAction.html#setTemplate(org.apache.turbine.ut
> il.RunData, java.lang.String)
> http://jakarta.apache.org/turbine/turbine-2.2.0/apidocs/org/apache/turbi
> ne/modules/screens/TemplateScreen.html#setTemplate(org.apache.turbine.ut
> il.RunData, java.lang.String)
> 
> Kind regards
>  
> Jürgen Hoffmann
> ByteACTION GmbH
>  
> cert. Perl Programmer
> cert. Linux System Administrator
> cert. Java Programmer
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: a7b46501@telus.net [mailto:a7b46501@telus.net] 
> Gesendet: Donnerstag, 26. Juni 2003 21:32
> An: Turbine Users List
> Betreff: Re: template and associated class pairing problem
> 
> 
> I know you can use pull model to stuff data into context and let
> template 
> decide which one to pick. But it doesn't cure all. 
> The problem is what and when do you stuff data into context? In some
> cases the 
> data is only associated with that screen. The most logical place to
> populate 
> the data is in the associated class. Anywhere else (actions etc) will
> result in 
> code duplication.
> 
> 
> > > This posed a big problem because major content
> > > rendering logic could be and
> > > should be implemented in B.java. 
> > 
> > Check out the pull model. In this approach you pull
> > all the data into each template therefore eliminating
> > the need to put any content rendering logic in a
> > screen.  my turbine app uses the pul model and the
> > only code in any screens is for security purposes.
> > 
> > Push vs. Pull: 
> > http://jakarta.apache.org/turbine/turbine-2.2.1/pullmodel.html
> > 
> > Pull HowTo: 
> > http://jakarta.apache.org/turbine/turbine-2.2.1/howto/pullmodel-howto.
> > html
> > 
> > -Lou
> > 
> > __________________________________
> > Do you Yahoo!?
> > SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-user-help@jakarta.apache.org
> > 
> > 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
> 
> 





---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


AW: template and associated class pairing problem

Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi,

data.setScreenTemplate() sets the Template to be used to render the
screen you are in. If you want to redirect a request to another
Screen+Template inside a VelocityAction or VelocitySecureScreen you have
to use setTemplate() This will invoke the class and the screen.
See:
http://jakarta.apache.org/turbine/turbine-2.2.0/apidocs/org/apache/turbi
ne/modules/actions/VelocityAction.html#setTemplate(org.apache.turbine.ut
il.RunData, java.lang.String)
http://jakarta.apache.org/turbine/turbine-2.2.0/apidocs/org/apache/turbi
ne/modules/screens/TemplateScreen.html#setTemplate(org.apache.turbine.ut
il.RunData, java.lang.String)

Kind regards
 
Jürgen Hoffmann
ByteACTION GmbH
 
cert. Perl Programmer
cert. Linux System Administrator
cert. Java Programmer



-----Ursprüngliche Nachricht-----
Von: a7b46501@telus.net [mailto:a7b46501@telus.net] 
Gesendet: Donnerstag, 26. Juni 2003 21:32
An: Turbine Users List
Betreff: Re: template and associated class pairing problem


I know you can use pull model to stuff data into context and let
template 
decide which one to pick. But it doesn't cure all. 
The problem is what and when do you stuff data into context? In some
cases the 
data is only associated with that screen. The most logical place to
populate 
the data is in the associated class. Anywhere else (actions etc) will
result in 
code duplication.


> > This posed a big problem because major content
> > rendering logic could be and
> > should be implemented in B.java. 
> 
> Check out the pull model. In this approach you pull
> all the data into each template therefore eliminating
> the need to put any content rendering logic in a
> screen.  my turbine app uses the pul model and the
> only code in any screens is for security purposes.
> 
> Push vs. Pull: 
> http://jakarta.apache.org/turbine/turbine-2.2.1/pullmodel.html
> 
> Pull HowTo: 
> http://jakarta.apache.org/turbine/turbine-2.2.1/howto/pullmodel-howto.
> html
> 
> -Lou
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
> 
> 





---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


Re: template and associated class pairing problem

Posted by Louis Moore <lr...@yahoo.com>.
--- a7b46501@telus.net wrote:
> I know you can use pull model to stuff data into
> context and let template 
> decide which one to pick. But it doesn't cure all. 
> The problem is what and when do you stuff data into
> context? In some cases the 
> data is only associated with that screen. The most
> logical place to populate 
> the data is in the associated class. Anywhere else
> (actions etc) will result in 
> code duplication.
> 

the whole point of the pull model is that you're NOT
stuffing data anywhere. You write the function
getStuff() once, in your pull tool, and then anytime
your front-end designer needs to get that Stuff in his
template, he makes a call to the function. If you only
need the data once, the function only gets called
once. There is no code duplication. Plus, if you later
find the need to use the same data elsewhere, you
don't need to rewrite any java code.

-Lou

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


Re: template and associated class pairing problem

Posted by a7...@telus.net.
I know you can use pull model to stuff data into context and let template 
decide which one to pick. But it doesn't cure all. 
The problem is what and when do you stuff data into context? In some cases the 
data is only associated with that screen. The most logical place to populate 
the data is in the associated class. Anywhere else (actions etc) will result in 
code duplication.


> > This posed a big problem because major content
> > rendering logic could be and 
> > should be implemented in B.java. 
> 
> Check out the pull model. In this approach you pull
> all the data into each template therefore eliminating
> the need to put any content rendering logic in a
> screen.  my turbine app uses the pul model and the
> only code in any screens is for security purposes.
> 
> Push vs. Pull:
> http://jakarta.apache.org/turbine/turbine-2.2.1/pullmodel.html
> 
> Pull HowTo:
> http://jakarta.apache.org/turbine/turbine-2.2.1/howto/pullmodel-howto.html
> 
> -Lou
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
> 
> 





---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


Re: template and associated class pairing problem

Posted by Louis Moore <lr...@yahoo.com>.
> This posed a big problem because major content
> rendering logic could be and 
> should be implemented in B.java. 

Check out the pull model. In this approach you pull
all the data into each template therefore eliminating
the need to put any content rendering logic in a
screen.  my turbine app uses the pul model and the
only code in any screens is for security purposes.

Push vs. Pull:
http://jakarta.apache.org/turbine/turbine-2.2.1/pullmodel.html

Pull HowTo:
http://jakarta.apache.org/turbine/turbine-2.2.1/howto/pullmodel-howto.html

-Lou

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org