No worries,
I'm hopeful it will be similarly easy migration process for anyone else
who's depending on current behaviour.
cheers,
Krzysztof
On 06/03/2011 9:03 PM, [email protected] wrote:
Ok, that sounds good to me. I have to admit, I did'nt know about the
possibility to register a Component with multiple services. When we
started
using Windsor we used the file based XML configuration and partly do
it today. And since the ResolveAll() worked as expected, we didn't think
about registering a component this way.
The multiservice concept resolves the problem i talked about. And the
need for code changes seems not to be as big as i suspected, since in
the end the call to and the behaviour of ResolveAll() stays the same,
if we change the registration process.
Thanks for the explanation.
Am schrieb Krzysztof Koźmic <[email protected]>:
> Thanks for the explanation. Actually supporting precisely this
scenario was the reason for introducing this behaviour in the first
place, back in 2008. And that's because back then Windsor only
supported single service per component. So you could have had
PatientTaskCalc registered either as IPatientTask, or as ITask but not
as both. So to workaround this limitation the ResolveAll ignored what
service you assigned to the component and just looked if its
assignable to the type you want.
>
>
>
> Later on though (not sure if RC3 had it, but all releases starting
with 2.0 did) we introduced concept of ForwardedHandler to allow
components to expose multiple services. That was piggy-backed a bit on
top of existing architecture at the time. In Wawel (codename for
Windsor vNext) that was rebuilt so that multi-service components are
now a core concept in Windsor.
>
>
>
> This removes the need for the workaround since now you can be
explicit about your intention:
>
>
>
> pContainer.Register(
Component.For().ImplementedByPatientTaskCalc>().LifeStyle.Transient);
>
> As a sidenote, you can simplify that registration even further by
relying on scanning, like this:
container.Register(AllTypes.FromAssemblyBla().BasedOnITask>().WithService.DefaultInterface().Configure(c
=> c.Lifestyle.Transient));
>
>
>
> You would get the same behaviour as you have now, with benefit of
being explicit.
>
>
>
> And that implicitness of current implementation is the biggest
problem and driver for change here (mostly to accommodate massively
popular ASP.NET MVC framework with breaks SRP and is a PITA to work
with, unless this is fixed).
>
>
>
> Looking forward to your (and others') insight on this.
>
>
>
> On 06/03/2011 3:59 AM, [email protected] wrote:
>
>
> Hi Krzysztof,
>
>
>
> one of the scenariois where i use this is the following:
>
> The application is extendable with any plugins. A costumer has also
the ability to extend the application with his own plugins.
>
> The base for such plugins is a framework wich defines the
architecture and some basic interfaces and classes so that the plugins
>
> can integrate properly. One of the reasons for user defined plugins
are Task that could be started by hand or in a chronological
>
> order at defined points in time. So we provide Task interfaces for
specific parts of the application (IPatientTask, IAppointmentTask and
so on).
>
> For any other Task not associated with a specific part of the
application, simply the ITask interface could be used. During startup
the app searches
>
> for plugins and loads them. After that all plugins are being
searched for known interface implementations to register them with the
container.
>
> In short it does something like this:
>
>
>
> pContainer.Register(
Component.For().ImplementedBy().Named("p_calc").LifeStyle.Is(Castle.Core.LifestyleType.Transient)
);
>
> pContainer.Register(
Component.For().ImplementedByPatientTaskMidnight>().Named("p_midnight").LifeStyle.Is(Castle.Core.LifestyleType.Transient)
);
>
> pContainer.Register(
Component.ForIAppointmentTask>().ImplementedByAppointmentTaskMonth>().Named("a_month").LifeStyle.Is(Castle.Core.LifestyleType.Transient)
);
>
> pContainer.Register(
Component.ForIAppointmentTask>().ImplementedByAppointmentTaskBack>().Named("a_back").LifeStyle.Is(Castle.Core.LifestyleType.Transient)
);
>
>
>
> In the application the user can now start a Task or can define, when
a specific Task should start automatically etc. If i want a specific
Task, i ask the container:
>
>
>
> IPatientTask[] pTasksP = pContainer.ResolveAllIPatientTask>(); //2
>
> IAppointmentTask[] pTasksA =
pContainer.ResolveAllIAppointmentTask>(); //2
>
>
>
> To get all the registered Tasks, i ask the container:
>
> ITask[] pAllT = pContainer.ResolveAll(); ///all 4
>
>
>
>
>
> So, in the end for this i need the current behaviour or i have to
change the current application code. Sure there are a lot of other
>
> ways to accomplish this but we decided years ago to do it that way,
because it is simple and it is there :-)
>
> There are other parts, where we use the same approach for instance
for text and document generation etc.
>
>
>
> Regards
>
>
>
>
>
>
>
>
>
> Am schrieb Krzysztof Koźmic [email protected]>:
>
> > That's a fair point and that's precisely why I started this thread
and asked for feedback.
>
> >
>
> > So can you shed some more light on the context in which you're
depending on current behaviour and why/if alternative approach (just
registering your components with the service you ResolveAll) would or
would not be feasable.
>
> >
>
> >
>
> >
>
> > I also don't want to derail this thread but i would also be
interested in hearing you scenario in which you're using
RemoveComponent. Perhaps if you could start another thread to discuss
that, that would be great.
>
> >
>
> >
>
> >
>
> > Krzysztof
>
> >
>
> >
>
> >
>
> > On 04/03/2011 11:49 PM, [email protected] wrote:
>
> >
>
> >
>
> > Jason, that may all be true, but I want to use the container as is
and don't want to rethink and rework thinks from release to release.
Now i use ResolveAll and
>
> >
>
> > want it to return all components implementing a specific service
no matter for what else they are registered. Next time i have to build
something new to do this.
>
> >
>
> > Now i use RemoveComponent. Next release it is not available
anymore and i have again to build something new. I don't know , i
thought i simply could use the lib
>
> >
>
> > to simplify my work where i have enough other things to think about.
>
> >
>
> >
>
> >
>
> > Am schrieb Jason Meckley [email protected]>:
>
> >
>
> > > Handler selectors are not a work around, they are how handler
selection should be done. the recommendation on the table fixes a
subtle, implicit bug. creating yet another method on IWindsorContainer
doesn't solve the problem, it solves the symptom.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > --
>
> >
>
> > >
>
> >
>
> > > 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.
>
> >
>
> >
>
> >
>
> >
>
> > --
>
> >
>
> > 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.
>
>
>
>
> --
>
> 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.
--
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.
