Tim Boudreau-3 wrote:
>
> This definitely sounds like the better option if it can be completed
> promptly. Ideally wicket portlet support could make it relatively easy to
> support both incoming and outgoing remote portlets - I read through the
> (ferociously complex) WSRP spec and it sounds like that to be usable by
> the
> mainstream, some simple ways of handling common cases are sorely needed.
> Is
> that one of your design goals for this project?
>
I haven't looked at WSRP at all.
Tim Boudreau-3 wrote:
>
> I agree with Jon here - it sounds like you're talking like a sort of
> generalized "event bus" system. Certainly those are needed for portlets,
> but I think trying to come up with a unified model of handling "global"
> events and handling the on*() type of events that are local to Wicket
> components are very different things, and trying to make them similar will
> probably just make both more complicated. Take a look what we did in the
> Gizmo prototype - specifically,
>
> public interface IListener <T extends Event> {
> void onEvent (T event);
> }
>
> coupled with
>
> public <T> void addListener (IListener<T>) {}
>
> In other words, have single onEvent() methods which are passed a type
> makes
> better use of the Java type system than what Swing does. On that note,
> since listener leaks are the most potent source of memory leaks in Java
> desktop applications, it might be worth considering defining the lifecycle
> of such listeners - for example, that the caller must keep a strong
> reference to the listener or it can be garbage collected. Your call, but
> we
> might as well not recreate the serious problems of the listener pattern as
> used in Swing.
>
>
Have a look at what I did. I'm not sure how the onEvent system above would
work when servicing eventRequests from the portal.
-----
___________________________
http://stubbisms.wordpress.com http://stubbisms.wordpress.com
--
View this message in context:
http://www.nabble.com/Finishing-Portal-2.0-development-tp19909563p20227485.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
