Yeah I was also in favor of enabler interfaces, but now I like pico's approach more. When you have a big app and a big hierarchy and this hierarchy needs some components then you realize with the old approach you just have to define lots of enablers, you can't use a base enabler because of the way it's defined in the xml file. So for example if you have a hierarchy of Exporters (HtmlExporter, PdfExporter, etc) then with xwork's current approach you can't say "implements ExporterAware" and be done. That ExporterAware is only mapped to one Exporter concrete instance in components.xml. With pico it's just plain easy. Just pass the correct type to a specific component in its constructor!
But scopes are still an issue imho. I don't agree with Joe that a components depending on narrower scoped component is a design smell. So you have a GroceryStore component, it needs a PersistenceManager component. In first thought you make GroceryStore app scoped, but then realize it needs PM and PM is request scoped because it needs to open and close sessions/transactions. So basically to scope a component you look at the dependencies of that component and use the narrowest scope of its dependencies for the first component. It's very easy to make mistakes and I'm not sure scope of another component, an implementation detail of another component, should dictate the way to choose scope for your own component. On the other hand I understand that you can't depend on narrower scoped components. That's very logical. What I think we need is some help from the ComponentFactory for deciding scopes. So if I set GroceryStore.scope=app and it needs PM and PM.scope=request then probably ComponentFactory should dynamically tweak the scope of GroceryStore to request (?). Another possibility if a diagramming tool like the one Joe showed me. It visiually shows dependencies. I think we can tune it to show scope of a dependency hierarchy. Thoughts? Ara. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of BOGAERT Mathias Sent: Wednesday, June 25, 2003 5:54 PM To: '[EMAIL PROTECTED]' Subject: RE: [OS-webwork] How do you define a component ? Hi, � This also demonstrates one of the reasons I would like to go for picocontainer and type 3 IOC. When I started with IOC, I wasn't fully convinced yet, and it was more like 'hey this is cool'. More experimentation like. Now, after 2 weeks converting most of my components to use IOC, I am beginning to hate all those enabler interfaces since I know they can be made redundant. � I hope we migrate to pico soon. � Cheers, Mathias -----Original Message----- From: Jason Carreira [mailto:[EMAIL PROTECTED] Sent: woensdag 25 juni 2003 16:19 To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] How do you define a component ? Think of them as services... your persistence manager might be a good candidate. You could bind a Hibernate implementation, for instance, into the persistence manager spot in the registry. It could declare that it depends on a ConnectionProvider (another component) so it would be provided one when it is instantiated. You could also have a ShoppingCart component / service which depends on the PersistenceManager, etc... -----Original Message----- From: Christian Meunier [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 7:37 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] How do you define a component ? Refining a little bit my question, what does make a good candidate for a component ? Obvious examples we see everywhere is bridge component ( Trade component to query a trade engine�etc...)�but beside this ? Many things can be done with interceptors and you can always re use your business layer or part of it in another applications, guess i dont get it :) � Chris � ----- Original Message ----- From: Christian Meunier To: [EMAIL PROTECTED] Sent: Wednesday, June 25, 2003 12:20 PM Subject: [OS-webwork] How do you define a component ? Hi everyone, while reading the topic about nano/pico container,�few questions keep coming to my mind, what exactly is a component, which purpose does it have ? How exactly is it different from an aspect in AOP ? How do you choose to code something as a component rather than as a 'module' in your business logic ? � Thanks in advance for any though you can share on this topic. Christian Meunier ------------------------------------------------------- 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
