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<IPatientTask>().ImplementedBy<PatientTaskCalc>().Named("p_calc").LifeStyle.Is(Castle.Core.LifestyleType.Transient)
);
pContainer.Register(
Component.For<IPatientTask>().ImplementedBy<PatientTaskMidnight>().Named("p_midnight").LifeStyle.Is(Castle.Core.LifestyleType.Transient)
);
pContainer.Register(
Component.For<IAppointmentTask>().ImplementedBy<AppointmentTaskMonth>().Named("a_month").LifeStyle.Is(Castle.Core.LifestyleType.Transient)
);
pContainer.Register(
Component.For<IAppointmentTask>().ImplementedBy<AppointmentTaskBack>().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.ResolveAll<IPatientTask>(); //2
IAppointmentTask[] pTasksA = pContainer.ResolveAll<IAppointmentTask>(); //2
To get all the registered Tasks, i ask the container:
ITask[] pAllT = pContainer.ResolveAll<ITask>(); ///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.
