You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Gary Lawrence Murphy <ga...@canada.com> on 2001/06/11 22:06:24 UTC
Questions about Turbine page contexts, and screens within pages
Here's the naiive plan for my webapp:
1) I have an index page that may return one of two XML pages
depending on the GET data. With no data, it uses Index.vm and
the default page layout with headers, footers and nav just like
in the TDK.
(this is to support legacy interfaces, so there's no option of using
actions; the page select must be driven by the data requested)
2) If the first case parm is defined, it uses Index.doBuildTemplate and
calls data.setLayoutTemplate("Page1.vm") which only has one line that
invokes a Page1Screen.vm; this lets me re-use the screen later.
- Will this cause Turbine to run a
APP.module.screens.Page1.doBuildTemplate() method or does it only
run the Index.doBuildTemplate() ?
If it doesn't call the Page1 method, I suppose I can just call it
myself directly, but is there a better way to do page chaining?
3) in the second case, Page2 must contain a URLEncoded version of Page1,
which would be simple enough if the Page1 was _not_ encoded (just insert
the Page1Screen.vm at the appropriate spot)
- Is there an easy way to hook into the template generate so the
Page2.vm layout will load a _processed_ version of the Page1.vm?
what I plan to do is to have an (as yet unknown) Velocity or
Turbine method called in doBuildTemplate to return a String
containing the expanded Page1 template, then encode this result
and place it in the context hash ... unless there is an easier
way ;)
--
Gary Lawrence Murphy <ga...@teledyn.com> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless. They can only give you answers."(Pablo Picasso)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Questions about Turbine page contexts, and screens within pages
Posted by Gary Lawrence Murphy <ga...@canada.com>.
>>>>> "J" == Jon Stevens <jo...@latchkey.com> writes:
J> Nope, you got it. The class was renamed. Submit a patch to the
J> xdoc. :-)
Were it only so simple! :) There are two candidates, one being the
VelocityECSLayout the other is VelocityOnlyLayout, and the javadocs
for both are word-for-word copies ;)
Now ... in another thread Jason made the comment of the getScreen &c
classes being cruft left over from when "Turbine was based on ECS", so
that leads me to expect that VelocityECSLayout is _also_ deprecated.
Is this true?
While on the topic of Layout classes, I place my Layout class in
modules/layouts/Default.java expecting it to be loaded when Default.vm
is built, but the class is never executed. I thought perhaps there
was some place in tr.props or some such property file where I had to
specify a path, but I could not find one for the screens and actions.
Is there another step to adding new module types such as Layouts or
scheduled events?
--
Gary Lawrence Murphy <ga...@teledyn.com> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless. They can only give you answers."(Pablo Picasso)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Questions about Turbine page contexts, and screens within
pages
Posted by Jon Stevens <jo...@latchkey.com>.
on 6/12/01 1:56 PM, "Gary Lawrence Murphy" <ga...@canada.com> wrote:
> There may be a bug in the docs, but I found this in the Velocity Site
> Howto:
>
> Now that you know how to create simple Screens, you are probably
> wondering where the layout and navigation portions of the page
> come from and how you control that. If you were not wondering
> that, then shame on you. :-) Essentially, it is the same exact
> procedure as before except you subclass VelocitySiteLayout and
> VelocitySiteNavigation instead.
>
> there is no VelocitySiteLayout in my TDK kit, the closest is
> VelocityECSLayout. Did I miss something?
Nope, you got it. The class was renamed. Submit a patch to the xdoc. :-)
-jon
--
"Open source is not available to commercial companies."
-Steve Ballmer, CEO Microsoft
<http://www.suntimes.com/output/tech/cst-fin-micro01.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Questions about Turbine page contexts, and screens within pages
Posted by Gary Lawrence Murphy <ga...@canada.com>.
There may be a bug in the docs, but I found this in the Velocity Site
Howto:
Now that you know how to create simple Screens, you are probably
wondering where the layout and navigation portions of the page
come from and how you control that. If you were not wondering
that, then shame on you. :-) Essentially, it is the same exact
procedure as before except you subclass VelocitySiteLayout and
VelocitySiteNavigation instead.
there is no VelocitySiteLayout in my TDK kit, the closest is
VelocityECSLayout. Did I miss something?
--
Gary Lawrence Murphy <ga...@teledyn.com> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless. They can only give you answers."(Pablo Picasso)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Questions about Turbine page contexts, and screens within
pages
Posted by Jon Stevens <jo...@latchkey.com>.
on 6/11/01 8:24 PM, "Gary Lawrence Murphy" <ga...@canada.com> wrote:
>>>>>> "J" == Jon Stevens <jo...@latchkey.com> writes:
>
>>> (this is to support legacy interfaces, so there's no option of
>>> using actions; the page select must be driven by the data
>>> requested)
>
> J> Actions can be specified at any time by placing the information
> J> into the query string.
>
> I'm not certain I follow. Do you mean I can alter the query string
> _after_ receiving the request? This would be very, very useful. Where
> can I do this re-writing of the query so subsequent Turbine processing
> uses the Action?
All the query/path_info/post data information is stored in the
ParameterParser class and you can modify it at any point in Turbine's
processing chain.
> I'd understood that the query string, as received from the remote
> browser, must contain the action parameter to select the action; the docs
> suggest that the action is done before just about everything else and
> I hadn't considered that I could deflect it on the fly.
If you read through Turbine.java you can see the chain of events. It is
pretty well documented in there.
> In this particular case, though, I cannot have the browser agents
> change their URLs, I must accept the old URLs they are already using,
> and those URLs do not include the action parameter -- if I can make my
> tests of the form data and then slyly insert the correct Action before
> processing continues, this is a much better plan.
That will work just fine. You can also set things up so that you execute an
Action based on the incoming URI. This is very typical of other frameworks,
but personally, I feel that it is bad design in most cases. Yours is one of
the first cases that I have seen where it would be valid, although, I would
tend to want to use mod_rewrite to add the action/Foo to the request URI
instead.
> J> ... Generally, you can always come up with another solution
> J> to chaining two Screen Modules together that ends up being a
> J> cleaner design in the long run.
>
> Ok, I'll take your word for it ;)
:-)
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Questions about Turbine page contexts, and screens within pages
Posted by Gary Lawrence Murphy <ga...@canada.com>.
>>>>> "J" == Jon Stevens <jo...@latchkey.com> writes:
>> (this is to support legacy interfaces, so there's no option of
>> using actions; the page select must be driven by the data
>> requested)
J> Actions can be specified at any time by placing the information
J> into the query string.
I'm not certain I follow. Do you mean I can alter the query string
_after_ receiving the request? This would be very, very useful. Where
can I do this re-writing of the query so subsequent Turbine processing
uses the Action?
I'd understood that the query string, as received from the remote
browser, must contain the action parameter to select the action; the docs
suggest that the action is done before just about everything else and
I hadn't considered that I could deflect it on the fly.
In this particular case, though, I cannot have the browser agents
change their URLs, I must accept the old URLs they are already using,
and those URLs do not include the action parameter -- if I can make my
tests of the form data and then slyly insert the correct Action before
processing continues, this is a much better plan.
J> ... Generally, you can always come up with another solution
J> to chaining two Screen Modules together that ends up being a
J> cleaner design in the long run.
Ok, I'll take your word for it ;)
--
Gary Lawrence Murphy <ga...@teledyn.com> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless. They can only give you answers."(Pablo Picasso)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Questions about Turbine page contexts, and screens within
pages
Posted by Jon Stevens <jo...@latchkey.com>.
on 6/11/01 1:06 PM, "Gary Lawrence Murphy" <ga...@canada.com> wrote:
>
> Here's the naiive plan for my webapp:
>
> 1) I have an index page that may return one of two XML pages
> depending on the GET data. With no data, it uses Index.vm and
> the default page layout with headers, footers and nav just like
> in the TDK.
>
> (this is to support legacy interfaces, so there's no option of using
> actions; the page select must be driven by the data requested)
Actions can be specified at any time by placing the information into the
query string.
> 2) If the first case parm is defined, it uses Index.doBuildTemplate and
> calls data.setLayoutTemplate("Page1.vm") which only has one line that
> invokes a Page1Screen.vm; this lets me re-use the screen later.
>
> - Will this cause Turbine to run a
> APP.module.screens.Page1.doBuildTemplate() method or does it only
> run the Index.doBuildTemplate() ?
>
> If it doesn't call the Page1 method, I suppose I can just call it
> myself directly, but is there a better way to do page chaining?
Screen modules should not be chained. It is a design reason. Generally, you
can always come up with another solution to chaining two Screen Modules
together that ends up being a cleaner design in the long run.
-jon
--
"Open source is not available to commercial companies."
-Steve Ballmer, CEO Microsoft
<http://www.suntimes.com/output/tech/cst-fin-micro01.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org