we've been relying on order to do decorators, with quite good results.
We're cutting edge here, we give people scissors.
Current design keeps selectors independent, which I consider to be a
good thing.
You don't have to have just one selector if you need so. I expressed my
personal preference, nothing more. I would use more than a single
selector if I felt a need with no hesitation.
Also current design does not put any requirements at you WRT
model.Interceptors.
Perhaps it would be more beneficial if we moved from abstract concept to
some actual example where you feel having that capability (single jar of
interceptors passed between all selectors) would be required.
cheers,
Krzysztof
On 3/10/2010 10:53 PM, Simone Busoli wrote:
I see selectors as a step in the pipeline where you can apply
additional concerns, you don't care about what's already there, you
just add behavior if necessary.
That's why I don't think there should be only 1 selector and why a
selector shouldn't care about the stuff that's already in
model.Interceptors. That's why I'm saying we're probably looking at
things under a different perspective.
About order of registration for selectors, I think it's a very bad way
of doing things. To me the order of two calls to container.Register
(or most of what else you could put into the container: facilities,
interceptors,...) should mean as much as the order of two fields in a
class.
If you're relying on that you're looking for troubles.
2010/3/10 Krzysztof Koźmic <[email protected]
<mailto:[email protected]>>
On 3/10/2010 10:37 PM, Simone Busoli wrote:
inline
2010/3/10 Krzysztof Koźmic <[email protected]
<mailto:[email protected]>>
On 3/10/2010 10:15 PM, Simone Busoli wrote:
2010/3/10 Krzysztof Koźmic <[email protected]
<mailto:[email protected]>>
On 3/10/2010 9:59 PM, Simone Busoli wrote:
inline
2010/3/10 Krzysztof Koźmic <[email protected]
<mailto:[email protected]>>
you put interceptors in whatever order you please.
how?
You create the array yourself in the selector. You
choose what to put there, and in what order. it doesn't
even have to have anything in common with
componentModel.Interceptors collection
Can you see that all interceptors in model.Interceptors are
appended after those selected by all selectors?
Yes, I can see that. I would execute that code only when no
selector has opinion about component model in question.
I'm not sure that would be a good choice, but we definitely need
to define what selectors are for. In my opinion they should have
a chance to modify the existing collection of interceptors. If
they don't care about the order then they will eventually append
their stuff otherwise they will do nothing. With the current code
we're really looking for bugs with duplicate interceptors
appended at the end.
Why wouldn't this be a good choice?
Either selectors want to override the choice, or we go with
default. Should work IMO.
between selectors order of selectors transfers to
order of
interceptors. Plus I think you should not have
multiple selectors for
one model so it's a non-issue anyway.
why? I'm using multiple selectors to apply different
and unrelated concerns to models. Do you think I should
centralize a bunch of unrelated stuff into the same class?
Give me a scenario. But despite of it, doesn't order of
selectors give you enough control?
A selector handling whether we need to add transaction
interceptor and another handling exception-related stuff.
Ideally I wouldn't like to depend on the order of selectors
and put that logic in the selectors themselves, for
instance, transaction interceptor should be last. (in this I
would like to extend InterceptorReferenceCollection to
support keeping an interceptor in a certain position even if
other interceptors are added later)
now we're talking :)
I still think that you can achieve this with ordering of
selectors without changing the interface. Plus you always can
use IInterceptorSelector to select/order interceptors at a
method level.
Would you be confident in relying on the order in which you
register your selectors? I'd prefer to let the selector itself
decide where to put its interceptor/s.
I think I would 99% of the time. And for the remaining 1% I'd use
IInterceptorSelector.
in addition I'm against passing interceptors
selected by one selector,
to subsequent selectors.
this is the current code. how do you apply order? how
do you remove interceptors?
foreach(IModelInterceptorsSelector selector in
selectors)// selectors are asked in order you register
them in
{
InterceptorReference[] interceptors =
selector.SelectInterceptors(model);
+ if (interceptors == null)
+ {
+ continue;
+ }
+
+ foreach (InterceptorReference interceptor in
interceptors)
+ yield return interceptor; // interceptors are
returned in order selector put them in the array
}
+
+ foreach (InterceptorReference interceptor in
model.Interceptors)
+ yield return interceptor;
}
Note that model.Interceptors are concatenated to anything
returned by selectors, so you don't have control unless you
modify the collection directly.
2010/3/10 Simone Busoli <[email protected]
<mailto:[email protected]>>:
> Except that I don't agree with this principle,
the return value doesn't let
> you specify where exactly to put the interceptor.
So the return value
> provides a subset of the functionality provided
by the input collection.
>
> 2010/3/10 Krzysztof Koźmic
<[email protected]
<mailto:[email protected]>>
>>
>> void methods should not modify their arguments
>
> --
> 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]
<mailto:[email protected]>.
> To unsubscribe from this group, send email to
> [email protected]
<mailto:castle-project-users%[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:castle-project-users%[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:castle-project-users%[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:castle-project-users%[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:castle-project-users%[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.
