Hi all,
Well the trouble by using setAction() is that the action is executed for
all the portlets (if a suitable method exists). You can easily test this
by adding multiple instances of the same portlet to a page (same action
class) or multiple portlets with different action classes but the same
event name. You will then see that the action event is executed once for
all the portlets.
The pattern is thus (AE=action event, BNC=buildNormalContext):
AE for portlet A, BNC for portlet A, AE for portlet B, BNC for portlet B
etc..
Not what we want at all, we just want the action event to fire once.
This is why I specify the portlet ID in the action like this:
$jslink.getAction("myaction", $portlet)
The action event is then executed only once, but as I described in my
previous post the pattern is (clicking on portlet B): BNC-A, AE -B, BNC-B
and not the desired AE-B, BNC-A, BNC-B.
Note: I am using getAction() because setAction() is deprecated according
to the documentation. It does the same thing.
Kind regards,
Bjorn Vidar Remme
[EMAIL PROTECTED]
06.08.2004 15:54
Please respond to "Jetspeed Users List"
To: "Jetspeed Users List" <[EMAIL PROTECTED]>
cc:
Subject: Re: Portlets execution flow
Bjorn, Oscar -
I have never seen the problems you are mentioning below - my action
handler methods ALWAYS execute before the build*() methods on the active
portlets. We are currently using Velocity-based portlets. When we
specify the action parameter in a form, we use the following code
template:
<form method="post" action="$jslink">
or
<form method="post" action="$jslink.setAction("portlets.FooAction")">
The first version uses the "default" action as specified in the xreg for
the portlet - this is what we use in most cases. The second version uses
any action you specify - as long as the action package you are using is
declared to Turbine using the "module.packages" key (see
TurbineResources.properties, and look for that key.)
For an example of the first version, look at the source in
/tutorial/tutorials/9/templates/vm/portlets/html/coffees-browser.vm
(directly from cvs) as well as the related xreg files. An example of the
second version is at:
http://portals.apache.org/jetspeed-1/tutorial/7/events.html.
Good luck,
Eric
Bjorn Vidar Remme <[EMAIL PROTECTED]>
08/06/2004 04:10 AM
Please respond to
"Jetspeed Users List" <[EMAIL PROTECTED]>
To
"Jetspeed Users List" <[EMAIL PROTECTED]>
cc
Subject
Re: Portlets execution flow
Hi Oscar,
Note: This answer does not solve your problem, it only confirms it. Read
on if you are interested.
We are using Jetspeed 1.6-dev and we struggle with the same problem
(Velocity portlets in our case). The idea was to have multiple portlets on
the page share information stored in rundata. The BuildNormalContext()
method builds the context based entirely on data stored in rundata. We use
a system to store data in the rundata based on portlet id / portlet group
(parameter) and global for all.
We then write action handlers that performs all the logic and updates the
rundata.
Of course this relies on the fact that the action event is executed BEFORE
the buildNormaContext() methods are executed.
Specifying the action for a specific portlet like this:
<form action="$jslink.getPortletById($portlet.ID)" name="RundataTest"
method="GET">
or this:
<form
action="$jslink.getAction("portlets.test.general.Rundata_TestAction",
$portlet)" name="RundataTest" method="GET">
executes the action specifically for that particular portlet. Exactly what
we wanted.
But, then we noticed that the some of the portlets displayed old data!
The pattern for the problem was top->bottom->left->right as you describe.
Lets say we have two portlets A & B (AE=Action Event,
BNC=BuildNormalContext).
1. Clicking on portlet A executes: AE for A -> BNC for A -> BNC for B
(Perfect!).
2. Clicking on portlet B executes: BNC for A -> AE for B -> BNC for B
(Disaster!)
In case 2 portlet A is diplayed using old values from the rundata object.
Oh dear...
The only answer I have received on this problem is that in JSR168
(Jetspeed-2 implements this) the action event should always be executed
before the portlets are rendered in an undefined order.
Very cute, but migrating to Jetspeed-2 is not an option for the moment.
It would be nice to get an opinion from an experienced Jetspeed developer
on how much work it would be to modifiy Jetspeed-1 to behave in this way
to.
Right now we have to be really careful when planning the actions/flow in
the portal and this is quite a limitation for the moment.
Kind regards,
Bjorn Vidar Remme
"Oscar Ruiz" <[EMAIL PROTECTED]>
05.08.2004 13:33
Please respond to "Jetspeed Users List"
To: "'Jetspeed Users List'" <[EMAIL PROTECTED]>
cc:
Subject: Portlets execution flow
Hi all,
can anyone clarify me how multiple MVC portlets (JSP for instance) are
executed and output displayed?
There is obviously an order in which portlet controllers are called,
apparently from top to bottom and left to right.
*apparently* the View component (JSP) is executed right after the
Controller, hence if portlets are sharing a Model the whole thing results
in
a disaster.
Is there a way of rendering the page (i.e. execute the View components)
after all controllers have completed?
Many thanks.
Oscar.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
