on 7/9/01 12:59 PM, "Jason Crickmer" <[EMAIL PROTECTED]> wrote:
> 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.
Nope. With that statement, I don't think you understand how Pull works. Pull
is created by the Java engineers and used by the page designers. It is an
API to work by.
> 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.
Pull requires less programming on the part of page designers because they
will not be bound to what a Java programmer gives them for each and every
page. What you are proposing is the creation of a Java class for each page.
If you want to modify the page in order to add something to it, then you
have to also modify the Java class file. That is bad.
> 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.
Scarab is 99.9999% Pull.
> The question comes down to this: who programs (yes, programs) the user
> flow?
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".
Again, I don't quite think you understand the concept of Pull very well. The
objects in the Pull model is the same as the Push model. The difference
between the two is the use of those objects.
> The page
> designers will have to become fluid with programming VTL, but it isn't
> a difficult language to learn... just limited.
How is VTL limited?
Also, the page designers are not the people programming VTL, it is the
template engineers. See past discussions for the differences between all of
the different roles on a project.
>>
>> #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?
Read:
How the templates are found
<http://jakarta.apache.org/turbine/howto/velocity-site-howto.html>
Configuration for the name of the default file is defined in the TR.props
file.
> 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...
It is a Tool and will be added to the context for you by the PullService.
Read: http://jakarta.apache.org/turbine/services/pull-service.html
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
