I have an addition to the context problem:
I posted about the issue with the different contexts depending on what
happens
quite a while ago
(around August),
for some reason it went under in the traffic,
As it seems the doPerform and the events in 1.4b1 get different contexts
(as you described one for the turbine the other for jetspeed)
I used a different workaround to this problem.
I settled down to ignore the passed context and
generated my own app specific context which then was
corrently installed in the application.
Here is my approach to the problem:
I extracted the code generation for the context
(I´m not sure if my naming is different to the one of the
core system contexts, doesn´t really matter anyway)
protected Context getActionContext(RunData data) {
Context context = (Context)
data.getTemplateInfo().getTemplateContext("VelocityActionContext");
if(context == null) {
context = TurbineVelocity.getContext();
data.getTemplateInfo().setTemplateContext("VelocityActionContext",contex
t);
}
return context;
}
And instead of using the served context I simply do a quick call to my
getActionContext
to fetch my internal context:
public void doPerform(RunData data, Context context) {
context = super.getActionContext(data);
Later in the template I fetch the context into a local variable
for later processing:
#set($myActionContext =
$data.getTemplateInfo().getTemplateContext('VelocityActionContext'))
Then you simply deal with it like with ever other Velocity variable by
simply accessing the data stored in the new context variable:
#if($lcActionContext.target &&
$lcActionContext.target.equalsIgnoreCase("VotingExecute"))
-----Ursprüngliche Nachricht-----
Von: Glenn R. Golden [mailto:ggolden@;umich.edu]
Gesendet: Mittwoch, 23. Oktober 2002 14:34
An: Jetspeed Users List
Betreff: Re: Jetspeed BUG???
If in your form that has the submit that triggered the doUpdate, there
is an 'action' parameter (with the class name of your Action class),
then the request will be handled by the Turbine action mechanism, not
the Velocity action mechanism. The difference is that from Turbine,
only your action class is called - with velocity, all the portlets on
the page get a shot at responding to the submit. Also, with Turbine,
the action is processed BEFORE any of the page is composed - with
velocity, the action is processed as part of each portlet's
composition. An action call handled by Turbine can do a redirect - one
handled by velocity cannot (output has already been sent to the
browser).
The key difference in this case is that the context is new or missing
when using the Turbine action processing, but will be there as expected
when using the velocity action processing.
We exclusively use the Turbine action processing in our Jetspeed work.
We just ignore the context parameter to the do... routines.
When doing Turbine action processing, the do... routine will be called,
then all the portlets will be composed, so your build routine will also
be called. Nice separation between input processing and output. With
velocity, only the do.... routine will be called, it must setup the
context for the output as well as process the input.
All controlled by having or not the 'action' form field or url
parameter.
- Glenn
---------------------------------------------------------------------
Glenn R. Golden Systems Research Programmer
School of Information University of Michigan
[EMAIL PROTECTED] 734-615-1419
---------------------------------------------------------------------
--
To unsubscribe, e-mail:
<mailto:jetspeed-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail:
<mailto:jetspeed-user-help@;jakarta.apache.org>
