JavaDoc
When I came on the scene, Portlet 1.0 support was complete, with the help of Apache Portal Bridges and work on Wicket resource serving support was mostly complete. The first daunting task however, was completing the documentation for nearly the entire existing Portlet support in Wicket. This was a big learning experience and a deep look into Wicket internals (which btw, made me a bit nervous about my upcoming event implementation task). This was mostly completed in WICKET-1875 , with the a lot more additional javadoc included in my patches for WICKET-1620.
Events
It was pretty much decided that I wasn’t going to try and do anything at this stage with the public render parameters part of the spec, and was going to focus on the Events system. This was a much bigger task than any of the other parts of the Portlet 2.0 spec, and a lot more complicated than I expected.
However, in the end, I think I came up with a pretty nice solution. After some false starts, I ended up implementing with custom
- WebRequestCycleProcessor
- AbstractBehavior
- BehaviorRequestTarget
aptly named
- PorletWebRequestProcessor
- AbstractPortletEventListenerBehaviour
- PortletEventRequestTarget
This really fits into Wicket superbly well, a testament to the sophisticated, yet reasonably straight forward (considering the problem domain) extensibility of Wicket. Bravo.The patches are sitting with the issue, and now that I have some extra time, I will massage them some more and I’m confident that they will be in Wicket 1.5. Included with the patches is also a simple example application.
Known issues with the implementation at this stage are:
- Issues around events in response to events
- Resource URL’s being generated for links, in some cases, instead of Action URL’s.
On my second to last day at Componence, I gave a presentation to the company on the work I had done. Posted below are two small sections of that presentation (Keynote is lots of fun) which show the gist of it.
Basic flow of code through the events sub-system
Triggering an event is merely a call into the Portlet API and letting the hosting Portal take care of the rest.
The basic steps for receiving a Portlet event are as follows:
- Wicket receives an event request - this is like a normal HTTP request (or a Action request in Portlet speak - so to speak
- Wicket calls into the custom (registered) PorletWebRequestProcessor.
- The PorletWebRequestProcessor checks the context is an Event Request - otherwise the processing is delegated to the parent.
- The Request Target is resolved to the custom PortletEventRequestTarget.
- During the normal Wicket request processing, at the appropriate stage, calls into our PortletEventRequestTarget the processEvents method from the IEventProcessor.
- Inside this method call, we search through the page’s component tree looking for behaviors attached to components which extend the AbstractPortletEventListenerBehaviour. The search performed is a depth first recursive search. I have a niggling feeling that this could perhaps be improved somehow.
- When found, the event name is checked to see if it matches the name of event the behavior is registered as wanting to subscribe to.
- If they match, we call into the behavior, passing in the Event.
- Hey presto!
In hind sight it all seems a little simple now But of course I have come out the other end a much wiser and learned man - gotta love the opportunity to learn from Open Source! So my current view is of course, biased.
Code example of using the events API
I’m very proud of the work I’ve done on Wicket and am very excited to see it make it into trunk. As I said before, the next step is to polish up the patch and remove extra unneeded code (it’s pretty big), so that the core guys can review it properly.
A snapshot of the end of my talk at Componence about Wicket et al
Author: Antony (Tony) Stubbs
Source: Tony’s Blog on http://stubbisms.wordpress.com/
