Why can't Windsor handle a TimeSpan constructor parameter?

[George Mauer]

I have a variety of classes in my project that take a TimeSpan in the
constructor which is to be provided from a settings class. So as an
example, I have things wired as follows

<component id="timed_alert_dialog"
service="DriverInterface2.UI.Presentation.UIInterfaces.ITimedDialog,
DriverInterface2.UI.Presentation"
type="DriverInterface2.UI.WinForms.Dialogs.AlertDialog,
DriverInterface2.UI.WinForms">
<parameters><timespan>${time_alert_dialogs_remain_on_screen}</
timespan></parameters>
</component>

<component id="time_alert_dialogs_remain_on_screen"
type="System.TimeSpan"
factoryId="global_settings"
factoryCreate="get_TimeAlertDialogsRemainOnScreen" />

But when I try to resolve timed_alert_dialog I get the following
error:
{"Could not convert from '${time_alert_dialogs_remain_on_screen}' to
System.TimeSpan"}
Inner Exception: {"Input string was not in a correct format."}

Some things I have learned while experimenting:
I can resolve time_alert_dialogs_remain_on_screen (the TimeSpan)
properly with no problem.
If I change the constructor to take an object that is later cast to a
TimeSpan then it works fine also.

This last point indicates an annoying yet quick way to resolve the
situation which is for obvious reasons, less than ideal. What is the
cause of the problem and is there any way I can resolve it for real?

Thanks a lot,
George Mauer

[Shawn Hinsey]

I've had luck with creating timestamps using the format "HH:MM:SS" in
the component parameter configuration, but I've never tried that
approach. Do you need to have a separate component for the timespan?
You could put the value in a property if it's reused.

[George Mauer]

I want the value to come from a property on a Settings class that gets
passed around to a related group of objects. I would prefer the
Settings class to be strongly typed. It would seem to me like that's
a pretty common way of doing things, if I'm going about it the wrong
way by all means tell me, since I'm just pulling this stuff out of my
butt.

On a side note, I'm also running into this issue when the constructor
takes an Int32 and, I assume I will run into it with any non-reference
object.

Without digging into the code, it seems like the input of a parameter
is assumed to be either a reference type or a string and no attempt at
casting is done. I would be surprised if someone hasn't run into this
annoyance before and written a module to solve it so if any can point
me in the right direction it would be greatly appreciated.

[Shawn Hinsey]

How are you setting the value of time_alert_dialogs_remain_on_screen?

[Shawn Hinsey]

I'm not very familiar with the factory facility is why I ask. Is it
possible that the object isn't in a valid state at dependency
resolution time?

[George Mauer]

I can't be 100% sure since I'm still very new at all this but I would
imagine not since I can do
IoC.Container.Resolve("time_alert_dialogs_remain_on_screen") with no
problem

On Oct 13, 4:02 pm, "Shawn Hinsey" <smhin...@gmail.com> wrote:
> I'm not very familiar with the factory facility is why I ask. Is it
> possible that the object isn't in a valid state at dependency
> resolution time?
>

[Shawn Hinsey]

Have you tried replacing the component reference with a string in
Timespan format, just to make sure nothing else is awry?
Alternatively, try configuring the referenced TimeSpan object with a
string via the parameters and lose the factory stuff. If that works,
at least you've isolated the issue, and someone more familiar with the
factory facility can probably chime in with the fix.

[George Mauer]

Yes, when registered in a string format these values work just fine.
It seems to definitely be a casting issue.

[Shawn Hinsey]

So it sounds like it's something to do with the factory facility. I
would suggest not using it there, because from what I can tell, it's
intended to be used more as a mechanism for configuring types that
require configuration via method invocations.

This might help clear that up:
http://blog.bittercoder.com/PermaLink,guid,07925133-ae33-41dd-bc50-2b49a5434e19.aspx

Good luck!

[George Mauer]

I agree, this method seems slightly awkward.

However, I don't understand what the proposed method is supposed to
be. Take the example where the constructor could be something like

TimedAlertDialog(TimeSpan time_remains_on_screen) {...}

And the value is to be read in from a database (say, an integer
representing milliseconds). What is the proposed method?

On Oct 13, 4:38 pm, "Shawn Hinsey" <smhin...@gmail.com> wrote:
> So it sounds like it's something to do with the factory facility. I
> would suggest not using it there, because from what I can tell, it's
> intended to be used more as a mechanism for configuring types that
> require configuration via method invocations.
>

> This might help clear that up:http://blog.bittercoder.com/PermaLink,guid,07925133-ae33-41dd-bc50-2b...

[Shawn Hinsey]

Ah, I am not sure what the canon recommendation would be in that case,
but I'd probably go down the same path you are. I'm guessing that
needing to read config from a database might be something that comes
up more than once, so what if you created a database configuration
service that you inject into classes that need it? You could implement
caching at that level, so ultimately it wouldn't be much different
from injecting the values directly into properties, and I think this
also better divides the responsibilities of your domain, leaving you
with a more cohesive set of classes in the end.

I'm hoping someone can chime in with the scoop on the factory facility.

[hammett]

If I had to do it, I'd probably make AlertDialog depend on the
settings class, but that's just a personal preference.

You have to note that ${} isn't an expression notation. That might be
the source of the problem as well.

I'll do a quick experiment here..

--
Cheers,
hammett
http://hammett.castleproject.org/

[hammett]

So, the problem is that there are two types of dependencies: services
and config/primitives. I dont think that's a bad thing, though, but
the thing is that they are not treat equally. The ${} is only
recognizable by service dependencies. Hence the problem.