> > Can you expand on where/ why you think that difference comes from? Are
> > some of the default components of WO better abstracted for the kind of
> > things you do?
> For example, I'm thinking of some pages sometimes that contains tons of little
> dynamic "label" (or WOString ;)). In a declarative way, you don't need to
> factorize these in a new component. With Wicket, we usually factorize these 
> in a
> custom Panel to keep the page class clean.

We have wicket:message for such cases. And there is the non-advertised
wicket:component tag, of which we are still unsure whether we should
totally ditch it or not.

A WO (or Tapestry, for that matter) kind of approach, where the
structure is defined in a third file or inferred somehow should be
doable if someone is willing to take that up. I'm not sure whether
you'd get a lot of additional help from the core team, but we're
certainly not against customizations if people feel alternatives work
better. One of the advantages of Wicket being a non-declarative
framework, is that it is still open for building the declarative part
on top of it if you want.

For instance, look at how WicketMessageResolver is implemented
(IComponentResolver). And add to that the fact that you can let any
component dynamically build itself (or rather it's children), e.g.
using a factory pattern using that declarative file, and a world of
possibilities opens up.

If you'd ever endeavor on that, please keep us (this list) informed :)


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Wicket-user mailing list

Reply via email to