Luca,
have a look at the documentation
http://docs.castleproject.org/Windsor.Registering-components-by-conventions.ashx
specifically the "*|BasedOn|, |Where| and |Pick| do logical |or|*" section.
"container.Register(AllTypes.FromThisAssembly().Pick.Where(Component.IsInNamespace("MyApp.Views")).WithService.DefaultInterface())"
This registers every single public type from this assembly as itself,
and then types from the namespace you specified are registered again
with the default interfaces they expose.
Short answer is - use just a single of those methods (BasedOn,
Where, Pick) per call to AllTypes.
about "*IClass1 *is actually registered (with status "All dependencies
can be resolved") several times on this way:
Service=*IClass1*+Event1EventHandler;
Implementation=*IClass1*+Event1EventHandler
Service=*IClass1*+Event2EventHandler;
Implementation=*IClass1*+Event2EventHandler
Service=*IClass1*+Event3EventHandler;
Implementation=*IClass1*+Event3EventHandler"
no it's not IClass1 that's registered here - it's the three (I suppose
delegate) types defined within it.
On 14/04/2011 4:51 AM, Luca Vignando wrote:
Hi,
I am porting a .Net 1.1 desktop application based on Castle +
NHibernate + nano/pico container, based on MVP pattern on .Net 4.
I overcome several problems and I managed to have a few forms of the
existing codebase running properly after updating Castle + NHibernate
to the latest versions and substituting nano/pico container with Windsor.
My biggest problem now is with *component registration in Windsor.
My question in 4 lines: *which is the proper way to register (using
fluent registration) in Winsor an Interface that defines events and is
passed as a parameter in a class constructor (that does not implement
it) (IView containing events passed to Presenter constructor)?
Please note: I tried several variations of fluent registration with
odd results (multiple registrations of IView+EventName, one for each
event, but no "vanilla" IView registration).*
*
*Long and detailed version of the question follows.
*
If I *manually register* components one by one everything works
perfectly and components resolve properly.
semple code:
container.Register(Component.For(Of
Views.Interfaces.IMyForm).ImplementedBy(Of MyForm)
container.Register(Component.For(Of
Presenters.Interfaces.IMyFormPresenter).ImplementedBy(Of MyFormPresenter)
(and so on for each view and presenter, but I have several hundreds
classes)
*To resolve* I use:
presenter = container.Resolve(GetType(IMyFormPresenter))
If instead I use *fluent registration *
(sample code)
container.Register(AllTypes.FromThisAssembly().Pick.Where(Component.IsInNamespace("MyApp.Views")).WithService.DefaultInterface())
(please note: I_tried *several* variation of this_, including separate
registration of presenters and views, using the .BasedOn followed by
the base interfaces implemented in my app, with or without .Pick, with
or without .Where and so on).
I also noticed that the sample above registers also components in
MyApp.Presenters namespace.
No matter the variation I apply, I get this:
* For each "Presenter" the "container" reports that some
components are likely to be misconfigured and properly reports
the missing component.
* The missing related component is not in the "misconfigured"
components list: I can find it on the list of properly
configured components but not as I expect: it is *registered
several times using every event as part of service and
registration*. (details below)
* I have to register IWindsorContainer, System.Object,
System.IntPtr as components, otherwise most components complains
about not being able to be resolved owing to those missing
registrations.
* _I have no issue with fluent registration when the IView does
not define events_*.
*
*Details of each component with multiple registrations:
*
Please note: *
*
* *Class1Presenter *is a Presenter in Presenters namespace;
* *IClass1 *is the interface implemented by view Class1 in Views
namespace (passed to *Class1Presenter *constructor);
* Event1,2,3 are actual event names defined in IClass1
container reports a problem for *Class1Presenter*, the "Status" says
that *IClass1 *can be misconfigured so the component might not resolve.
*IClass1 *is actually registered (with status "All dependencies can be
resolved") several times on this way:
Service=*IClass1*+Event1EventHandler;
Implementation=*IClass1*+Event1EventHandler
Service=*IClass1*+Event2EventHandler;
Implementation=*IClass1*+Event2EventHandler
Service=*IClass1*+Event3EventHandler;
Implementation=*IClass1*+Event3EventHandler
...
You got the point, for each event defined in each interface I get a
different component having the event handler as a part of service and
implementation. The service and implementation value is exactly as
reported: /InterfaceName/+/EventName/EventHandler
I have also a variation: let's suppose that Class*2*presenter uses in
the constructor IView*2* implemented in View*2* which inherits from
View*3*. If IView*2* does not contain any event, then
Class*2*Presenter is misconfigured because of missing IView*3*. As
usual IView*3* is registered several times, one for each event.
*The bottom line*
Am I missing something? I suppose that there is something wrong in my
code but I cannot figure out why an event in interface triggers this
multiple registration and how to avoid it.*
*I would like to have advice or sample code to:
* Use fluent registration getting rid of the misconfigured components
* Avoid (if possible) registration of IWindsorContainer,
System.Object, System.IntPt: I have never seen them in any
sample and I see no point in registering them in the container,
so it seems to me that are symptoms of a mistake on my code.
Please note, my app uses MVP in a conventional way: views and
presenters can communicate through interfaces only and to open a form
I have to resolve a presenter from the container and let it
instantiate the related view properly.
I ask you to kindly forgive the length of this post but I tried to be
as clear as possible and I thank you in advance for your patience
reading all this and for help you can provide me.
Luca
--
You received this message because you are subscribed to the Google
Groups "Castle Project Users" group.
To post to this group, send email to
[email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en.
--
You received this message because you are subscribed to the Google Groups "Castle
Project Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en.
