[EMAIL PROTECTED] 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
>> [EMAIL PROTECTED] +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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
