> > Imo, once you get used to it, working with callbacks/ factories like
> > that is actually nice.
>
> Perhaps. I am not so convinced...
> The interesting bit is that we can find other ways as well.
Just my opinion of course :) I struggled with the change a bit, but
after I got used to it I feel it makes me think more ahead. It's not
always great though. The wizard component for instance is actually
more elegant in 1.2/1.3 than it is in 2.0, as in the older version I
could combine the wizard step definition with the actual panel/
component which allowed for a nice short writing style. But well...
can't have it all.
> > > Eelco, we have the impression that the stuff that is stored in the
> > > ListView model will be serialized, in which case the above can not work,
> > > and a PaxTag mapping or similar would be needed. Could you clarify a bit?
> >
> > Yep. Keep in mind that Wicket doesn't have to serialize components at
> > all; it mostly depends on whether and how you do clustering
>
> Isn't it involved in long-running sessions as well??
What do you mean with long-running sessions? If you mean long running
transactions for e.g. you database layer: Wicket doesn't have anything
to do with that. You can hide the logic for pausing and resuming a
long running session nicely in Wicket's models, but it is not a
responsibility of the framework.
> Doesn't this end up with a single Spring application context?? I.e. another
> form of bridging with singletons.
Not for end users, as the only thing they have to know is that when
they define that @SpringBean reference, it'll be resolved for them
whenever they use it. Purists have been screaming that the fact that
@SpringBean is there at all spoils the idea of IoC, but frankly I
don't care and think this works great (and in fact mucho better than
defining the dependencies in XML).
> > Btw, @SpringBean works really great, I'm totally hooked on it, even
> > though I've never been a Spring kiddie. How about an OSGi variant of
> > this. Any options/ ideas?
>
> Well;
>
> As you probably know, OSGi is not so much about magic. So, a simple pattern
> more or less equivalent to the above;
>
> public class MyPanel extends Panel
> {
> public MyPanel(MarkupContainer parent, String id)
> {
> IModel theModel = new LoadableDetachableModel()
> {
> protected Object load()
> {
> MyService service = MyActivator.getMyService();
> return service.findAWholeBunchOfVeryCoolDomainObjects();
> }
> }
> ...
> }
> }
>
> And in the BundleActivator we have something like;
>
> public void start( BundleContext bc )
> {
> m_myService = new DefaultMyServiceTracker( bc );
> }
>
> static MyService getMyService()
> {
> return m_myService;
> }
>
> The DefaultMyServiceTracker is MyService proxy that tracks the "real thing",
> and has some behaviour for handling "unavailable".
And that's great and even more efficient than having that proxy (light
as it is)! I don't mind the service locator pattern at all. But there
are zillions of IoC zealots out there that start foaming when they see
the slightest hint of that pattern. Obviously, being a committer on
Wicket, I'm not crazy about code obscuring magic myself and in fact
enjoy writing good old Java code like your example above :)
Eelco
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
