On Mon, Mar 23, 2009 at 2:51 PM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote: > what happens when features of differnet containers need to bleed > through? for example Guice's @Inject has an optional() attribute. > Since users of wicket-guice use guice's own @Inject it is all > transparently supported.
Syringe doesn't support that. If you want to use Guice, you should use Guice. > Reversely, syringe.Inject offers a name attribute, which afaik, guice > does not support... Guice supports the @Named attribute. Syringe supports that (it's in the test case). > you mean syringe does not have the portion of code that deals with > cglib? that has been farmed out to commons-proxy? i dont see how this > is a differentiating feature though unless you expect your users to > work with syringe code that creates proxies? It's different in that the code doesn't need to deal with it. If you want to use a different proxying technology, you plug it in (the SyringePlugin constructor can take a ProxyFactory). > this pattern has proved quiet problematic in the past, and will keep > doing so until everybody uses the wicketpluginapplication base class > for the plugins they write for wicket. you should support a way of > working with syringe without the base class present. That doesn't mean it's not a good idea. If the architecture is there, then folks can start migrating to it. The beauty of the plugin architecture is that the injector logic can lookup the DependencyProvider at runtime (even after serialization). I suppose I could come up with a way to do that without the plugin architecture, but then nobody will use wicket-plugin! :) --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
