You can't have a component that depends on another component of narrower scope though - that doesn't make sense.
I'm a little on the fence on this one, the enabler interfaces seem a bit nicer to me in some ways too, but Pico would reduce the LoC a little, and definitely feels simpler. The thing is, Pico fits the XWork model pretty well, however I'm a little concerned about the situation where you'd want to write a component that was also used outside of XWork - the "only allowed a single constructor" constraint could become a limitation? Thoughts? "Mike Cannon-Brookes" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Guys, > > Please sort this one way or the other so I don't look like a total joker at > TSS describing our IoC architecture, then we flip around and use Pico :) > > j/k > > I've only looked at Pico briefly from Paul Hammant, and it does look good. I > kinda like the enabler interfaces personally though, they're nice and neat. > How does Pico handle things with different scopes I wonder? > > Ie if you have an application scoped component, which gets a request scoped > component set on it - it's already constructed, so uh - eh? :) > > Mike ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
