Krzysztof, But the name of the inner-parameter doesn't get passed to the HandlerSelector, from the tests that I've run. I don't understand how that method that checks whether the key is "inner" works. I must be missing something...?
Joni On Mar 9, 12:00 pm, Krzysztof Koźmic (2) <[email protected]> wrote: > Joni, > > the scenario in the wiki is just a sample. > You *can* extend it to make it work as you want by extending the > facility to your needs. > > for example call inner of SecurityDecorator securityInner, inner of > TransactionDecorator transactionInner etc... than you can pick > appropriate handler based on your decorator priority > > On 9 Mar, 10:50, joniba <[email protected]> wrote: > > > I would also like to add that the scenario discussed > > onhttp://stw.castleproject.org/Windsor.Decorators.ashx, as far as I can > > tell, does not support decorator chains, but only a single decorator. > > Because I could have a security-decorator that expects as its inner a > > transaction-decorator, whose inner would be the actual implementation. > > In which case the SelectHandler code, assuming the "inner" key could > > be passed to it, would still not be able to provide the desired > > functionality. > > > Joni > > > On Mar 9, 11:32 am, joniba <[email protected]> wrote: > > > > Hi Krzysztof, > > > Thanks for the links. Perhaps you can help me understand something > > > from the first one. Please bear with me as I am just getting started > > > with Castle. > > > > My question is about this method: > > > > public IHandler SelectHandler(string key, Type service, IHandler[] > > > handlers) > > > { > > > if (!"inner".Equals(key, > > > StringComparison.OrdinalIgnoreCase)) > > > { > > > return > > > handlers.Where(IsDecorator).FirstOrDefault(); > > > } > > > > return handlers.Where(h => IsDecorator(h) == > > > false).FirstOrDefault(); > > > } > > > > First, in order for a key to be passed to the SelectHandler method, I > > > would need to ask the container to resolve by key which, if I > > > understand correctly, it won't "just do" because my (in the example) > > > CustomerRepositoryDecorator has a parameter named "inner" that needs > > > to be resolved. > > > Hence, my conclusion is that registering the decorator would look > > > something like this: > > > > container.Register > > > ( > > > Component.For(typeof(IRepository<Customer>)) > > > .ImplementedBy(typeof(CustomerRepositoryDecorator)) > > > .DynamicParameters > > > ((kernel, dict) => > > > dict["inner"] = > > > kernel.Resolve<IRepository<Customer>>("inner") > > > ) > > > ); > > > > But of course that can't work because I have not registered any > > > component with key "inner". And I couldn't register the > > > CustomerRepository with key "inner" because there could be many > > > decorators or many repositories and the key must be unique. > > > > Could you tell me what I'm missing? > > > > Thanks > > > Joni > > > > On Mar 8, 8:04 pm, Krzysztof Koźmic <[email protected]> > > > wrote: > > > > >http://stw.castleproject.org/Windsor.Decorators.ashxhttp://ayende.com... > > > > > On 3/8/2010 6:47 PM, joniba wrote: > > > > > > Hi Krzysztof, how would implementing the IHandlerSelector help me? How > > > > > will I differentiate between the initial call to (continuing the > > > > > example) > > > > > > container.Resolve<IWriteRepository<Document>>() > > > > > > With castle windsor's internal attempt to resolve the > > > > > SecurityRepositoryDecorator's "inner" parameter? > > > > > > Thanks > > > > > Joni > > > > > > On Mar 8, 7:17 pm, Krzysztof Koźmic<[email protected]> > > > > > wrote: > > > > > >> use IHandlerSelector > > > > > >> On 3/8/2010 5:59 PM, joniba wrote: > > > > > >>> Hi all, I'm trying to use Castle Windsor to implement decorator > > > > >>> chains, as per Ayende's msdn post. However, I'm using the fluent > > > > >>> API, > > > > >>> and I want to know if it can be done en masse. > > > > > >>> Without the decorators I have: > > > > > >>> container.Register > > > > >>> ( > > > > >>> AllTypes.FromAssembly(assembly) > > > > >>> .IncludeNonPublicTypes() > > > > >>> > > > > >>> .BasedOn(typeof(IWriteRepository<>)).WithService.Base() > > > > >>> .Configure(component => > > > > >>> component.LifeStyle.Transient) > > > > >>> ); > > > > > >>> (Which works fine.) > > > > >>> My decorators also implement IWriteRepository<T>, and take as the > > > > >>> inner, an IWriteRepository<T>. For example: > > > > > >>> public class SecurityRepositoryDecorator<TEntity> : > > > > >>> IWriteRepository<TEntity> > > > > >>> { > > > > >>> private IWriteRepository<TEntity> inner; > > > > > >>> public > > > > >>> SecurityRepositoryDecorator(IWriteRepository<TEntity> > > > > >>> inner) > > > > >>> { > > > > >>> this.inner = inner; > > > > >>> } > > > > >>> } > > > > > >>> Is this impossible because of a circular reference to > > > > >>> IWriteRepository<>? > > > > >>> I would like to get to: > > > > > >>> var repository = container.Resolve<IWriteRepository<Document>>(); > > > > > >>> And have this return a SecurityRepositoryDecorator wrapping a > > > > >>> DocumentRepository. > > > > >>> Any ideas are appreciated. > > > > > >>> Joni -- 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.
