You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Otto Cordero <oc...@sipecom.com> on 2003/04/22 19:47:19 UTC
one template for all
Dear list,
We have been working with Turbine in a project in which we have to produce
many different html pages that differ between each other very little. More
specifically, we needed to create mantainance screens for the tables in a
database, so the presentation style remained consistent while the html form
in it changed. We thought the best idea was to have one single template for
all. This idea saved us a lot of time and we ended up having a good
solution. However, we had to use Turbine in a rather unusual way: Since our
template was generic, and one template is attached to one screen, we
couldn't have one single screen to work for all the many different forms.
Instead, the code that configures each specific was placed in Actions, so
these actions work as both action and screen. We could also have had one
action and one screen per form (setting the screen with setScreen from the
action) but given the large amount of form configurations, we thought this
wasn't a good idea.
Given this, we have come with the idea of having Screens that may build the
template in different ways, according to a specified "screenConfig". So the
"screenConfig" could be setted from the http parameters or with
setScreen("screenName", "screenConfig"). This would work similar to action
events, but in screens, so if we set the "screenConfig" to "xyz", the method
doXyz from the Screen would be executed.
I am posting this to the list because I would like to hear your comments on
this issue. Is this a good or bad idea? Can it be solved in other way?.
Regards,
Otto.
----- Original Message -----
From: <EP...@upstate.com>
To: <tu...@jakarta.apache.org>
Sent: Tuesday, April 22, 2003 8:38 AM
Subject: RE: cvs commit: jakarta-turbine-2/proposals/henning/velocitymacro
> I guess I'll plug my configuration proposal. Basically, you can edit a
> turbine-configuration.xml file and point to all the properties files that
> you might have. Of course, we would need the ability to load the
properties
> from the jar versus the file system...
>
> Eric
>
> -----Original Message-----
> From: jbrekke@wi.rr.com [mailto:jbrekke@wi.rr.com]
> Sent: Tuesday, April 22, 2003 9:16 AM
> To: Turbine Developers List
> Cc: hps@intermeta.de
> Subject: Re: cvs commit:
> jakarta-turbine-2/proposals/henning/velocitymacro
>
>
>
> Have you found a way to include properties files for your jar'd apps?
> We ususally have these *include*d at the bottom of the main TR.props
> file. It would be nice to get the properties files into the jars
> along with the templates and classes.
>
>
> >>>>> On Tue, 22 Apr 2003 08:19:38 +0000 (UTC), "Henning P.
Schmiedehausen"
> <hp...@intermeta.de> said:
>
> > EPugh@upstate.com writes:
> >> ------_=_NextPart_001_01C3083C.9698EB90 Content-Type: text/plain;
> >> charset="iso-8859-1"
>
> >> Does this mean that out of the box I could put .vm files in a jar
> >> (with other code like the actions etc) and share that accross
> >> multiple turbine apps?
>
> > Yeah, sure. That's what the classpath loader is all about. I
> > distribute my applications like this all the time. They all have a
> > "templates" jar which contains four packages: screens, navigations,
> > layouts and macros. In my app, I simply add e.g.
>
> > services.VelocityService.velocimacro.library =
> > macros/ToolboxMacros.vm
>
> > and toolbox.jar contains:
>
> > % jar tvf ~/javalibs/maven/intermeta/jars/toolbox-2.0-dev.jar | grep
> > -i vm 818 Thu Apr 10 14:02:02 CEST 2003 macros/ToolboxMacros.vm 5679
> > Thu Apr 10 14:02:02 CEST 2003 macros/GridMacros.vm 4826 Thu Apr 10
> > 14:02:02 CEST 2003 macros/IntakeMacros.vm
>
> > The classpath loader then finds this on the classpath and loads it
> > into Velocity.
>
> > You might understand now, why I'm such a stickler for template
> > naming and pathes. I don't have any template files (besides an
> > Index.vm which is different for each installation) at all in my
> > apps, once they're deployed.
>
> > You should see the eyes of my customers' engineers when they decide
> > to "improve" the web layout of the application pages and don't find
> > any files which contain the template pages... =:-)
>
> > Regards Henning
>
>
>
> >> ERic
>
> >> -----Original Message----- From: henning@apache.org
> >> [mailto:henning@apache.org] Sent: Monday, April 21, 2003 2:42 PM
> >> To: jakarta-turbine-2-cvs@apache.org Subject: cvs commit:
> >> jakarta-turbine-2/proposals/henning/velocitymacros README
> >> TurbineMacros.vm
>
>
> >> henning 2003/04/21 11:41:32
>
> >> Added: proposals/henning/velocitymacros README TurbineMacros.vm
> >> Log: First cut at actually implementing the macros that Quinton
> >> described in HtmlPageAttributes. Please try out and report bugs.
> >>
> >> Revision Changes Path 1.1
> >> jakarta-turbine-2/proposals/henning/velocitymacros/README
> >>
> >> Index: README
> >> ===================================================================
> >> Velocity Macros for VelocityOnlyLayout
> >> ======================================
> >>
> >> These are two macros which can be used in conjunction with
> >> VelocityOnlyLayout and HtmlPageAttributes to provide the same
> >> Functionality as VelocityECSLayout with TemplatePageAttributes.
> >>
> >> These macros should be used in the Layout template like this:
> >>
> >> --- cut --- Layout Template --- cut ---
> >>
> >> ... here you should put things like setting the page name, adding
> >> style sheets and so on.
> >>
> >> <html> #TurbineHtmlHead() #TurbineHtmlBodyStart() .... your body
> >> information </body> </html> --- cut --- Layout Template --- cut ---
> >>
> >> As the layout template is rendered _after_ the screen template, you
> >> can of course, add information to the $page tool in your screen
> >> template. This will be added correctly to the <head>...</head> and
> >> <body> tags.
> >>
> >>
> >> Adding these Macros to the Turbine Code base
> >> ============================================
> >>
> >> I propose to add these Macros for loading by the classpath loader
> >> directly from the turbine.jar. To achieve this, the following is
> >> added to the java:compile postGoal in maven.xml:
> >>
> >> <copy file="${maven.src.dir}/macros/TurbineMacros.vm"
> >> todir="${maven.build.dest}/macros" />
> >>
> >> (assuming the Macro file is put into src/macros/TurbineMacros.vm in
> >> the Turbine code base)
> >>
> >> and then adding a load instruction to the
> >> TurbineResources.properties:
> >>
> >> services.VelocityService.velocimacro.library =
> >> macros/TurbineMacros.vm
> >>
> >> Of course, the classpath loader must be configured (it is by
> >> default):
> >>
> >> services.VelocityService.resource.loader = classpath
> >> services.VelocityService.classpath.resource.loader.description =
> >> Velocity Classpath Resource Loader
> >> services.VelocityService.classpath.resource.loader.class =
> >> org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
> >>
> >>
> >>
> >>
> >>
> >>
> >> 1.1
> >> jakarta-turbine-2/proposals/henning/velocitymacros/TurbineMacros.vm
> >>
> >> Index: TurbineMacros.vm
> >> ===================================================================
> >> ## @version $Id: TurbineMacros.vm,v 1.1 2003/04/21 18:41:31 henning
> >> Exp $ ## @author <a href="mailto:hps@intermeta.de">Henning
> >> P. Schmiedehausen</a>
> >>
> >> ## ## Build the <head> ... </head> tag of a web page with
> >> VelocityOnly Layout ## #macro (TurbineHtmlHead) <head> #if
> >> ($!page.Title) <title>$page.Title</title> #end #if
> >> ($page.MetaTags.size() > 0) #foreach($metaTag in
> >> $page.MetaTags.keySet()) <meta name="$metaTag"
> >> content="$page.MetaTags.get($metaTag)"> #end #end #if
> >> ($page.HttpEquivs.size() > 0) #foreach($httpEquiv in
> >> $page.HttpEquivs.keySet()) <meta http-equiv="$httpEquiv"
> >> content="$page.HttpEquivs.get($httpEquiv)"> #end #end #if
> >> ($page.StyleSheets.size() > 0) #foreach( $styleSheet in
> >> $page.StyleSheets ) <link rel="stylesheet" href="$styleSheet.Url"
> >> #if($!styleSheet.Type) type="$styleSheet.Type" #end
> >> #if($!styleSheet.Media) media="$styleSheet.Media" #end
> >> #if($!styleSheet.Title) title="$styleSheet.Title" #end
> >> >
> >> #end #end #if ($page.Scripts.size() > 0) #foreach( $script in
> >> $page.Scripts ) <script type="text/javascript" src="$script"
> >> language="JavaScript"></script> #end #end </head> #end
> >>
> >> ## ## Build the <body> start tag of a web page with VelocityOnly
> >> Layout ## #macro (TurbineHtmlBodyStart) #if
> >> ($page.BodyAttributes.size() > 0) <body #foreach( $attributeName in
> >> $page.BodyAttributes.keySet() ) $attributeName =
> >> "$page.BodyAttributes.get($attributeName)" #end
> >> >
> >> #else <body> #end #end
> >>
> >>
> >>
> >>
> >>
>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> >> turbine-dev-help@jakarta.apache.org
>
> >> ------_=_NextPart_001_01C3083C.9698EB90--
>
> > -- 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
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
> --
> =====================================================================
> Jeffrey D. Brekke jbrekke@wi.rr.com
> Wisconsin, USA brekke@apache.org
> ekkerbj@yahoo.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: one template for all
Posted by Eric Emminger <er...@ericemminger.com>.
Otto Cordero wrote:
> We have been working with Turbine in a project in which we have to produce
> many different html pages that differ between each other very little. More
> specifically, we needed to create mantainance screens for the tables in a
> database, so the presentation style remained consistent while the html form
> in it changed. We thought the best idea was to have one single template for
Does this single template have lots of complex if/else conditions in
Velocity? In other words, is the View layer more complex in exchange for
a simpler Controller layer?
> all. This idea saved us a lot of time and we ended up having a good
> solution. However, we had to use Turbine in a rather unusual way: Since our
> template was generic, and one template is attached to one screen, we
> couldn't have one single screen to work for all the many different forms.
> Instead, the code that configures each specific was placed in Actions, so
> these actions work as both action and screen. We could also have had one
> action and one screen per form (setting the screen with setScreen from the
> action) but given the large amount of form configurations, we thought this
> wasn't a good idea.
> Given this, we have come with the idea of having Screens that may build the
> template in different ways, according to a specified "screenConfig". So the
> "screenConfig" could be setted from the http parameters or with
> setScreen("screenName", "screenConfig"). This would work similar to action
> events, but in screens, so if we set the "screenConfig" to "xyz", the method
> doXyz from the Screen would be executed.
> I am posting this to the list because I would like to hear your comments on
> this issue. Is this a good or bad idea? Can it be solved in other way?.
This sounds like you replaced several screen classes with one screen
class having several methods. Is that right?
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: one template for all
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Henning P. Schmiedehausen" <hp...@intermeta.de> writes:
[...]
>Or simply put all your Template names into a hash map and pull the
>template associated with your screen out of it by some key which
>decides which screen to show. So by requesting
>$link.setScreen("Foo");
Ok, it is that easy. Almost. :-)
Actually, the setScreen("Foo") does not work, because our
TemplateSessionValidator will choke on that (Ugh, that bugger _really_
wants a rewrite. We should push 2.3 out of the door so we can start
backporting the pipeline).
You must use setPage("Foo.vm"), even if Foo.vm does not exist. This is
simply needed to map on the Foo class.
I threw together a small demo app (which is really small. :-). Get it
from
ftp://ftp.hometree.net/pub/java/multitemplate/
multitemplate.war -- Ready to run Web application (5,1 MB)
multitemplate-1.0.tar.gz -- Source Code (12 kB)
Notice, that there are page links for SwitchScreen.vm in the pages, a
template which does not exist at all. It still works. :-)
Some caveats when trying to recompile: This one already uses the new
URI classes.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: one template for all
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Otto Cordero" <oc...@sipecom.com> writes:
>Henning,
>We didn't have many templates and one screen, that wouldn't be much of a
>problem. We had one single template corresponding to one single presentation
>style, and what we needed was many Screens to configure the many different
>variants of context info that should be passed to this single template. I
>think using pull tools is one valid solution, but having one single screen
>with a big if-else is definitely not. We had about 50 different forms that
>required different context information. This takes us back to my original
>question, would it be a good idea if I could call one specific method in the
>Screen, just like we can do now with Action events? Something like
>setScreen("screenName", "methodName").
Ah, ok. Then I misunderstood your initial question. To answer in a short
sentence: Yes, here a tool is definitivly the way to go. Pull out the current
screen name in the init method of a request tool and set it up internally to
do "the right thing" for your screen.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: one template for all
Posted by Otto Cordero <oc...@sipecom.com>.
Henning,
We didn't have many templates and one screen, that wouldn't be much of a
problem. We had one single template corresponding to one single presentation
style, and what we needed was many Screens to configure the many different
variants of context info that should be passed to this single template. I
think using pull tools is one valid solution, but having one single screen
with a big if-else is definitely not. We had about 50 different forms that
required different context information. This takes us back to my original
question, would it be a good idea if I could call one specific method in the
Screen, just like we can do now with Action events? Something like
setScreen("screenName", "methodName").
Regards,
Otto.
----- Original Message -----
From: "Henning P. Schmiedehausen" <hp...@intermeta.de>
Newsgroups: hometree.jakarta.turbine.dev
To: <tu...@jakarta.apache.org>
Sent: Wednesday, April 23, 2003 2:53 AM
Subject: Re: one template for all
> "Otto Cordero" <oc...@sipecom.com> writes:
>
> >solution. However, we had to use Turbine in a rather unusual way: Since
our
> >template was generic, and one template is attached to one screen, we
> >couldn't have one single screen to work for all the many different forms.
>
> Ugh. Don't tell me, you did that. :-)
>
> Easiest to change this would've been:
>
> public class Foo extends VelocityScreen
> {
> public void doBuildTemplate(RunData data, VelocityContext ctx)
> throws Exception
> {
> if ( .... some condition applied ...)
> {
> data.setScreenTemplate("Template1.vm");
> }
> else
> {
> data.setScreenTemplate("Template2.vm");
> }
> }
> }
>
> Or simply put all your Template names into a hash map and pull the
> template associated with your screen out of it by some key which
> decides which screen to show. So by requesting
>
> $link.setScreen("Foo");
>
> you would get the Foo class above run which in turn sets the template
> that you want to show (This is one of the places where the notion
> between Screen (= Entity that displays the contents of a page) and
> Template (= Entity that gets possibly parsed and displayed by a
> VelocityScreen Screen Entity) is blurred.
>
> The "One Screen - One Template" mapping is simply the default case
> from VelocityScreen and VelocitySecureScreen. There is no reason you
> cannot assign multiple Templates to a single screen. I do this all the
> time depending on e.g. access rights to a screen. Someone with user
> rights gets a different Template presented than someone with admin
> rights.
>
> >Instead, the code that configures each specific was placed in Actions, so
> >these actions work as both action and screen. We could also have had one
> >action and one screen per form (setting the screen with setScreen from
the
> >action) but given the large amount of form configurations, we thought
this
> >wasn't a good idea.
>
> Urgh. We definitly need better documentation to clarify the role of
actions
> and screens in the turbine model. It seems to me that you turned the whole
> screen/action concept upside down. =:-)
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: one template for all
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Otto Cordero" <oc...@sipecom.com> writes:
>solution. However, we had to use Turbine in a rather unusual way: Since our
>template was generic, and one template is attached to one screen, we
>couldn't have one single screen to work for all the many different forms.
Ugh. Don't tell me, you did that. :-)
Easiest to change this would've been:
public class Foo extends VelocityScreen
{
public void doBuildTemplate(RunData data, VelocityContext ctx)
throws Exception
{
if ( .... some condition applied ...)
{
data.setScreenTemplate("Template1.vm");
}
else
{
data.setScreenTemplate("Template2.vm");
}
}
}
Or simply put all your Template names into a hash map and pull the
template associated with your screen out of it by some key which
decides which screen to show. So by requesting
$link.setScreen("Foo");
you would get the Foo class above run which in turn sets the template
that you want to show (This is one of the places where the notion
between Screen (= Entity that displays the contents of a page) and
Template (= Entity that gets possibly parsed and displayed by a
VelocityScreen Screen Entity) is blurred.
The "One Screen - One Template" mapping is simply the default case
from VelocityScreen and VelocitySecureScreen. There is no reason you
cannot assign multiple Templates to a single screen. I do this all the
time depending on e.g. access rights to a screen. Someone with user
rights gets a different Template presented than someone with admin
rights.
>Instead, the code that configures each specific was placed in Actions, so
>these actions work as both action and screen. We could also have had one
>action and one screen per form (setting the screen with setScreen from the
>action) but given the large amount of form configurations, we thought this
>wasn't a good idea.
Urgh. We definitly need better documentation to clarify the role of actions
and screens in the turbine model. It seems to me that you turned the whole
screen/action concept upside down. =:-)
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
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: one template for all
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
I'll echo other advice here, use pull tools. Create a pull tool, which could be a domain object that knows about tables, and have the template use the api provided. The code in the pull tool would have any logic needed to help the template render. The template should be sorta simple, like epugh mentioned ( forgive my buggy vtl ):
<form>
#foreach ($column in $maintTool.Table)
#displayHeader($column)
#end
#foreach ($row in $maintTool.Table)
#displayRow($row)
#end
</form>
The action before the template would set the current table in the pull tool or something. Based on the current table your actions could also know what to do, you can get the pull tool in the action also:
MaintenanceTool maintTool = (MaintenanceTool)context.get("maintTool");
table = maintTool.getTable();
Hope this helps a bit..
>>>>> On Tue, 22 Apr 2003 12:47:19 -0500, "Otto Cordero" <oc...@sipecom.com> said:
> Dear list, We have been working with Turbine in a project in which
> we have to produce many different html pages that differ between
> each other very little. More specifically, we needed to create
> mantainance screens for the tables in a database, so the
> presentation style remained consistent while the html form in it
> changed. We thought the best idea was to have one single template
> for all. This idea saved us a lot of time and we ended up having a
> good solution. However, we had to use Turbine in a rather unusual
> way: Since our template was generic, and one template is attached to
> one screen, we couldn't have one single screen to work for all the
> many different forms. Instead, the code that configures each
> specific was placed in Actions, so these actions work as both action
> and screen. We could also have had one action and one screen per
> form (setting the screen with setScreen from the action) but given
> the large amount of form configurations, we thought this wasn't a
> good idea. Given this, we have come with the idea of having Screens
> that may build the template in different ways, according to a
> specified "screenConfig". So the "screenConfig" could be setted from
> the http parameters or with setScreen("screenName",
> "screenConfig"). This would work similar to action events, but in
> screens, so if we set the "screenConfig" to "xyz", the method doXyz
> from the Screen would be executed. I am posting this to the list
> because I would like to hear your comments on this issue. Is this a
> good or bad idea? Can it be solved in other way?.
> Regards,
> Otto.
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: one template for all
Posted by Quinton McCombs <qm...@nequalsone.com>.
You could use a pull tool to create the form for the page. The pull
tool would be passed in the URL parameters to tell it what form to
create. The tool would pull its configuration from XML or a database
table.
The only problem left at that poinbt is processing the form submissions.
In my application, I have a separate action for each table. Each of the
actions inherit from a generic 'data entry' class where I perform Intake
validation, error handling, etc...
> -----Original Message-----
> From: Otto Cordero [mailto:ocordero@sipecom.com]
> Sent: Tuesday, April 22, 2003 12:47 PM
> To: Turbine Developers List
> Subject: one template for all
>
>
> Dear list,
>
> We have been working with Turbine in a project in which we
> have to produce many different html pages that differ between
> each other very little. More specifically, we needed to
> create mantainance screens for the tables in a database, so
> the presentation style remained consistent while the html
> form in it changed. We thought the best idea was to have one
> single template for all. This idea saved us a lot of time and
> we ended up having a good solution. However, we had to use
> Turbine in a rather unusual way: Since our template was
> generic, and one template is attached to one screen, we
> couldn't have one single screen to work for all the many
> different forms. Instead, the code that configures each
> specific was placed in Actions, so these actions work as both
> action and screen. We could also have had one action and one
> screen per form (setting the screen with setScreen from the
> action) but given the large amount of form configurations, we
> thought this wasn't a good idea. Given this, we have come
> with the idea of having Screens that may build the template
> in different ways, according to a specified "screenConfig".
> So the "screenConfig" could be setted from the http
> parameters or with setScreen("screenName", "screenConfig").
> This would work similar to action events, but in screens, so
> if we set the "screenConfig" to "xyz", the method doXyz from
> the Screen would be executed. I am posting this to the list
> because I would like to hear your comments on this issue. Is
> this a good or bad idea? Can it be solved in other way?.
>
> Regards,
>
> Otto.
>
>
> ----- Original Message -----
> From: <EP...@upstate.com>
> To: <tu...@jakarta.apache.org>
> Sent: Tuesday, April 22, 2003 8:38 AM
> Subject: RE: cvs commit:
> jakarta-turbine-2/proposals/henning/velocitymacro
>
>
> > I guess I'll plug my configuration proposal. Basically,
> you can edit
> > a turbine-configuration.xml file and point to all the
> properties files
> > that you might have. Of course, we would need the ability
> to load the
> properties
> > from the jar versus the file system...
> >
> > Eric
> >
> > -----Original Message-----
> > From: jbrekke@wi.rr.com [mailto:jbrekke@wi.rr.com]
> > Sent: Tuesday, April 22, 2003 9:16 AM
> > To: Turbine Developers List
> > Cc: hps@intermeta.de
> > Subject: Re: cvs commit:
> > jakarta-turbine-2/proposals/henning/velocitymacro
> >
> >
> >
> > Have you found a way to include properties files for your
> jar'd apps?
> > We ususally have these *include*d at the bottom of the main
> TR.props
> > file. It would be nice to get the properties files into the jars
> > along with the templates and classes.
> >
> >
> > >>>>> On Tue, 22 Apr 2003 08:19:38 +0000 (UTC), "Henning P.
> Schmiedehausen"
> > <hp...@intermeta.de> said:
> >
> > > EPugh@upstate.com writes:
> > >> ------_=_NextPart_001_01C3083C.9698EB90 Content-Type:
> text/plain;
> > >> charset="iso-8859-1"
> >
> > >> Does this mean that out of the box I could put .vm files
> in a jar
> > >> (with other code like the actions etc) and share that accross
> > >> multiple turbine apps?
> >
> > > Yeah, sure. That's what the classpath loader is all about. I
> > > distribute my applications like this all the time. They
> all have a
> > > "templates" jar which contains four packages: screens,
> navigations,
> > > layouts and macros. In my app, I simply add e.g.
> >
> > > services.VelocityService.velocimacro.library =
> > > macros/ToolboxMacros.vm
> >
> > > and toolbox.jar contains:
> >
> > > % jar tvf
> ~/javalibs/maven/intermeta/jars/toolbox-2.0-dev.jar | grep
> > > -i vm 818 Thu Apr 10 14:02:02 CEST 2003
> macros/ToolboxMacros.vm 5679
> > > Thu Apr 10 14:02:02 CEST 2003 macros/GridMacros.vm 4826
> Thu Apr 10
> > > 14:02:02 CEST 2003 macros/IntakeMacros.vm
> >
> > > The classpath loader then finds this on the classpath and
> loads it
> > > into Velocity.
> >
> > > You might understand now, why I'm such a stickler for template
> > > naming and pathes. I don't have any template files (besides an
> > > Index.vm which is different for each installation) at all in my
> > > apps, once they're deployed.
> >
> > > You should see the eyes of my customers' engineers when
> they decide
> > > to "improve" the web layout of the application pages and
> don't find
> > > any files which contain the template pages... =:-)
> >
> > > Regards Henning
> >
> >
> >
> > >> ERic
> >
> > >> -----Original Message----- From: henning@apache.org
> > >> [mailto:henning@apache.org] Sent: Monday, April 21, 2003 2:42 PM
> > >> To: jakarta-turbine-2-cvs@apache.org Subject: cvs commit:
> > >> jakarta-turbine-2/proposals/henning/velocitymacros README
> > >> TurbineMacros.vm
> >
> >
> > >> henning 2003/04/21 11:41:32
> >
> > >> Added: proposals/henning/velocitymacros README TurbineMacros.vm
> > >> Log: First cut at actually implementing the macros that Quinton
> > >> described in HtmlPageAttributes. Please try out and report bugs.
> > >>
> > >> Revision Changes Path 1.1
> > >> jakarta-turbine-2/proposals/henning/velocitymacros/README
> > >>
> > >> Index: README
> > >>
> ===================================================================
> > >> Velocity Macros for VelocityOnlyLayout
> > >> ======================================
> > >>
> > >> These are two macros which can be used in conjunction with
> > >> VelocityOnlyLayout and HtmlPageAttributes to provide the same
> > >> Functionality as VelocityECSLayout with TemplatePageAttributes.
> > >>
> > >> These macros should be used in the Layout template like this:
> > >>
> > >> --- cut --- Layout Template --- cut ---
> > >>
> > >> ... here you should put things like setting the page
> name, adding
> > >> style sheets and so on.
> > >>
> > >> <html> #TurbineHtmlHead() #TurbineHtmlBodyStart() .... your body
> > >> information </body> </html> --- cut --- Layout Template
> --- cut ---
> > >>
> > >> As the layout template is rendered _after_ the screen
> template, you
> > >> can of course, add information to the $page tool in your screen
> > >> template. This will be added correctly to the
> <head>...</head> and
> > >> <body> tags.
> > >>
> > >>
> > >> Adding these Macros to the Turbine Code base
> > >> ============================================
> > >>
> > >> I propose to add these Macros for loading by the
> classpath loader
> > >> directly from the turbine.jar. To achieve this, the following is
> > >> added to the java:compile postGoal in maven.xml:
> > >>
> > >> <copy file="${maven.src.dir}/macros/TurbineMacros.vm"
> > >> todir="${maven.build.dest}/macros" />
> > >>
> > >> (assuming the Macro file is put into
> src/macros/TurbineMacros.vm in
> > >> the Turbine code base)
> > >>
> > >> and then adding a load instruction to the
> > >> TurbineResources.properties:
> > >>
> > >> services.VelocityService.velocimacro.library =
> > >> macros/TurbineMacros.vm
> > >>
> > >> Of course, the classpath loader must be configured (it is by
> > >> default):
> > >>
> > >> services.VelocityService.resource.loader = classpath
> > >> services.VelocityService.classpath.resource.loader.description =
> > >> Velocity Classpath Resource Loader
> > >> services.VelocityService.classpath.resource.loader.class =
> > >>
> org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> 1.1
> > >>
> jakarta-turbine-2/proposals/henning/velocitymacros/TurbineMacros.vm
> > >>
> > >> Index: TurbineMacros.vm
> > >>
> ===================================================================
> > >> ## @version $Id: TurbineMacros.vm,v 1.1 2003/04/21
> 18:41:31 henning
> > >> Exp $ ## @author <a href="mailto:hps@intermeta.de">Henning
> > >> P. Schmiedehausen</a>
> > >>
> > >> ## ## Build the <head> ... </head> tag of a web page with
> > >> VelocityOnly Layout ## #macro (TurbineHtmlHead) <head> #if
> > >> ($!page.Title) <title>$page.Title</title> #end #if
> > >> ($page.MetaTags.size() > 0) #foreach($metaTag in
> > >> $page.MetaTags.keySet()) <meta name="$metaTag"
> > >> content="$page.MetaTags.get($metaTag)"> #end #end #if
> > >> ($page.HttpEquivs.size() > 0) #foreach($httpEquiv in
> > >> $page.HttpEquivs.keySet()) <meta http-equiv="$httpEquiv"
> > >> content="$page.HttpEquivs.get($httpEquiv)"> #end #end #if
> > >> ($page.StyleSheets.size() > 0) #foreach( $styleSheet in
> > >> $page.StyleSheets ) <link rel="stylesheet" href="$styleSheet.Url"
> > >> #if($!styleSheet.Type) type="$styleSheet.Type" #end
> > >> #if($!styleSheet.Media) media="$styleSheet.Media" #end
> > >> #if($!styleSheet.Title) title="$styleSheet.Title" #end
> > >> >
> > >> #end #end #if ($page.Scripts.size() > 0) #foreach( $script in
> > >> $page.Scripts ) <script type="text/javascript" src="$script"
> > >> language="JavaScript"></script> #end #end </head> #end
> > >>
> > >> ## ## Build the <body> start tag of a web page with VelocityOnly
> > >> Layout ## #macro (TurbineHtmlBodyStart) #if
> > >> ($page.BodyAttributes.size() > 0) <body #foreach(
> $attributeName in
> > >> $page.BodyAttributes.keySet() ) $attributeName =
> > >> "$page.BodyAttributes.get($attributeName)" #end
> > >> >
> > >> #else <body> #end #end
> > >>
> > >>
> > >>
> > >>
> > >>
> >
> > >>
> -------------------------------------------------------------------
> > >> --
> > >> To unsubscribe, e-mail:
> turbine-dev-unsubscribe@jakarta.apache.org
> > >> For additional commands, e-mail:
> > >> turbine-dev-help@jakarta.apache.org
> >
> > >> ------_=_NextPart_001_01C3083C.9698EB90--
> >
> > > -- 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
> >
> > >
> --------------------------------------------------------------------
> > > -
> > > To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> turbine-dev-help@jakarta.apache.org
> >
> > --
> >
> =====================================================================
> > Jeffrey D. Brekke
> jbrekke@wi.rr.com
> > Wisconsin, USA
> brekke@apache.org
> >
> ekkerbj@yahoo.com
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: one template for all
Posted by Rodrigo Reyes <ro...@instaservi.com>.
Chris
I don't understand how the hierarchy would help. The problem we are
trying to solve here is that we would like to have our context configured in
many ways for a single template. We know we could have many screens and
select which one is going to be used from the action, but that would mean to
have many screen classes just for a single template. We think it would be
better to have a single screen class which encapsulates many of the the
different ways the context could be configured for a single template.
For example, let's say we would like to have a description filled once
an id is filled by the user in form. What we do right now is that we have an
event in the action called, which fills this information. We think this
should be placed inside the screen, but that is not possible (or at least,
is very difficult) since each screen contains only one single logic for
configuring the context. If we had many ways (many styles or events) inside
the screen, then we could place it were we think it belongs: the screen.
Am I missing your point?
Rodrigo
----- Original Message -----
From: "Chris K Chew" <ch...@fenetics.com>
To: "Turbine Developers List" <tu...@jakarta.apache.org>
Sent: Tuesday, April 22, 2003 2:47 PM
Subject: RE: one template for all
> I would try to avoid having one super-thick screen and template, as it
will
> continue to get thicker and more difficult to maintain.
>
> Instead, create a hierarchy of screen classes and abstract common
> functionality up the tree. You can do the same with your templates using
of
> combination of global macros and the #parse() command.
>
> Good luck,
>
> Chris
>
> > -----Original Message-----
> > From: Otto Cordero [mailto:ocordero@sipecom.com]
> > Sent: Tuesday, April 22, 2003 11:47 AM
> > To: Turbine Developers List
> > Subject: one template for all
> >
> >
> > Dear list,
> >
> > We have been working with Turbine in a project in which we have to
produce
> > many different html pages that differ between each other very little.
More
> > specifically, we needed to create mantainance screens for the tables in
a
> > database, so the presentation style remained consistent while the
> > html form
> > in it changed. We thought the best idea was to have one single
> > template for
> > all. This idea saved us a lot of time and we ended up having a good
> > solution. However, we had to use Turbine in a rather unusual way:
> > Since our
> > template was generic, and one template is attached to one screen, we
> > couldn't have one single screen to work for all the many different
forms.
> > Instead, the code that configures each specific was placed in Actions,
so
> > these actions work as both action and screen. We could also have had one
> > action and one screen per form (setting the screen with setScreen from
the
> > action) but given the large amount of form configurations, we thought
this
> > wasn't a good idea.
> > Given this, we have come with the idea of having Screens that may
> > build the
> > template in different ways, according to a specified
> > "screenConfig". So the
> > "screenConfig" could be setted from the http parameters or with
> > setScreen("screenName", "screenConfig"). This would work similar to
action
> > events, but in screens, so if we set the "screenConfig" to "xyz",
> > the method
> > doXyz from the Screen would be executed.
> > I am posting this to the list because I would like to hear your
> > comments on
> > this issue. Is this a good or bad idea? Can it be solved in other way?.
> >
> > Regards,
> >
> > Otto.
> >
> >
> > ----- Original Message -----
> > From: <EP...@upstate.com>
> > To: <tu...@jakarta.apache.org>
> > Sent: Tuesday, April 22, 2003 8:38 AM
> > Subject: RE: cvs commit:
jakarta-turbine-2/proposals/henning/velocitymacro
> >
> >
> > > I guess I'll plug my configuration proposal. Basically, you can edit
a
> > > turbine-configuration.xml file and point to all the properties
> > files that
> > > you might have. Of course, we would need the ability to load the
> > properties
> > > from the jar versus the file system...
> > >
> > > Eric
> > >
> > > -----Original Message-----
> > > From: jbrekke@wi.rr.com [mailto:jbrekke@wi.rr.com]
> > > Sent: Tuesday, April 22, 2003 9:16 AM
> > > To: Turbine Developers List
> > > Cc: hps@intermeta.de
> > > Subject: Re: cvs commit:
> > > jakarta-turbine-2/proposals/henning/velocitymacro
> > >
> > >
> > >
> > > Have you found a way to include properties files for your jar'd apps?
> > > We ususally have these *include*d at the bottom of the main TR.props
> > > file. It would be nice to get the properties files into the jars
> > > along with the templates and classes.
> > >
> > >
> > > >>>>> On Tue, 22 Apr 2003 08:19:38 +0000 (UTC), "Henning P.
> > Schmiedehausen"
> > > <hp...@intermeta.de> said:
> > >
> > > > EPugh@upstate.com writes:
> > > >> ------_=_NextPart_001_01C3083C.9698EB90 Content-Type: text/plain;
> > > >> charset="iso-8859-1"
> > >
> > > >> Does this mean that out of the box I could put .vm files in a jar
> > > >> (with other code like the actions etc) and share that accross
> > > >> multiple turbine apps?
> > >
> > > > Yeah, sure. That's what the classpath loader is all about. I
> > > > distribute my applications like this all the time. They all have a
> > > > "templates" jar which contains four packages: screens, navigations,
> > > > layouts and macros. In my app, I simply add e.g.
> > >
> > > > services.VelocityService.velocimacro.library =
> > > > macros/ToolboxMacros.vm
> > >
> > > > and toolbox.jar contains:
> > >
> > > > % jar tvf ~/javalibs/maven/intermeta/jars/toolbox-2.0-dev.jar | grep
> > > > -i vm 818 Thu Apr 10 14:02:02 CEST 2003 macros/ToolboxMacros.vm 5679
> > > > Thu Apr 10 14:02:02 CEST 2003 macros/GridMacros.vm 4826 Thu Apr 10
> > > > 14:02:02 CEST 2003 macros/IntakeMacros.vm
> > >
> > > > The classpath loader then finds this on the classpath and loads it
> > > > into Velocity.
> > >
> > > > You might understand now, why I'm such a stickler for template
> > > > naming and pathes. I don't have any template files (besides an
> > > > Index.vm which is different for each installation) at all in my
> > > > apps, once they're deployed.
> > >
> > > > You should see the eyes of my customers' engineers when they decide
> > > > to "improve" the web layout of the application pages and don't find
> > > > any files which contain the template pages... =:-)
> > >
> > > > Regards Henning
> > >
> > >
> > >
> > > >> ERic
> > >
> > > >> -----Original Message----- From: henning@apache.org
> > > >> [mailto:henning@apache.org] Sent: Monday, April 21, 2003 2:42 PM
> > > >> To: jakarta-turbine-2-cvs@apache.org Subject: cvs commit:
> > > >> jakarta-turbine-2/proposals/henning/velocitymacros README
> > > >> TurbineMacros.vm
> > >
> > >
> > > >> henning 2003/04/21 11:41:32
> > >
> > > >> Added: proposals/henning/velocitymacros README TurbineMacros.vm
> > > >> Log: First cut at actually implementing the macros that Quinton
> > > >> described in HtmlPageAttributes. Please try out and report bugs.
> > > >>
> > > >> Revision Changes Path 1.1
> > > >> jakarta-turbine-2/proposals/henning/velocitymacros/README
> > > >>
> > > >> Index: README
> > > >> ===================================================================
> > > >> Velocity Macros for VelocityOnlyLayout
> > > >> ======================================
> > > >>
> > > >> These are two macros which can be used in conjunction with
> > > >> VelocityOnlyLayout and HtmlPageAttributes to provide the same
> > > >> Functionality as VelocityECSLayout with TemplatePageAttributes.
> > > >>
> > > >> These macros should be used in the Layout template like this:
> > > >>
> > > >> --- cut --- Layout Template --- cut ---
> > > >>
> > > >> ... here you should put things like setting the page name, adding
> > > >> style sheets and so on.
> > > >>
> > > >> <html> #TurbineHtmlHead() #TurbineHtmlBodyStart() .... your body
> > > >> information </body> </html> --- cut --- Layout Template --- cut ---
> > > >>
> > > >> As the layout template is rendered _after_ the screen template, you
> > > >> can of course, add information to the $page tool in your screen
> > > >> template. This will be added correctly to the <head>...</head> and
> > > >> <body> tags.
> > > >>
> > > >>
> > > >> Adding these Macros to the Turbine Code base
> > > >> ============================================
> > > >>
> > > >> I propose to add these Macros for loading by the classpath loader
> > > >> directly from the turbine.jar. To achieve this, the following is
> > > >> added to the java:compile postGoal in maven.xml:
> > > >>
> > > >> <copy file="${maven.src.dir}/macros/TurbineMacros.vm"
> > > >> todir="${maven.build.dest}/macros" />
> > > >>
> > > >> (assuming the Macro file is put into src/macros/TurbineMacros.vm in
> > > >> the Turbine code base)
> > > >>
> > > >> and then adding a load instruction to the
> > > >> TurbineResources.properties:
> > > >>
> > > >> services.VelocityService.velocimacro.library =
> > > >> macros/TurbineMacros.vm
> > > >>
> > > >> Of course, the classpath loader must be configured (it is by
> > > >> default):
> > > >>
> > > >> services.VelocityService.resource.loader = classpath
> > > >> services.VelocityService.classpath.resource.loader.description =
> > > >> Velocity Classpath Resource Loader
> > > >> services.VelocityService.classpath.resource.loader.class =
> > > >> org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> 1.1
> > > >> jakarta-turbine-2/proposals/henning/velocitymacros/TurbineMacros.vm
> > > >>
> > > >> Index: TurbineMacros.vm
> > > >> ===================================================================
> > > >> ## @version $Id: TurbineMacros.vm,v 1.1 2003/04/21 18:41:31 henning
> > > >> Exp $ ## @author <a href="mailto:hps@intermeta.de">Henning
> > > >> P. Schmiedehausen</a>
> > > >>
> > > >> ## ## Build the <head> ... </head> tag of a web page with
> > > >> VelocityOnly Layout ## #macro (TurbineHtmlHead) <head> #if
> > > >> ($!page.Title) <title>$page.Title</title> #end #if
> > > >> ($page.MetaTags.size() > 0) #foreach($metaTag in
> > > >> $page.MetaTags.keySet()) <meta name="$metaTag"
> > > >> content="$page.MetaTags.get($metaTag)"> #end #end #if
> > > >> ($page.HttpEquivs.size() > 0) #foreach($httpEquiv in
> > > >> $page.HttpEquivs.keySet()) <meta http-equiv="$httpEquiv"
> > > >> content="$page.HttpEquivs.get($httpEquiv)"> #end #end #if
> > > >> ($page.StyleSheets.size() > 0) #foreach( $styleSheet in
> > > >> $page.StyleSheets ) <link rel="stylesheet" href="$styleSheet.Url"
> > > >> #if($!styleSheet.Type) type="$styleSheet.Type" #end
> > > >> #if($!styleSheet.Media) media="$styleSheet.Media" #end
> > > >> #if($!styleSheet.Title) title="$styleSheet.Title" #end
> > > >> >
> > > >> #end #end #if ($page.Scripts.size() > 0) #foreach( $script in
> > > >> $page.Scripts ) <script type="text/javascript" src="$script"
> > > >> language="JavaScript"></script> #end #end </head> #end
> > > >>
> > > >> ## ## Build the <body> start tag of a web page with VelocityOnly
> > > >> Layout ## #macro (TurbineHtmlBodyStart) #if
> > > >> ($page.BodyAttributes.size() > 0) <body #foreach( $attributeName in
> > > >> $page.BodyAttributes.keySet() ) $attributeName =
> > > >> "$page.BodyAttributes.get($attributeName)" #end
> > > >> >
> > > >> #else <body> #end #end
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > >
> > >
>> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> > > >> For additional commands, e-mail:
> > > >> turbine-dev-help@jakarta.apache.org
> > >
> > > >> ------_=_NextPart_001_01C3083C.9698EB90--
> > >
> > > > -- 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
> > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
> > >
> > > --
> > > =====================================================================
> > > Jeffrey D. Brekke jbrekke@wi.rr.com
> > > Wisconsin, USA brekke@apache.org
> > > ekkerbj@yahoo.com
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: one template for all
Posted by Chris K Chew <ch...@fenetics.com>.
I would try to avoid having one super-thick screen and template, as it will
continue to get thicker and more difficult to maintain.
Instead, create a hierarchy of screen classes and abstract common
functionality up the tree. You can do the same with your templates using of
combination of global macros and the #parse() command.
Good luck,
Chris
> -----Original Message-----
> From: Otto Cordero [mailto:ocordero@sipecom.com]
> Sent: Tuesday, April 22, 2003 11:47 AM
> To: Turbine Developers List
> Subject: one template for all
>
>
> Dear list,
>
> We have been working with Turbine in a project in which we have to produce
> many different html pages that differ between each other very little. More
> specifically, we needed to create mantainance screens for the tables in a
> database, so the presentation style remained consistent while the
> html form
> in it changed. We thought the best idea was to have one single
> template for
> all. This idea saved us a lot of time and we ended up having a good
> solution. However, we had to use Turbine in a rather unusual way:
> Since our
> template was generic, and one template is attached to one screen, we
> couldn't have one single screen to work for all the many different forms.
> Instead, the code that configures each specific was placed in Actions, so
> these actions work as both action and screen. We could also have had one
> action and one screen per form (setting the screen with setScreen from the
> action) but given the large amount of form configurations, we thought this
> wasn't a good idea.
> Given this, we have come with the idea of having Screens that may
> build the
> template in different ways, according to a specified
> "screenConfig". So the
> "screenConfig" could be setted from the http parameters or with
> setScreen("screenName", "screenConfig"). This would work similar to action
> events, but in screens, so if we set the "screenConfig" to "xyz",
> the method
> doXyz from the Screen would be executed.
> I am posting this to the list because I would like to hear your
> comments on
> this issue. Is this a good or bad idea? Can it be solved in other way?.
>
> Regards,
>
> Otto.
>
>
> ----- Original Message -----
> From: <EP...@upstate.com>
> To: <tu...@jakarta.apache.org>
> Sent: Tuesday, April 22, 2003 8:38 AM
> Subject: RE: cvs commit: jakarta-turbine-2/proposals/henning/velocitymacro
>
>
> > I guess I'll plug my configuration proposal. Basically, you can edit a
> > turbine-configuration.xml file and point to all the properties
> files that
> > you might have. Of course, we would need the ability to load the
> properties
> > from the jar versus the file system...
> >
> > Eric
> >
> > -----Original Message-----
> > From: jbrekke@wi.rr.com [mailto:jbrekke@wi.rr.com]
> > Sent: Tuesday, April 22, 2003 9:16 AM
> > To: Turbine Developers List
> > Cc: hps@intermeta.de
> > Subject: Re: cvs commit:
> > jakarta-turbine-2/proposals/henning/velocitymacro
> >
> >
> >
> > Have you found a way to include properties files for your jar'd apps?
> > We ususally have these *include*d at the bottom of the main TR.props
> > file. It would be nice to get the properties files into the jars
> > along with the templates and classes.
> >
> >
> > >>>>> On Tue, 22 Apr 2003 08:19:38 +0000 (UTC), "Henning P.
> Schmiedehausen"
> > <hp...@intermeta.de> said:
> >
> > > EPugh@upstate.com writes:
> > >> ------_=_NextPart_001_01C3083C.9698EB90 Content-Type: text/plain;
> > >> charset="iso-8859-1"
> >
> > >> Does this mean that out of the box I could put .vm files in a jar
> > >> (with other code like the actions etc) and share that accross
> > >> multiple turbine apps?
> >
> > > Yeah, sure. That's what the classpath loader is all about. I
> > > distribute my applications like this all the time. They all have a
> > > "templates" jar which contains four packages: screens, navigations,
> > > layouts and macros. In my app, I simply add e.g.
> >
> > > services.VelocityService.velocimacro.library =
> > > macros/ToolboxMacros.vm
> >
> > > and toolbox.jar contains:
> >
> > > % jar tvf ~/javalibs/maven/intermeta/jars/toolbox-2.0-dev.jar | grep
> > > -i vm 818 Thu Apr 10 14:02:02 CEST 2003 macros/ToolboxMacros.vm 5679
> > > Thu Apr 10 14:02:02 CEST 2003 macros/GridMacros.vm 4826 Thu Apr 10
> > > 14:02:02 CEST 2003 macros/IntakeMacros.vm
> >
> > > The classpath loader then finds this on the classpath and loads it
> > > into Velocity.
> >
> > > You might understand now, why I'm such a stickler for template
> > > naming and pathes. I don't have any template files (besides an
> > > Index.vm which is different for each installation) at all in my
> > > apps, once they're deployed.
> >
> > > You should see the eyes of my customers' engineers when they decide
> > > to "improve" the web layout of the application pages and don't find
> > > any files which contain the template pages... =:-)
> >
> > > Regards Henning
> >
> >
> >
> > >> ERic
> >
> > >> -----Original Message----- From: henning@apache.org
> > >> [mailto:henning@apache.org] Sent: Monday, April 21, 2003 2:42 PM
> > >> To: jakarta-turbine-2-cvs@apache.org Subject: cvs commit:
> > >> jakarta-turbine-2/proposals/henning/velocitymacros README
> > >> TurbineMacros.vm
> >
> >
> > >> henning 2003/04/21 11:41:32
> >
> > >> Added: proposals/henning/velocitymacros README TurbineMacros.vm
> > >> Log: First cut at actually implementing the macros that Quinton
> > >> described in HtmlPageAttributes. Please try out and report bugs.
> > >>
> > >> Revision Changes Path 1.1
> > >> jakarta-turbine-2/proposals/henning/velocitymacros/README
> > >>
> > >> Index: README
> > >> ===================================================================
> > >> Velocity Macros for VelocityOnlyLayout
> > >> ======================================
> > >>
> > >> These are two macros which can be used in conjunction with
> > >> VelocityOnlyLayout and HtmlPageAttributes to provide the same
> > >> Functionality as VelocityECSLayout with TemplatePageAttributes.
> > >>
> > >> These macros should be used in the Layout template like this:
> > >>
> > >> --- cut --- Layout Template --- cut ---
> > >>
> > >> ... here you should put things like setting the page name, adding
> > >> style sheets and so on.
> > >>
> > >> <html> #TurbineHtmlHead() #TurbineHtmlBodyStart() .... your body
> > >> information </body> </html> --- cut --- Layout Template --- cut ---
> > >>
> > >> As the layout template is rendered _after_ the screen template, you
> > >> can of course, add information to the $page tool in your screen
> > >> template. This will be added correctly to the <head>...</head> and
> > >> <body> tags.
> > >>
> > >>
> > >> Adding these Macros to the Turbine Code base
> > >> ============================================
> > >>
> > >> I propose to add these Macros for loading by the classpath loader
> > >> directly from the turbine.jar. To achieve this, the following is
> > >> added to the java:compile postGoal in maven.xml:
> > >>
> > >> <copy file="${maven.src.dir}/macros/TurbineMacros.vm"
> > >> todir="${maven.build.dest}/macros" />
> > >>
> > >> (assuming the Macro file is put into src/macros/TurbineMacros.vm in
> > >> the Turbine code base)
> > >>
> > >> and then adding a load instruction to the
> > >> TurbineResources.properties:
> > >>
> > >> services.VelocityService.velocimacro.library =
> > >> macros/TurbineMacros.vm
> > >>
> > >> Of course, the classpath loader must be configured (it is by
> > >> default):
> > >>
> > >> services.VelocityService.resource.loader = classpath
> > >> services.VelocityService.classpath.resource.loader.description =
> > >> Velocity Classpath Resource Loader
> > >> services.VelocityService.classpath.resource.loader.class =
> > >> org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> 1.1
> > >> jakarta-turbine-2/proposals/henning/velocitymacros/TurbineMacros.vm
> > >>
> > >> Index: TurbineMacros.vm
> > >> ===================================================================
> > >> ## @version $Id: TurbineMacros.vm,v 1.1 2003/04/21 18:41:31 henning
> > >> Exp $ ## @author <a href="mailto:hps@intermeta.de">Henning
> > >> P. Schmiedehausen</a>
> > >>
> > >> ## ## Build the <head> ... </head> tag of a web page with
> > >> VelocityOnly Layout ## #macro (TurbineHtmlHead) <head> #if
> > >> ($!page.Title) <title>$page.Title</title> #end #if
> > >> ($page.MetaTags.size() > 0) #foreach($metaTag in
> > >> $page.MetaTags.keySet()) <meta name="$metaTag"
> > >> content="$page.MetaTags.get($metaTag)"> #end #end #if
> > >> ($page.HttpEquivs.size() > 0) #foreach($httpEquiv in
> > >> $page.HttpEquivs.keySet()) <meta http-equiv="$httpEquiv"
> > >> content="$page.HttpEquivs.get($httpEquiv)"> #end #end #if
> > >> ($page.StyleSheets.size() > 0) #foreach( $styleSheet in
> > >> $page.StyleSheets ) <link rel="stylesheet" href="$styleSheet.Url"
> > >> #if($!styleSheet.Type) type="$styleSheet.Type" #end
> > >> #if($!styleSheet.Media) media="$styleSheet.Media" #end
> > >> #if($!styleSheet.Title) title="$styleSheet.Title" #end
> > >> >
> > >> #end #end #if ($page.Scripts.size() > 0) #foreach( $script in
> > >> $page.Scripts ) <script type="text/javascript" src="$script"
> > >> language="JavaScript"></script> #end #end </head> #end
> > >>
> > >> ## ## Build the <body> start tag of a web page with VelocityOnly
> > >> Layout ## #macro (TurbineHtmlBodyStart) #if
> > >> ($page.BodyAttributes.size() > 0) <body #foreach( $attributeName in
> > >> $page.BodyAttributes.keySet() ) $attributeName =
> > >> "$page.BodyAttributes.get($attributeName)" #end
> > >> >
> > >> #else <body> #end #end
> > >>
> > >>
> > >>
> > >>
> > >>
> >
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> > >> For additional commands, e-mail:
> > >> turbine-dev-help@jakarta.apache.org
> >
> > >> ------_=_NextPart_001_01C3083C.9698EB90--
> >
> > > -- 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
> >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
> >
> > --
> > =====================================================================
> > Jeffrey D. Brekke jbrekke@wi.rr.com
> > Wisconsin, USA brekke@apache.org
> > ekkerbj@yahoo.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org