RE: How to correctly Java Script with Jetspeed ?
We use them in each portlet, and friendly up the javascript names (make them unique) using the Portlet ID, this way you can have common javascript names you reference in your portlets using the portletid. We had to muck the JS_PEID to remove the hyphens, as they didn't work well together. -Original Message- From: Hampton, Thomas [mailto:[EMAIL PROTECTED] Sent: Thursday, October 21, 2004 3:07 PM To: [EMAIL PROTECTED] Subject: How to correctly Java Script with Jetspeed ? I'm having problems using Java Script in portlets because I don't know the correct place to put the function definitions. Java Script functions are supposed to be defined in the HEAD section to make sure that the scripts are loaded before they can possibly be called, but the HTML for portlets don't have HEAD tags. I'm using Jetspeed 1, is this handled differently in Jetspeed 2 ? I've scanned the discussion forums and found the following suggestions. 1) JavaScript does not need to be in the HEAD tag just put it in the body, that it was just convention that it's put in the HEAD tag. This is kind of true, the Java Script documentation says the following: Generally, you should define the functions for a page in the HEAD portion of a document. That way, all functions are defined before any content is displayed. Otherwise, the user might perform an action while the page is still loading that triggers an event handler and calls an undefined function, leading to an error. The question is then, what else, besides putting the script definitions in the HEAD tag, can you do to guarantee that the functions are defined before content is displayed. Different browsers process the content differently. I have not been having problems with IE but in Mozilla, if you are quick, it's possible to click a link that triggers some script that has not yet been processed. 2) Override the JetSpeed template file and put all the JavaScript into the HEAD tag there. This would mean that all my script would have to be in the portal layout pages because that's where the HEAD tags are: templates\jsp\layouts\html\content.jsp templates\jsp\layouts\html\default.jsp templates\jsp\layouts\html\previous.jsp And that it would be loaded all the time whether it's needed or not for any page in the portal. This is pretty non-elegant solution, especially if you have a lot of script in your portal, but it would work. 3) It was suggested that other portals have a way to add content dynamically (maybe I misunderstood this one) into the HEAD tag. Here's a questions/suggestion from me : Is it possible in Jetspeed to include the HEAD tags in the portlet's HTML and have the portlet code (HTML portlet) merge the contents of the HEAD tags from all portlets on a page together before sending the HTML to the browser ? Seems like this would solve the problem. I would like to hear what everyone else thinks, as I've not yet discovered a workable solution that I'm happy with. Thanks, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Handling errors in customize mode
You can do this if you do not specify an action in your form form /form This way, it posts back to itself (still under buildconfigurecontext), you can handle the request. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 12:32 PM To: Jetspeed Users List Subject: Fw: Handling errors in customize mode Has anyone done this? Hello - We are writing a portlet in Jetspeed 1.5 for which we are providing our own customizer (provides.customization=true.) The customizer has a number of data entry fields, which the user could fill in incorrectly. We would like to validate the entered data in an action method (doUpdate() for example,) and return them to the customize screen if there is an error. Is there a way to return the user to the customize view from your doX() methods? I have tried a number of things... none of which seemed to work. This is pretty much a show-stopper for us at the moment... any help would be greatly appreciated! Thanks, Eric Olson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Changing Default Customize page
Either add a parameter in your portlet definition in the xreg: parameter name=provides.customization value=true hidden=true/ or (read this works but haven't tried it) create a providesCustomization which returns true in your action class. We have found an issue however, see http://nagoya.apache.org/jira/browse/JS1-520 for more information. -Art -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, October 07, 2004 8:15 AM To: [EMAIL PROTECTED] Subject: Changing Default Customize page I want to change the customize page of my portlet from using the default cutomize page to my own customize page but still using the default customize action. I am using VM. Any assistance would be appreciated. - 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]
RE: Changing Default Customize page
The action class takes care of that per my first response to your question. If you do not tell Jetspeed that you action class provides it's own customization, it uses the default. The setTemplate method tells the action class to display that customizer vm file, versus the default. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, October 07, 2004 8:50 AM To: [EMAIL PROTECTED] Subject: RE: Changing Default Customize page Let me get this right...hopefully. The user hits the customize button in the top right of the portlet and I want my customize page displayed. So how do I tell the portlet that it must use my customize portlet and not the default. From what you have said I would need to write an action class with a buildConfigureContext method, and myCustomizationPage.vm can just use the default customize action. Apologies if appearing dense !!! Jon Hawkins That is done in the action class... In the action class, you implement the buildConfigureContext method, and invoke the setTemplate method. Eg. setTemplate(rundata, myCustomizationPage.vm); -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, October 07, 2004 8:32 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Changing Default Customize page Thanks for the quick reply, but how do I tell my portlet to use myCustomizationPage.vm and not the default ? Thanks Jon Hawkins Either add a parameter in your portlet definition in the xreg: parameter name=provides.customization value=true hidden=true/ or (read this works but haven't tried it) create a providesCustomization which returns true in your action class. We have found an issue however, see http://nagoya.apache.org/jira/browse/JS1-520 for more information. -Art -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, October 07, 2004 8:15 AM To: [EMAIL PROTECTED] Subject: Changing Default Customize page I want to change the customize page of my portlet from using the default cutomize page to my own customize page but still using the default customize action. I am using VM. Any assistance would be appreciated. - 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] - 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] - 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]
RE: Changing Default Customize page
What class did you extend in your action class. The velocity action class
should look like:
protected void buildConfigureContext( VelocityPortlet portlet,
Context context,
RunData rundata )
{
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 9:13 AM
To: [EMAIL PROTECTED]
Subject: RE: Changing Default Customize page
I have added parameter name=provides.customization value=true
hidden=true/ top my portlet and have put the following in my action class
protected void buildConfigureContext(Portlet portlet, Context context,
RunData rundata) throws Exception
{
setTemplate(rundata, CedArFavourites.vm);
}
When I debug this in eclipse, buildNormalContext gets called but
buildConfigureContext doesn't !!
Any further assistance appreciated
The action class takes care of that per my first response to your
question. If you do not tell Jetspeed that you action class provides
it's own customization, it uses the default.
The setTemplate method tells the action class to display that
customizer vm file, versus the default.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 8:50 AM
To: [EMAIL PROTECTED]
Subject: RE: Changing Default Customize page
Let me get this right...hopefully.
The user hits the customize button in the top right of the portlet and
I want my customize page displayed. So how do I tell the portlet that
it must use my customize portlet and not the default.
From what you have said I would need to write an action class with a
buildConfigureContext method, and myCustomizationPage.vm can just use
the default customize action.
Apologies if appearing dense !!!
Jon Hawkins
That is done in the action class... In the action class, you implement
the buildConfigureContext method, and invoke the setTemplate method.
Eg.
setTemplate(rundata, myCustomizationPage.vm);
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 8:32 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Changing Default Customize page
Thanks for the quick reply, but how do I tell my portlet to use
myCustomizationPage.vm and not the default ?
Thanks
Jon Hawkins
Either add a parameter in your portlet definition in the xreg:
parameter name=provides.customization value=true
hidden=true/
or (read this works but haven't tried it) create a
providesCustomization
which returns true in your action class.
We have found an issue however, see
http://nagoya.apache.org/jira/browse/JS1-520 for more information.
-Art
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 8:15 AM
To: [EMAIL PROTECTED]
Subject: Changing Default Customize page
I want to change the customize page of my portlet from using the
default cutomize page to my own customize page but still using the
default customize action. I am using VM.
Any assistance would be appreciated.
-
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]
-
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]
-
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]
-
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]
RE: Changing Default Customize page
I don't think you can mix and match, is your normal portlet a JSP or VM ?
If it's a JSP, you will need to use a JSP customizer (we initially tried
mixing them, but were unable to get that to work)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 10:12 AM
To: [EMAIL PROTECTED]
Subject: RE: Changing Default Customize page
What is happaening is that when buildConfigureContext is called it is
trying to set the template to CedArFavourites.jsp. My portlet action class
extends JspPortletAction, without the new buildConfigureContext it sets the
template to a vm, with the new method it tries to load a jsp !!
Any ideas.
Thanks very much for your assistance
Jon Hawkins
What class did you extend in your action class. The velocity action
class should look like:
protected void buildConfigureContext( VelocityPortlet portlet,
Context context,
RunData rundata )
{
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 9:13 AM
To: [EMAIL PROTECTED]
Subject: RE: Changing Default Customize page
I have added parameter name=provides.customization value=true
hidden=true/ top my portlet and have put the following in my action
class
protected void buildConfigureContext(Portlet portlet, Context context,
RunData rundata) throws Exception
{
setTemplate(rundata, CedArFavourites.vm);
}
When I debug this in eclipse, buildNormalContext gets called but
buildConfigureContext doesn't !!
Any further assistance appreciated
The action class takes care of that per my first response to your
question. If you do not tell Jetspeed that you action class provides
it's own customization, it uses the default.
The setTemplate method tells the action class to display that
customizer vm file, versus the default.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 8:50 AM
To: [EMAIL PROTECTED]
Subject: RE: Changing Default Customize page
Let me get this right...hopefully.
The user hits the customize button in the top right of the portlet and
I want my customize page displayed. So how do I tell the portlet that
it must use my customize portlet and not the default.
From what you have said I would need to write an action class with a
buildConfigureContext method, and myCustomizationPage.vm can just use
the default customize action.
Apologies if appearing dense !!!
Jon Hawkins
That is done in the action class... In the action class, you
implement the buildConfigureContext method, and invoke the
setTemplate method.
Eg.
setTemplate(rundata, myCustomizationPage.vm);
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 8:32 AM
To: [EMAIL PROTECTED];
[EMAIL PROTECTED] Subject: RE: Changing Default
Customize page
Thanks for the quick reply, but how do I tell my portlet to use
myCustomizationPage.vm and not the default ?
Thanks
Jon Hawkins
Either add a parameter in your portlet definition in the xreg:
parameter name=provides.customization value=true
hidden=true/
or (read this works but haven't tried it) create a
providesCustomization
which returns true in your action class.
We have found an issue however, see
http://nagoya.apache.org/jira/browse/JS1-520 for more information.
-Art
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 8:15 AM
To: [EMAIL PROTECTED]
Subject: Changing Default Customize page
I want to change the customize page of my portlet from using the
default cutomize page to my own customize page but still using the
default customize action. I am using VM.
Any assistance would be appreciated.
-
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]
-
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]
-
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]
Proper way to exit customization mode when provides.customization=true
We have an issue, which appears to be a bug, where a portlet with an action class which provides it's own customization front end has no way of properly exiting the customization view. Eg, We properly get the custom edit page, however, when canceling, or updating, we return to a view which no longer has the navigational tabs. We must execute any portlet control.Restore method on the page to return the page back to normal view (the other portlets which normally would be present in normal/restore view are in fact visible, just the tab buttons at the top are missing) We've tried mimicking the generic customize doCancel functionality to no avail. I've checked the state of the portlet throughout, and it does get reset back to 0 after the doUpdate/doCancel, however, there still remain no navigational tabs at the top. Any insights or pointers would greatly be appreciated. -Arthur
RE: After Maximize Protlet, buildNormalContext not Called
We are seeing this problem in JS 1.5, does anyone have a bug to reference? I did not see any open or closed issues resembling this post. Does anyone have a workaround. This is the issue ASturtz posted subject 'Portlet state problem' this afternoon. -Art - From: Dmitry Sklyut Subject: RE: After Maximize Protlet, buildNormalContext not Called Date: Thu, 12 Feb 2004 06:39:41 -0800 That is what I saw also. Handling of the js_peid is not consistent as well as handling of template. They just don't get reset correctly. This is still a problem in b4 and 1.4 final. Dmitry -Original Message- From: Boyd, David [mailto:[EMAIL PROTECTED] Sent: Thursday, February 12, 2004 9:36 AM To: 'Jetspeed Users List' Cc: Dmitry Sklyut Subject: RE: After Maximize Protlet, buildNormalContext not Called After further investigation, your comments make sense. There seems to be a bug in the way Jetspeed 1.4b3 handles a portlet when it is maximized, restored or minimized. After digging around and outputting rundata, saw that when you maximized a portlet, the js_peid is set to the portlet that is maximized. When you then select a link off of that page to go to a completely different psml, the Jetspeed:pane tag lib is called, it checks to see if the js_peid is set, if so, then it uses that value to look for a portlet in the psml file, if it is not set then it uses the name to locate the portlet. Since the psml does not have any portlets with that js_peid, we get the blank screen. The solution was to modify the MAXIMAZE, RESTORE and MINIMIZE classes along with the pane taglib class. Added a new key,value pair to the temp storage to control the behavior. This mailbox protected from junk email by Matador from MailFrontier, Inc. http://info.mailfrontier.com http://info.mailfrontier.com/ -Original Message- From: Dmitry Sklyut [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 10, 2004 5:42 PM To: 'Jetspeed Users List' Subject: RE: After Maximize Protlet, buildNormalContext not Called I saw that happen with forwards that forwarded to a pane. All works fine if forwarded to a portlet. I think it happens because rundata keeps the old js_peid and tries to render the portlet with that old js_peid. Dmitry -Original Message- From: Boyd, David [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 10, 2004 5:39 PM To: Jetspeed Users List Subject: After Maximize Protlet, buildNormalContext not Called I have a page where there are 2 columns of 5 rows of portals. If a user maximizes a given portlet, and then selects a link from that portlet, the user is taken to the correct page, as indicated by the URL, but no content is displayed except for the following /. If the user navigates back to the original page, selects the restore icon, then selects same link on the same portlet, the user is taken to the same page, but, now there is content. Any ideal as to why this occurs. _ This mailbox protected from junk email by Matador from MailFrontier, Inc. http://info.mailfrontier.com http://info.mailfrontier.com/ http://info.mailfrontier.com http://info.mailfrontier.com/
RE: Getting back to the original port page (JSP pages and actions)
Same concept, except, you can do this.resetTemplate(rundata); We do this, as well as clear up any portlet session state using an action like doResetstate(). -Original Message- From: Wilson, Allen [mailto:[EMAIL PROTECTED] Sent: Thursday, July 29, 2004 3:13 PM To: Jetspeed Users List Subject: Getting back to the original port page (JSP pages and actions) Question. I know how to get to a template page by set the SetTemplate() property of the Jetspeed object but I am having a problem getting back to the original portlet page. For example... Portlet 1 - Submit button is pressed and action processes information and sends user to template page Template 1 - User fills out form and submits. Action processes information and sends user to next template page Template 2 - User verifies information and submits. At this point I would like the user to be return to Portlet 1. Anyone know how I do that - 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]
RE: Getting back to the original port page (JSP pages and actions)
This simply returns the template to the original portlet page. I'm not sure what your referring to with the Menu items. IF you've set portlet variables, you can clean them up with a portlet action, which clears those attributes, and also resets the template to the original page. I use a PortletSessionState atribute, which is called, 'requesttemplate', which I set in the portlet actions, then in the buildnormalcontext, I either set the template to that value, or reset the template to the original. I clean up with a doResetreport() method, which clears any known attributes, including our requesttemplate attribute. -Original Message- From: Wilson, Allen [mailto:[EMAIL PROTECTED] Sent: Thursday, July 29, 2004 3:35 PM To: Jetspeed Users List Subject: RE: Getting back to the original port page (JSP pages and actions) Will these reset it to the portlet along with the menu items for that portlet. Portlet one will have the menu items for going to other Portlet areas. -Original Message- From: Arthur D'Alessandro III [mailto:[EMAIL PROTECTED] Sent: Thursday, July 29, 2004 2:16 PM To: 'Jetspeed Users List' Subject: RE: Getting back to the original port page (JSP pages and actions) Same concept, except, you can do this.resetTemplate(rundata); We do this, as well as clear up any portlet session state using an action like doResetstate(). -Original Message- From: Wilson, Allen [mailto:[EMAIL PROTECTED] Sent: Thursday, July 29, 2004 3:13 PM To: Jetspeed Users List Subject: Getting back to the original port page (JSP pages and actions) Question. I know how to get to a template page by set the SetTemplate() property of the Jetspeed object but I am having a problem getting back to the original portlet page. For example... Portlet 1 - Submit button is pressed and action processes information and sends user to template page Template 1 - User fills out form and submits. Action processes information and sends user to next template page Template 2 - User verifies information and submits. At this point I would like the user to be return to Portlet 1. Anyone know how I do that - 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] - 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]
RE: Getting back to the original port page (JSP pages and actions)
That is in the PortletActionClass... The rundata object is already declared as part of the action method, or the buildNormalContext method. -Original Message- From: Wilson, Allen [mailto:[EMAIL PROTECTED] Sent: Thursday, July 29, 2004 7:45 PM To: Jetspeed Users List Subject: RE: Getting back to the original port page (JSP pages and actions) Pardon...my stupidity...but what is this declare to the JetSpeedRunData object? -Original Message- From: Arthur D'Alessandro III [mailto:[EMAIL PROTECTED] Sent: Thursday, July 29, 2004 2:39 PM To: 'Jetspeed Users List' Subject: RE: Getting back to the original port page (JSP pages and actions) This simply returns the template to the original portlet page. I'm not sure what your referring to with the Menu items. IF you've set portlet variables, you can clean them up with a portlet action, which clears those attributes, and also resets the template to the original page. I use a PortletSessionState atribute, which is called, 'requesttemplate', which I set in the portlet actions, then in the buildnormalcontext, I either set the template to that value, or reset the template to the original. I clean up with a doResetreport() method, which clears any known attributes, including our requesttemplate attribute. -Original Message- From: Wilson, Allen [mailto:[EMAIL PROTECTED] Sent: Thursday, July 29, 2004 3:35 PM To: Jetspeed Users List Subject: RE: Getting back to the original port page (JSP pages and actions) Will these reset it to the portlet along with the menu items for that portlet. Portlet one will have the menu items for going to other Portlet areas. -Original Message- From: Arthur D'Alessandro III [mailto:[EMAIL PROTECTED] Sent: Thursday, July 29, 2004 2:16 PM To: 'Jetspeed Users List' Subject: RE: Getting back to the original port page (JSP pages and actions) Same concept, except, you can do this.resetTemplate(rundata); We do this, as well as clear up any portlet session state using an action like doResetstate(). -Original Message- From: Wilson, Allen [mailto:[EMAIL PROTECTED] Sent: Thursday, July 29, 2004 3:13 PM To: Jetspeed Users List Subject: Getting back to the original port page (JSP pages and actions) Question. I know how to get to a template page by set the SetTemplate() property of the Jetspeed object but I am having a problem getting back to the original portlet page. For example... Portlet 1 - Submit button is pressed and action processes information and sends user to template page Template 1 - User fills out form and submits. Action processes information and sends user to next template page Template 2 - User verifies information and submits. At this point I would like the user to be return to Portlet 1. Anyone know how I do that - 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] - 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] - 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]
RE: Getting back to the original port page (JSP pages and actions)
I believe the doPerform is called, only if a action is not found that was
called, but normally it's defined as such:
public void doSomeactionformatisveryimportant(RunData rundata,Portlet
portlet) throws Exception {
}
JSP snipplet
%
%@ page import=org.apache.jetspeed.portal.Portlet %
%@ page import=org.apache.turbine.util.RunData %
// Get some needed items
String jspeid = (String) request.getAttribute(js_peid);
Portlet portlet= (Portlet) request.getAttribute(portlet);
RunData rundata= (RunData) request.getAttribute(rundata);
%
...
form name='helloworld' action='%=request.getRequestURI%' method='post'
input type='hidden' name='js_peid' value='%=jspeid%'
input type='submit'
name='eventSubmit_doSomeactionformatisveryimportant' value='Submit this
form'
/form
--- End JSP Snipplet
And for this portlet, you'll need this in your xreg for the portleT:
parameter name=action value=portlets.PortletActionClass
hidden=false/
This is relative to the tubineresources (from memory, I think that's where
it is), modules definition.
-Original Message-
From: Wilson, Allen [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 8:04 PM
To: Jetspeed Users List
Subject: RE: Getting back to the original port page (JSP pages and actions)
Okay...so I have my Rundata object declared as
Public void doPerform(Rundata rundata) throws Exception
{
JetspeedRunData data = (JetspeedRunData)rundata
So will data.resetTemplate(rundata) work?
-Original Message-
From: Arthur D'Alessandro III [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 6:56 PM
To: 'Jetspeed Users List'
Subject: RE: Getting back to the original port page (JSP pages and
actions)
That is in the PortletActionClass...
The rundata object is already declared as part of the action method, or
the buildNormalContext method.
-Original Message-
From: Wilson, Allen [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 7:45 PM
To: Jetspeed Users List
Subject: RE: Getting back to the original port page (JSP pages and
actions)
Pardon...my stupidity...but what is this declare to the
JetSpeedRunData object?
-Original Message-
From: Arthur D'Alessandro III [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 2:39 PM
To: 'Jetspeed Users List'
Subject: RE: Getting back to the original port page (JSP pages and
actions)
This simply returns the template to the original portlet page. I'm not
sure what your referring to with the Menu items.
IF you've set portlet variables, you can clean them up with a portlet
action, which clears those attributes, and also resets the template to
the original page.
I use a PortletSessionState atribute, which is called,
'requesttemplate', which I set in the portlet actions, then in the
buildnormalcontext, I either set the template to that value, or reset
the template to the original.
I clean up with a doResetreport() method, which clears any known
attributes, including our requesttemplate attribute.
-Original Message-
From: Wilson, Allen [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 3:35 PM
To: Jetspeed Users List
Subject: RE: Getting back to the original port page (JSP pages and
actions)
Will these reset it to the portlet along with the menu items for that
portlet. Portlet one will have the menu items for going to other Portlet
areas.
-Original Message-
From: Arthur D'Alessandro III [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 2:16 PM
To: 'Jetspeed Users List'
Subject: RE: Getting back to the original port page (JSP pages and
actions)
Same concept, except, you can do
this.resetTemplate(rundata);
We do this, as well as clear up any portlet session state using an
action like doResetstate().
-Original Message-
From: Wilson, Allen [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 3:13 PM
To: Jetspeed Users List
Subject: Getting back to the original port page (JSP pages and actions)
Question.
I know how to get to a template page by set the SetTemplate() property
of the Jetspeed object but I am having a problem getting back to the
original portlet page. For example...
Portlet 1 - Submit button is pressed and action processes information
and sends user to template page Template 1 - User fills out form and
submits. Action processes information and sends user to next template
page Template 2 - User verifies information and submits.
At this point I would like the user to be return to Portlet 1.
Anyone know how I do that
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
RE: Getting back to the original port page (JSP pages and actions)
%
String jspeid = (String) request.getAttribute(js_peid);
%
This brings the Portlet ID (instance)
-Original Message-
From: Wilson, Allen [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 9:01 PM
To: Jetspeed Users List
Subject: RE: Getting back to the original port page (JSP pages and actions)
This is not working for me...how about something simplier...
I am trying the get the Portlet ID for one of my portlets. If I get that
then I can return to that portlet with setPortlet().
How can I get the Portlet ID in a JSP page?
I am trying your code below:
Portlet portlet = (Portlet)
request.getAttribute(CignaListing);
String portletID = portlet.getID();
But it is not working
-Original Message-
From: Arthur D'Alessandro III [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 7:11 PM
To: 'Jetspeed Users List'
Subject: RE: Getting back to the original port page (JSP pages and
actions)
I believe the doPerform is called, only if a action is not found that
was called, but normally it's defined as such: public void
doSomeactionformatisveryimportant(RunData rundata,Portlet
portlet) throws Exception {
}
JSP snipplet
%
%@ page import=org.apache.jetspeed.portal.Portlet %
%@ page import=org.apache.turbine.util.RunData %
// Get some needed items
String jspeid = (String) request.getAttribute(js_peid);
Portlet portlet= (Portlet) request.getAttribute(portlet);
RunData rundata= (RunData) request.getAttribute(rundata);
%
...
form name='helloworld' action='%=request.getRequestURI%'
method='post'
input type='hidden' name='js_peid' value='%=jspeid%'
input type='submit'
name='eventSubmit_doSomeactionformatisveryimportant' value='Submit this
form' /form
--- End JSP Snipplet
And for this portlet, you'll need this in your xreg for the portleT:
parameter name=action value=portlets.PortletActionClass
hidden=false/
This is relative to the tubineresources (from memory, I think that's
where it is), modules definition.
-Original Message-
From: Wilson, Allen [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 8:04 PM
To: Jetspeed Users List
Subject: RE: Getting back to the original port page (JSP pages and
actions)
Okay...so I have my Rundata object declared as
Public void doPerform(Rundata rundata) throws Exception
{
JetspeedRunData data = (JetspeedRunData)rundata
So will data.resetTemplate(rundata) work?
-Original Message-
From: Arthur D'Alessandro III [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 6:56 PM
To: 'Jetspeed Users List'
Subject: RE: Getting back to the original port page (JSP pages and
actions)
That is in the PortletActionClass...
The rundata object is already declared as part of the action method, or
the buildNormalContext method.
-Original Message-
From: Wilson, Allen [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 7:45 PM
To: Jetspeed Users List
Subject: RE: Getting back to the original port page (JSP pages and
actions)
Pardon...my stupidity...but what is this declare to the
JetSpeedRunData object?
-Original Message-
From: Arthur D'Alessandro III [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 2:39 PM
To: 'Jetspeed Users List'
Subject: RE: Getting back to the original port page (JSP pages and
actions)
This simply returns the template to the original portlet page. I'm not
sure what your referring to with the Menu items.
IF you've set portlet variables, you can clean them up with a portlet
action, which clears those attributes, and also resets the template to
the original page.
I use a PortletSessionState atribute, which is called,
'requesttemplate', which I set in the portlet actions, then in the
buildnormalcontext, I either set the template to that value, or reset
the template to the original.
I clean up with a doResetreport() method, which clears any known
attributes, including our requesttemplate attribute.
-Original Message-
From: Wilson, Allen [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 3:35 PM
To: Jetspeed Users List
Subject: RE: Getting back to the original port page (JSP pages and
actions)
Will these reset it to the portlet along with the menu items for that
portlet. Portlet one will have the menu items for going to other Portlet
areas.
-Original Message-
From: Arthur D'Alessandro III [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 2:16 PM
To: 'Jetspeed Users List'
Subject: RE: Getting back to the original port page (JSP pages and
actions)
Same concept, except, you can do
this.resetTemplate(rundata);
We do this, as well as clear up any portlet session state using an
action like doResetstate().
-Original Message-
From: Wilson, Allen [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 3:13 PM
To: Jetspeed Users List
Subject: Getting back to the original port page (JSP pages and actions)
Question.
I know how to get to a template page by set
JSP Portlet - POST|GET - DynamicURI
What is the proper way to post a form or a href to the current page; on the current pane; on the current psml? We had been using forms (method=post), with no action specified in the form tags, and this has been working for the most part when dealing with single portlets on a pane. Since better understanding the way that jetspeed processes requests, we have moved to a action class framework, and using the PortletSessionState static class for passing attributes to the JSP pages. We've tried the recommended : jetspeed:uriLookup type=Home/ and jetspeed:dynamicUri These both generate dynamic uri's that look like: http://hostname.domain.com/portal I would think they would have reference to the psml we're currently dealing with. However, when we use either of these dynamic uri's in both POST and GET HTTP methods, we end up back at the user's psml file. We do have a security ref on the common role:user Default.psml, which specifies that the panes, and portlets are all Read only. I don't think that this security-ref has anything to do with it, because the action method never gets invoked in the action class. It just seems that the dynamic uri being presented does not maintain current location in the portal. JS1.4 Thanks, -Art - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSP Portlet - Form Submission questions
Questions: 1) Is there a programmatic way built into the Jetspeed framework so that you can present multiple portlets (all of which may have forms and their own form handlers) and have a portlets form post the data only to itself? 2) Although I read mentions of portlet instance session information, I was unable to make use of session state attributes without using the PortletSessionState; this implementation modifies the PSML, which when using Role based PSML is not an option as it changes the psml for all the role members. Is there another way to track the portlet instance session information in memory, similar to how the entire portal can track session information? 3) What does including the js_peid attribute in forms do? It does not appear to help, or function at all that I can see. 4) Proper way to pass variables form action handler class to JSP pages? I've seen a variety of ways of doing this, from rundata.getSession.setAttribute, rundata.getRequest.setAttribute, portlet.setAttribute etc. I've found problems with most of them, in that my JSP pages may use common attribute names for multiple jsp portlets, which then try to evaluate the posted data, when the data wasn't meant for the portlet. We've somewhat rigged this by using the action handlers, but still isn't perfect. 5) This is somewhat linked to #1, but if you have multiple instances of portlets on the same pane, and submit a form, how do you differentiate? I've started to use common attribute method names for the form action, then populate a js_peid+methodname which is then handled both on the action handler and on the JSP side, but this seems overly complex. Any suggestions would be greatly appreciated. Environment: Jetspeed 1.4 Thanks, -Art - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JDBC Database init and JSP Portlet design
With our first deployment of Jetspeed 1.4, we decided to use JSP primarily for new portlet development. We've found portlet development to be quite straight forward, when/if dealing with only single portlets per pane. We are now getting into having multiple portlets per pane, and most of our custom JSP portlets interact with themselves via form posts. We've recently gone back to rework our portets to use the action, eventSubmit_Action framework, however, I now have questions on how to best utilize database access. Prior to Jetspeed, we had developed using the traditional JSP/Servelet model, where the classes would be initialized once during runtime, thus allowing us to make use of the JSPInit, and Init methods to grab references to our JDBC connection pool data sources defined in our server.xml. With the initial release of our Jetspeed 1.4 portal, the JSP pages all work nicely using the JSPInit method to grab those datasource references from the default context. Now that we're trying to move to a jsp form action handler framework, questions have arisen as to where those variables should be initialized. It is my understanding that the logic, and data processing should be largely handled on the PortletAction class, but there does not appear to be a way to define the class thus that it only initializes once. Does anyone have any best practices for where the database logic should be defined, and how to do so with the least amount of overall overhead. Thanks, -Art - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jetspeed startup problems on Tomcat 5.019 (Linux)
Has anyone else seen Jetspeed fail to load when Tomcat is started? In order to get the virtual hosts responding again, I must shutdown tomcat again, and start. This usually resolves the issue. I do not see any errors in the either tomcat nor jetspeed logs, only that the host seems to go into lala land; it accepts connections, but doesn't serve any content. The problem has only affected our jetspeed virtual host, all other virtual hosts are unaffected. Even the tomcat manager webapp context assigned to the virtual host element is unreachable. I haven't seen any posts regarding this issue, but I thought I'd see if anyone has seen this behavior. Thanks, -Art - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
