On 26.6.2006, at 12.41, Ate Douma wrote:
- you removed the
web.xml from the portlet-samples, but you definitely do need it as it won't build
otherwise, although it shouldn't contain a Pluto PortletServlet for sure.
Yeah, I put the empty
web.xml where it belongs.
- I noticed you configure the PortletApplication in portlet.xml as a preference.
That I find a bit odd as those kind of setup info is usually provided through init parameters
(just as you would do with servlets). I think Preferences really are meant for a different usage.
I first had them as init parameters, but did not manage to get them from the jetspeed. May be I should try it again, with better luck..
- In my initial shot at portlet support for Wicket I intended to provide a solution which would allow
Wicket web applications easily migrated to portlet applications or even run in dual mode.
For this, I tried to start with an inheritance model which would require hardly (if even needed)
modification by a developer. As far as I can see (but I must admit I have only yet glanced at the code),
you choose to use a parallel class model which will make this much harder.
Know that I'm not criticizing this choice at all (I hardly have credits to do so), and your route is
somewhat easier to follow this way, but I'd like to know if this is a deliberate choice or more one
to get a quicker working result (which I definitely can agree to).
I did the decision because using WebPage would require quite few refactorings in the core, and the result would still have been quite ugly. Both approaches have their good sides. Header contributions and other stuff like that won't work with portlets anyway, so I think it's cleaner to have them separated. You can easily use same code with and without portlets anyway by using wicket panels.
After looking around a bit in the code, I noticed that the PortletApplication.getSessionAttributePrefix(...) method uses
(only) the request contextPath for build up the prefix.
But, because two instances of the same portlet will share both the same name and the contextPath, I've got the feeling this
might be causing them to share the same key and thus clashing in their state management. As far as I could see, you don't
use (yet) PortletSession.PORTLET_SCOPE attributes to keep these apart.
I haven't yet had time to really debug this so maybe I'm way off track here though.
Yeah, I already had this in my todo-list.
