Come to think of it, I already circumvented the restriction before, by using the component version (version 2 in my sample).
But in my current setup, I haven't been able to, because MyObject is a delegate, and I haven't been able to create that through a component (just yet) On Apr 23, 4:16 pm, Grimace of Despair <[email protected]> wrote: > I've actually got a kind of deamon which loads Binsor applications > like aspnet_wp would load ASP.NET applications (though not nearly as > advanced). This setup allows me writing (copmiled) class libraries > that do the nitpicking, while being able to throw them around within > different configuration settings. Just to say that the running code is > actually container-agnostic, and stuff like custom dependencies would > have to be taken care of by my daemon. > > Now for the custom dependencies: I guess that can't be done in Binsor, > or am I missing something? > > On Apr 23, 2:49 pm, Craig Neuwirt <[email protected]> wrote: > > > Not sure if this helps, but the parameters and configuration sections in > > binsor are used to expose the corresponding configuration model supported in > > MK. I don't believe custom conversions are handled for the values. > > However, when using Binsor, I generally only use those sections for > > Facility configurations that are already based on configuration. Otherwise, > > I just set the dependencies directly. These could be anything and just get > > added to the custom dependencies collection and bound directly at resolution > > time > > craig > > > On Thu, Apr 23, 2009 at 7:22 AM, Grimace of Despair < > > > [email protected]> wrote: > > > > The following string to string mapping works fine for me: > > > > component x: > > > _parameters: > > > __Map: > > > ___map(keymap) = { > > > ____"foo": "bar" > > > ___} > > > > A string to component map also does: > > > > component bar > > > component x: > > > _parameters: > > > __Map: > > > ___map(keymap) = { > > > ____"foo": @bar > > > ___} > > > > Now I'm trying to pass in a custom, non-primitive object: > > > component x: > > > _parameters: > > > __Map: > > > ___map(keymap) = { > > > ____"foo": MyObject() > > > ___} > > > > This fails with: > > > > Castle.MicroKernel.SubSystems.Conversion.ConverterException: No > > > converter registered to handle the type MyObject. > > > > I've done a little digging, and there are two remarks I have: > > > > 1. KeyMapBuilder relies on ConfigurationHelper.SetConfigurationValue, > > > which converts MyObject to a string, losing any reference to the > > > actual object. Most probably, there's a really logical explanation for > > > this scenario, but to me, it seems that the map gets severely limited > > > by the use of the said SetConfigurationValue. > > > > 2. Even if the value was not converted to a string, the > > > GenericDictionaryConverter might not be able to use the original > > > value, because it does a PerformConversion. Afaics (but I might be > > > wrong), this method won't handle the conversion because no converter > > > exist, while the value would already be of the correct type. > > > > Could it be that I'm trying to push things? I can imagine the > > > ConfigurationHelper uses string conversions for a reason, but the > > > inability to use custom objects in the map ... well... it sucks :) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" 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/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
