> I think PortletAction should become a real class, and not a subclass
> anymore, and contains a render() method that would give it renders
> (javascript, or whatever). A portlet action would be linked to a control
> action.

IMOHO, PortletAction should go away entirely and the Portlets themselves should act as 
their own actions.  This is how the JSR works.

*===================================*
* Scott T Weaver                    *
* Jakarta Jetspeed Portal Project   *
* [EMAIL PROTECTED] *
*===================================*
  


> -----Original Message-----
> From: Aurelien Pernoud [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 18, 2003 12:02 PM
> To: 'Jetspeed Users List'
> Subject: RE: JSR-168 Comments
> 
> 
> Gerry Reno a ecrit :
> 
> > Scott,
> >   My apologies for coming at this a little strongly.  I didn't intend
> > to offend anyone.  My comments about the usability of the
> > IFramePortlet were actually intended to show that the IFramePortlet
> > can be made perfectly usable if we change the view interaction model
> > that's all.
> >
> > Gerry
> 
> I agree on this point, but when moving from a pane to another this won't
> work either. The only way to make IFRAMEPORTLET totally ok would be to
> prevent *any* client<->portal request, so the client should load the
> entire
> portal once... What about updates :)
> 
> Now your idea of making the controls action on the side client can be
> properly done I think this way :
> 
> Currently the rendering of the link is done in
> org.apache.jetspeed.portal.controls.VelocityPortletControl.buildActionList
> ,
> with a subclass "PortletAction" inside. All portlets actions are hardcoded
> there, that may be the time to change this and add a portletaction.xreg
> that
> list the available actions ?
> 
> I think PortletAction should become a real class, and not a subclass
> anymore, and contains a render() method that would give it renders
> (javascript, or whatever). A portlet action would be linked to a control
> action.
> 
> A nice way to autorize both rendering (javascript or client<->server for
> an
> action) would be to allow it at the portlet level (when adding a portlet,
> you decide which rendering you want for actions, or use the default one in
> the xreg, or if none present then use the current "standard" one).
> 
> Then if one would like to change the rendering of an action button, he'll
> have to override the render() method of a portletaction, create a new
> portletaction in the xreg, with the same name but the new created
> portletaction class, and then link it to a portlet.
> 
> I first thought that was easy, but in fact the hardcoded part of
> portletactions makes it harder than it seems, and I don't know if I've
> thought of everything...
> 
> Aurelien
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to