Jetspeed maven plugin questions
Hi all,
just a couple of questions regarding the jetspeed maven plugin and the
build process.
It looks like the property file merge replaces the velocimacro.library
entry
in Turbine.properties Is there a trick to add a new velocimacro.library to
Turbine.properties without replacing existing library entries?
Also, what is the correct location for the modules/localization files?
We put them in the
{project_folder}/src/java/{package}/modules/localization folder.
The problem is that they are not included in the .war when we use
jetspeed:deploy.
Med vennlig hilsen/Kind regards,
Bjorn Vidar Remme
AW: When might JetSpeed 1.6 be released?
Return Receipt Your AW: When might JetSpeed 1.6 be released? document : was Bjorn Vidar Remme/Oslo/Intentia_NO/Intentia received by: at: 2004-09-03 14:30:34 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Scheduled jobs in TOMCAT/JETSPEED
Return Receipt Your AW: Scheduled jobs in TOMCAT/JETSPEED document : was Bjorn Vidar Remme/Oslo/Intentia_NO/Intentia received by: at: 2004-09-03 14:31:14 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to ensure that a pane is always selected in Jetspeed?
Return Receipt Your How to ensure that a pane is always selected in Jetspeed? document : was Bjorn Vidar Remme/Oslo/Intentia_NO/Intentia received by: at: 2004-08-19 16:14:03 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: building Jetspeed 2
Return Receipt Your RE: building Jetspeed 2 document : was Bjorn Vidar Remme/Oslo/Intentia_NO/Intentia received by: at: 2004-08-10 08:05:02 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
VelocityPortletAction, $jslink.getAction('someaction', $portlet) - Portlet not found in Context.
Hi all, (Using Jetspeed-1.6-dev) When I submit a form using $jslink.getAction() I am not able to retrieve the portlet ID from the context. I have used the $jslink.getAction(xxx, $portlet) but still my application behaves unexpected because of a null pointer exception when it tries to use fetch the portlet ID. Looking at the log and the jetspeed sources the Context object appears to be created in the GenericMVCAction.perform() method. But this is just an empty Context and the portlet is nowhere to be found. Can anybode explain why the portlet is not in the Context at this point. Is this the normal behaviour? I just need the portlet ID so that I can store some portlet specific data in the RunData object. I can submit the portlet ID as a parameter to my action but I would like to avoid that. Kind regards, Bjorn Vidar Remme
RE: Portlets execution flow
Correction* The action event does call the public void doBrowse_refresh(RunData, Context) method. There was a Null pointer Exeption thrown in there when it tried to fetch and use the portlet object in the Context . Apparently this exception caused the rundata only method to be called. Med vennlig hilsen/Kind regards, Bjorn Vidar Remme Application Engineer Bjorn Vidar Remme 09.08.2004 20:52 To: Jetspeed Users List [EMAIL PROTECTED] cc: Subject:RE: Portlets execution flow Hi Bob, What you are saying makes sense. The trouble was that I was using qualified action names, but I still had major problems. I then reluctantly came to the conclusion that there was something fundamentally wrong with my code. Looking over the code again I remember changing the form method from POST to GET because my action event would not fire if I used POST. A major mistake! Changing the method caused the action parameter in the URL to be ignored. And the code executed as if I where using $jslink alone. It took me a while to figure out what was going on. Overriding the executeEvents() methods and logging any Exceptions thrown gave me the answer. When I supply an action in the URL it looks for an event method with the signature public void doBrowse_X(RunData rundata) and not public void doBrowse_refresh(RunData, Context). No wonder my event was not triggered because I used the Context variation. I then changed my code and it worked just as you said. Brilliant! The only consequence of removing the Context as a parameter is that we must find an alternative way to get the portlet id. Probably submitting it as a parameter Thanks, you really saved the day!!! Kind regards, Bjorn Vidar Remme Bob Fleischman [EMAIL PROTECTED] 06.08.2004 18:18 Please respond to Jetspeed Users List To: 'Jetspeed Users List' [EMAIL PROTECTED] cc: Subject:RE: Portlets execution flow Bjorn: You can limit the impact of which class runs your method via the action by qualifying the action. That is: use action=Myportlet2.doUpdate rather than action=doUpdate. With the second method any portlet which has a doUpdate method will fire. As to having several Portlets share a current model. We have found that it is best to have a separate action class that modifies the model. Then using the setAction style described in this thread you can update the common model first. That action will be called before any rendering. Your portlet should then be limited to building up your context. Otherwise you are duplicating your efforts by putting model update code in 2 places. Bob -Original Message- From: Bjorn Vidar Remme [mailto:[EMAIL PROTECTED] Sent: Friday, August 06, 2004 10:41 AM To: Jetspeed Users List Subject: Re: Portlets execution flow 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
RE: Portlets execution flow
Hi Bob, What you are saying makes sense. The trouble was that I was using qualified action names, but I still had major problems. I then reluctantly came to the conclusion that there was something fundamentally wrong with my code. Looking over the code again I remember changing the form method from POST to GET because my action event would not fire if I used POST. A major mistake! Changing the method caused the action parameter in the URL to be ignored. And the code executed as if I where using $jslink alone. It took me a while to figure out what was going on. Overriding the executeEvents() methods and logging any Exceptions thrown gave me the answer. When I supply an action in the URL it looks for an event method with the signature ?public void doBrowse_X(RunData rundata)? and not ?public void doBrowse_refresh(RunData, Context)?. No wonder my event was not triggered because I used the Context variation. I then changed my code and it worked just as you said. Brilliant! The only consequence of removing the Context as a parameter is that we must find an alternative way to get the portlet id. Probably submitting it as a parameter? Thanks, you really saved the day!!! Kind regards, Bjorn Vidar Remme Bob Fleischman [EMAIL PROTECTED] 06.08.2004 18:18 Please respond to Jetspeed Users List To: 'Jetspeed Users List' [EMAIL PROTECTED] cc: Subject:RE: Portlets execution flow Bjorn: You can limit the impact of which class runs your method via the action by qualifying the action. That is: use action=Myportlet2.doUpdate rather than action=doUpdate. With the second method any portlet which has a doUpdate method will fire. As to having several Portlets share a current model. We have found that it is best to have a separate action class that modifies the model. Then using the setAction style described in this thread you can update the common model first. That action will be called before any rendering. Your portlet should then be limited to building up your context. Otherwise you are duplicating your efforts by putting model update code in 2 places. Bob -Original Message- From: Bjorn Vidar Remme [mailto:[EMAIL PROTECTED] Sent: Friday, August 06, 2004 10:41 AM To: Jetspeed Users List Subject: Re: Portlets execution flow 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
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]
Re: Portlets execution flow
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
Re: Multiple portlet instances and action event execution order
Looks like I should upgrade to Jetspeed-2 :-) I am using Jetspeed 1.6-dev for the moment and there the action event is not processed first (as far as I can tell). The order of the build normal contex calls is irrelevant as long as the action is processed first. Thanks for the reply! Med vennlig hilsen/Kind regards, Bjorn Vidar Remme Application Engineer Paul Spencer [EMAIL PROTECTED] 11.07.2004 15:17 Please respond to Jetspeed Users List To: Jetspeed Users List [EMAIL PROTECTED] cc: Subject:Re: Multiple portlet instances and action event execution order The Jetspeed-2/JSR-168 answer is: The action, without the view (buildNormalContext), is called first then each portlet's view (buildNormalContext) is called in a random order. In short, after the action is called their is no defined execution order. Paul Spencer Bjorn Vidar Remme wrote: Tanks for the reply Jeremy. Now that I knew what I was looking for, I found a lot of documentation describing how to use $link $jslink. Very useful indeed! But I still hva a problem with the executrion order of the action event build?context methods. As far as I can tell the behaviour is identical when using the following form actions: form method=post action=$jslink.getPortletById($portlet.ID) name=RundataTest form method=get action=$jslink.getAction(portlets.test.general.Rundata_TestAction, $portlet) name=RundataTest Still the order is BNC-1, AE-2, BNC-2 and not AE-2, BNC-1, BNC-2 (whree BNC is buildNormalContext and AE is the action event). In this case the action paramter is added as ?action=. Are the alternative ways to specify the action parameter in order to get the action event executed before any context builds? Med vennlig hilsen/Kind regards, Bjorn Vidar Remme Application Engineer Jeremy Ford [EMAIL PROTECTED] 08.07.2004 15:36 Please respond to Jetspeed Users List To: [EMAIL PROTECTED] cc: Subject:RE: Multiple portlet instances and action event execution order See below: From: Bjorn Vidar Remme [EMAIL PROTECTED] Reply-To: Jetspeed Users List [EMAIL PROTECTED] To: Jetspeed Users List [EMAIL PROTECTED] Subject: Multiple portlet instances and action event execution order Date: Thu, 8 Jul 2004 09:49:32 +0200 Hi all, i have a pane with multiple portlets of the same type added. Works perfectly now, this was a issue before, but it is solved nicely. Thanks to the individuals who made that possible : The portlets are configured to behave differently, but the share some common data. We store the common data in the RunData object. We can store data on three different levels: UserSace (rundata.getUser.setTemp()) , PortletgroupSpace (homebrewed) and PortletSpace (using the portlet id). This also works perfectly. My problem now is how to handle the action events fired from these portlets. If I do the following (velocity): form action=$jslink name=RundataTest method=POST input type=submit name=eventSubmit_doBrowse_refresh value=Refresh /form the doBrowse_refresh() method is called for all the portlets on the page with the same input values. This of course overwrites all the portlet unique values in rundata. The events look like this: - doBrowse_Refresh() for portlet 1 - buildNormalContext() for portlet 1 - doBrowse_Refresh() for portlet 2 - buildNormalContext() for portlet 2 I then modified the code to use the portlet id. This is based on the HTML source for the portlet controls. I manually add the portletid to the context: form action=$jslink/js_peid/$!portletid name=RundataTest method=POST input type=submit name=eventSubmit_doBrowse_refresh value=Refresh /form Is there a equivalent to $jslink that would automatically do this? $jslink.getPortletById($portlet.ID) The result was better but not as expected. Now it turned out that the ordering on the pane was important. Lets say that we click on Portlet 2 which is the portlet on the left side of the pane. The events then look like this: - buildNormalContext() for portlet 1 - doBrowse_Refresh() for portlet 2 - buildNormalContext() for portlet 2 Almost what I want! The problem now is that portlet 1 is displaying old data, because the global/group entires in rundata was updated after the buildNormalContext() method was executed. If we click on Portel 1 everything works perfectly, because the events now look like: - doBrowse_Refresh() for portlet 1 - buildNormalContext() for portlet 1 - buildNormalContext() for portlet 2 Is it possible to get the action event to always be handled first regardless of which portlet the request was sent from, i.e. the events after clicking on portlet 2 should be: -doBrowse_Refresh() for portlet 2 - buildNormalContext() for portlet 1 - buildNormalContext() for portlet 2 If you
RE: Multiple portlet instances and action event execution order
Tanks for the reply Jeremy. Now that I knew what I was looking for, I found a lot of documentation describing how to use $link $jslink. Very useful indeed! But I still hva a problem with the executrion order of the action event build?context methods. As far as I can tell the behaviour is identical when using the following form actions: form method=post action=$jslink.getPortletById($portlet.ID) name=RundataTest form method=get action=$jslink.getAction(portlets.test.general.Rundata_TestAction, $portlet) name=RundataTest Still the order is BNC-1, AE-2, BNC-2 and not AE-2, BNC-1, BNC-2 (whree BNC is buildNormalContext and AE is the action event). In this case the action paramter is added as ?action=. Are the alternative ways to specify the action parameter in order to get the action event executed before any context builds? Med vennlig hilsen/Kind regards, Bjorn Vidar Remme Application Engineer Jeremy Ford [EMAIL PROTECTED] 08.07.2004 15:36 Please respond to Jetspeed Users List To: [EMAIL PROTECTED] cc: Subject:RE: Multiple portlet instances and action event execution order See below: From: Bjorn Vidar Remme [EMAIL PROTECTED] Reply-To: Jetspeed Users List [EMAIL PROTECTED] To: Jetspeed Users List [EMAIL PROTECTED] Subject: Multiple portlet instances and action event execution order Date: Thu, 8 Jul 2004 09:49:32 +0200 Hi all, i have a pane with multiple portlets of the same type added. Works perfectly now, this was a issue before, but it is solved nicely. Thanks to the individuals who made that possible : The portlets are configured to behave differently, but the share some common data. We store the common data in the RunData object. We can store data on three different levels: UserSace (rundata.getUser.setTemp()) , PortletgroupSpace (homebrewed) and PortletSpace (using the portlet id). This also works perfectly. My problem now is how to handle the action events fired from these portlets. If I do the following (velocity): form action=$jslink name=RundataTest method=POST input type=submit name=eventSubmit_doBrowse_refresh value=Refresh /form the doBrowse_refresh() method is called for all the portlets on the page with the same input values. This of course overwrites all the portlet unique values in rundata. The events look like this: - doBrowse_Refresh() for portlet 1 - buildNormalContext() for portlet 1 - doBrowse_Refresh() for portlet 2 - buildNormalContext() for portlet 2 I then modified the code to use the portlet id. This is based on the HTML source for the portlet controls. I manually add the portletid to the context: form action=$jslink/js_peid/$!portletid name=RundataTest method=POST input type=submit name=eventSubmit_doBrowse_refresh value=Refresh /form Is there a equivalent to $jslink that would automatically do this? $jslink.getPortletById($portlet.ID) The result was better but not as expected. Now it turned out that the ordering on the pane was important. Lets say that we click on Portlet 2 which is the portlet on the left side of the pane. The events then look like this: - buildNormalContext() for portlet 1 - doBrowse_Refresh() for portlet 2 - buildNormalContext() for portlet 2 Almost what I want! The problem now is that portlet 1 is displaying old data, because the global/group entires in rundata was updated after the buildNormalContext() method was executed. If we click on Portel 1 everything works perfectly, because the events now look like: - doBrowse_Refresh() for portlet 1 - buildNormalContext() for portlet 1 - buildNormalContext() for portlet 2 Is it possible to get the action event to always be handled first regardless of which portlet the request was sent from, i.e. the events after clicking on portlet 2 should be: -doBrowse_Refresh() for portlet 2 - buildNormalContext() for portlet 1 - buildNormalContext() for portlet 2 If you want your action to fire first before any portlets are rendered, you will need to specify the action parameter in the url. This will cause your event to fire first. Med vennlig hilsen/Kind regards, Bjorn Vidar Remme Application Engineer Jeremy Ford [EMAIL PROTECTED] _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Multiple portlet instances and action event execution order
Hi all, i have a pane with multiple portlets of the same type added. Works perfectly now, this was a issue before, but it is solved nicely. Thanks to the individuals who made that possible : The portlets are configured to behave differently, but the share some common data. We store the common data in the RunData object. We can store data on three different levels: UserSace (rundata.getUser.setTemp()) , PortletgroupSpace (homebrewed) and PortletSpace (using the portlet id). This also works perfectly. My problem now is how to handle the action events fired from these portlets. If I do the following (velocity): form action=$jslink name=RundataTest method=POST input type=submit name=eventSubmit_doBrowse_refresh value=Refresh /form the doBrowse_refresh() method is called for all the portlets on the page with the same input values. This of course overwrites all the portlet unique values in rundata. The events look like this: - doBrowse_Refresh() for portlet 1 - buildNormalContext() for portlet 1 - doBrowse_Refresh() for portlet 2 - buildNormalContext() for portlet 2 I then modified the code to use the portlet id. This is based on the HTML source for the portlet controls. I manually add the portletid to the context: form action=$jslink/js_peid/$!portletid name=RundataTest method=POST input type=submit name=eventSubmit_doBrowse_refresh value=Refresh /form Is there a equivalent to $jslink that would automatically do this? The result was better but not as expected. Now it turned out that the ordering on the pane was important. Lets say that we click on Portlet 2 which is the portlet on the left side of the pane. The events then look like this: - buildNormalContext() for portlet 1 - doBrowse_Refresh() for portlet 2 - buildNormalContext() for portlet 2 Almost what I want! The problem now is that portlet 1 is displaying old data, because the global/group entires in rundata was updated after the buildNormalContext() method was executed. If we click on Portel 1 everything works perfectly, because the events now look like: - doBrowse_Refresh() for portlet 1 - buildNormalContext() for portlet 1 - buildNormalContext() for portlet 2 Is it possible to get the action event to always be handled first regardless of which portlet the request was sent from, i.e. the events after clicking on portlet 2 should be: -doBrowse_Refresh() for portlet 2 - buildNormalContext() for portlet 1 - buildNormalContext() for portlet 2 Med vennlig hilsen/Kind regards, Bjorn Vidar Remme Application Engineer
Jetspeed1.5 using Maven
Return Receipt Your Jetspeed1.5 using Maven document : was Bjorn Vidar Remme/Oslo/Intentia_NO/Intentia received by: at: 2004-06-24 10:56:06 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
