> But it will be the portlet class the responsible for handling > processing. So the only way to pass information from the onClick > function to the > portlet application for rendering (for example) is using the portlet > session.
But why would you want to go via the Application? The WicketPortlet is mostly just the "front controller" responsible for mapping between the "portlet world" and the "Wicket world": Either use a custom WebSession for the portlet app, or pass the values you need in the PageParameters you send to the response page in your onClick()/onSubmit(). This assumes the onClick() is for a link on a Page that is part of the portlet application. Rendering is left to these Pages. > I also saw that in the portlet example, the examples structure is > initialized by the WicketExamplesMenuPortlet and sent to the > WicketExamplesMenuApplication using the servlet context. But this will > overbloat the servlet attributes storage space. Also this should be > solved if webpages could access to the portlet class directly. > > Why to do this way? The Examples portlet is a bit strange compared to how you would normally do things it seems. > 1.- Onclick: Put the Id on the session like above. > 2.- Portlet.DoView: Recover id from session and store it in > shared render params. > 3.- Delete it from session. > > > Is this the correct way to do it? You could try making "normal" PortletURLs instead of using Wicket Link elements; use setProperty()/addProperty() to set the portlet parameter. Presumably Wicket's Portlet API implementation will deal with the mapping just as it does today with mapping to and from PageParameters. - Tor Iver --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
