Hi Timo,
at Hippo, we've been working on a plugin architecture based on panels with
messaging capabilities. There was a presentation at the last Wicket meetup
in Amsterdam, see
http://www.slideshare.net/nielsvk/wicket-plugin-architecture. This code is
available under APL and we would like to share as much as possible with the
Wicket community. Currently, we're restructuring the messaging mechanism to
incorporate the lessons learned so far.
Let me first summarise our current architecture. In a nutshell, we want to
achieve the benefits listed in WICKET-1312, and then some. We want to
- construct plugin (component) trees dynamically
- compose applications by reusing existing, configured, (sub)trees
The scope of messages is limited to achieve composability. The method that
we're using to achieve this is by separating the message processing in two
phases. In the "request" phase, the message travels up the hierarchy, where
each plugin calls its parent plugin until one is found that handles it. A
message is handled by turning it into a "notification" and sending it to all
the children. Messages themselves consist of a description ("browse" or
"edit") and a model.
A number of conclusions we've been able to draw from our experience:
- the number of models that is used by the plugins is relatively small
- the number of different messages (i.e. events), are relatively numerous
- reusable events are at the application level rather than the model level
- publish/subscribe leads to lifecycle management; this does not fit very
well with Wicket
- ajax responses have to be managed when plugins can be dynamically removed
In the application model that we've been using, all communication is through
parent-child _plugin_ relationships. So even when a plugin is not reachable
from the Page, e.g. because it is in a tab that is not currently selected,
it does receive messages. This is used to switch tabs; a plugin in a tab
can send a "focus" request to the TabsPlugin in reponse to another event.
This is basically the distinction between Wicket components and Plugins.
With plugins, logic can be distributed in a non top-down fashion; child
plugins are not explicitly managed by their parent but instead can use
simple protocols to invert the control hierarchy.
We're now evaluating our model, having gained some experience with Wicket
and the interaction with the communication mechanism. The two solutions
that we're imagining are closely related to the "event" and the "model
changed" solutions of yourself and Matt Clark, respectively. There is
obviously a need for an event mechanism in Wicket, independent of a plugin
architecture. In the construction of the plugin architecture, it would be
nice to be able to reuse this mechanism.
For the event option, I think your patch provides a useful starting point.
I would suggest to scope events by providing a separate interface that is
implemented by components that handle events/messages. When a component
wants to broadcast, it uses findParent() to get a broadcaster. This should
also give the possibility to override the broadcaster with a more
specialised version, e.g. to also broadcast to disconnected plugins.
Separately, I don't really understand why the patch insists on separate
onEvent() methods for different events. Wouldn't it be easier to just have
the one, use marker interfaces to indicate what events to receive and check
the event type with instanceof?
In the "model changed" architecture, a shared model represents the state of
the application in a simple model. The model is a map that connects
descriptions to other models. Components use these referenced models and
can repaint when they change. It should be possible to maintain
composability by using an indirection between the component internal list of
model names and the descriptions in the map. This is a very simple
communication model but, since we haven't used it so far, it is difficult to
see whether it is sufficiently powerful in general.
If there is an interest in the plugin architecture, we can start working on
the next revision as a wicket extension. Ideally, this builds on an
existing event mechanism so I hope you'll excuse any seemingly ridiculous
requirements of flexibility.
cheers, Frank
Timo Rantalaiho wrote:
>
> On Tue, 05 Feb 2008, Igor Vaynberg wrote:
>> see https://issues.apache.org/jira/browse/WICKET-1312
>
> Thanks for advertising!-)
>
> Have you or other devs had time to look at the patch, and
> what do you think?
>
> It would be excellent to already have this in Wicket 1.3
> (such as 1.3.2) to be able to use it in most of our real
> Wicket projects. Of course now that the patch is there it
> can be easily enough ripped to any project.
>
> The code is all Java 1.4 and it doesn't change any existing
> code, just builds on it. So it doesn't break any other
> functionality, just adds more code to maintain.
>
> Anyway, good even if it makes it to Wicket 1.4.
>
>
> A braver version (suggested by my workmate) would hook event
> broadcasting directly to Component so that you could just
> call broadcast(ListenerClass, Event) anywhere without need
> to create the broadcaster object yourself.
>
>
> Best wishes,
> Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>
>
--
View this message in context:
http://www.nabble.com/Generic-event-mechanism-%28was%3A-loosely-coupled-panels%3A-react-to-model-object-change%29-tp15516909p15632889.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
