Put another way. Screen's are Java classes that are responsible
generating the response. In most cases when using templates you have no
need to use get/setScreen as the java module associated with a template
is found using the configured template service (of which there is
currently only one possibility). Specifying Screens manually can be
helpful when not using a template system or in a combination system that
has some need to generate a binary response. A screen template is the
main content template within a layout template. The difference between
a screen template and a navigation template is that there is only one
screen template per layout and the screen template determines the layout
template that is used.
This style of layout/navigation/screen is useful for the majority of
apps, though the portal style is also important and in this case there
is no distinction of one "navigation" template that is superior to
others and is called a "screen". Turbine3 intends to make this form of
layout easier to develop and the current layout/nav/screen to be a
special case.
The use of binary and template responses is not completely worked out in
Turbine3 to my knowledge.
In Turbine2 a screen template is referenced by
http://host/servlet/app/template/MyTemplate.vm
A java class is specified by
http://host/servlet/app/screen/MyFile
where there is a mypackage.screens.MyFile class in the app classpath and
mypackage is given in the module.packages
The reason for using "screen" as the keyword for the java module is
historical and has existed before any template integration into Turbine.
john mcnally
Jason van Zyl wrote:
>
> On 9/14/01 12:13 AM, "Jeff Zhu" <[EMAIL PROTECTED]> wrote:
>
> > Would you please explain the difference between "getScreen" and
> > "getScreenTemplate", "setScreen" and "setScreenTemplate" in the RunData?
>
> In almost all cases you should not need to reference the getScreen/setScreen
> methods. Screens are modules in Turbine and modules, in the current Turbine
> jargon, are responsible for populating contexts. I call them context
> builders and generally there is a context builder that corresponds to the
> template currently being rendered.
>
> In most cases the context builder, or module, is found for you by the logic
> internal to Turbine. Though there is a trend I see where a set of users gets
> mapped to use a particular layout, or more generally an arbitrary parmeter
> alters the rendering. In Turbine 3.0 this question will be more aptly stated
> as "how do I invoke the use of sibling module with a general parameter that
> will ultimately affect the rendering?". In Turbine 3.0 there are no such
> things as screens, navigations and layouts. There are just modules and they
> can be aggregated in an arbitrary fashion to render content.
>
> > Thanks,
> >
> > Jeff
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
> ---------------------------------------------------------------------
> 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]
