Jon,
On Mon, Jul 09, 2001 at 12:32:17PM -0700, Jon Stevens wrote:
> on 7/9/01 12:27 PM, "Jason Crickmer" <[EMAIL PROTECTED]> wrote:
>
> > I am sure this a pretty basic question, so please pardon my
> > newbieness.
> >
> > I have created a subclass of VelocityScreen called LWScreen.
> > LWScreen.doBuildTemplate() puts an object into the context called
> > "menu". I want this object to show up for every template page, but I
> > don't necessarily want to go and create a class for each screen. I
> > assumed that the "screen.homepage" parameter in
> > TurbineResources.properties was just what I needed, but apparently
> > not.
> >
> > Thanks in advance for your help!
> >
> > Thanks,
> > Jason
>
> #1. You shouldn't be creating Java screens. Read:
> <http://jakarta.apache.org/turbine/pullmodel.html>
Understood. To provide some quick comments, though... :)
The decision to implement "pull" or "push" really rests in the hands
of the page designers. Although there will be some advantages to
"pull", like the ability for someone creating a "wizard" to pick and
choose what data to place on what page, the "push" model is still
extremely easy to use and requires less "programming" on the part of
the page designers.
There is lots of talk about creating that boundary between content and
view. But, in the end, no tool will solve it completely (although
Turbine and Velocity are a good tool to use). It would be impossible
(in my humble estimation) to make a product that forced this boundary,
because for one application, it will be necessary to do 90% push/10%
pull, and for another, it will be %10 push/90% pull.
The question comes down to this: who programs (yes, programs) the user
flow? If you don't want your web page designers "programming"
(whether that be in Java, JSP, or VTL), then you better go 100% push
and let the application engineers do the programming (of both the
content and the user flow). But, if you want the web page designers
to do the flow programming, then go for a bigger "pull". The page
designers will have to become fluid with programming VTL, but it isn't
a difficult language to learn... just limited.
>
> #2. Create a Default.java and use that instead, but a better solution is to
> create a Global PullTool and use that.
So, it has to be named Default? And, I assume that the first default
in the module path is loaded first?
If I have a global PullTool but no default screen of my own, has does
the PullTool get added to the context? Or am I missing something
obvious...
Thanks!
Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]