> Is their a reason we cannot user peid, instead of js_peid? We can call the parameter whatever we like. Our original thinking was that prefix everything with js_ Im not clear as to why the method on JetspeedRunData has to be called setJs_peid
> -----Original Message----- > From: Paul Spencer [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 18, 2002 10:22 AM > To: Jetspeed Developers List > Subject: Re: JetspeedTemplateLink and peid > > > David, > Is their a reason we cannot user peid, instead of js_peid? > > Paul Spencer > > David Sean Taylor wrote: > > > See below: > > > > > >>JetspeedTemplateLink is not quite right for the new peid > >>feature. It still has forPortlet() taking a portlet name > >>(not id) and producing a url with "/portlet/<name>" intead of > >>"/js_peid/<id>". > >> > >>We need some call in there to make take a portlet id and make > >>a url with "/js_peid/<id>". > >> > >>Do we want to change the definition of forPortlet()? It's > >>new, so doing so might not break too much. We would change > >>it to encode the new "js_peid" parameter. It would have to > >>be passed the peid from the request, which can be found in > >>the $data.Js_peid. > >> > >>Forms that want to be submitted to just a portlet could > >>encode their action url as: > >> > >>$jlink.forPortlet("$!data.Js_peid") > >> > >>forPortlet() would, if passed a null or empty parameter, for > >>the case where there is no peid in the request, just be > >>ignored, so the $jink would be back to the entire portal > >>rather than specifying a portlet. > >> > >> > > > > That all sounds fine. > > Any objections to changing forPortlet to using an id? > > > > Btw - I don't like that Js_peid notation... > > Don't really have an alternative right now, but it looks clumsy > > > > > > > >>* * * > >> > >>Also, we would have to assure that whenever a reqest comes in > >>with a "js_peid", that the rundata's Js_peid() is properly > >>set with it, and not rely upon an action (such as Maximize) > >>to set this value. > >> > >>We need to fix JetspeedSessionValidator.doPerform(): > >> > >> String maximizedPortlet = > >>(String)jdata.getUser().getTemp("portlet"); > >> if (maximizedPortlet != null) { > >> jdata.setPortlet(maximizedPortlet); > >> jdata.setScreenTemplate("Maximize"); > >> } > >> > >> // if a portlet is referenced in the parameters > >>request, store it > >> // in the RunData object > >> String paramPortlet = > >>jdata.getParameters().getString("portlet"); > >> if (paramPortlet != null && paramPortlet.length() > 0) { > >> jdata.setPortlet(paramPortlet); > >> } > >> > >>Are we ok that the user.getTemp("portlet") is reserved here > >>for maximize? If so, we need to fix it so it sets the > >>jdata.Js_peid(), which is what Maxmize now uses, and check > >>the getTemp("js_peid"), which Maximize is also setting. > >> > >>To assure that the Js_peid() is set in the rundata, we also > >>need another hunk of code like this: > >> > >> // if a portlet is referenced in the parameters > >>request, store it > >> // in the RunData object > >> String paramPortletID = > >>jdata.getParameters().getString("js_peid"); > >> if (paramPortletID != null && paramPortletID.length() > 0) { > >> jdata.setJs_peid(paramPortletID); > >> } > >> > >>So all the new peid folks will have it set in the rundata. > >> > >> > > > > Agreed. I will apply your patches and combine them with the > code that > > Im adding to support referencing non-default psml pages. > All template > > links will now have to consider the profile parameters. > Hope to have > > this checked in early this week. > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:jetspeed-dev-> [EMAIL PROTECTED]> > > For > additional commands, > e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > -- > To unsubscribe, e-mail: > <mailto:jetspeed-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
