> 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]
