Re: DynamicProperties vs. UsingFactoryMethod - Problems with (optional) property injection

2013-02-19 Thread bhaalsen
They are just a bit more dynamic than an anonymous object or a dictionary 
passed into DynamicParameters.
Wouldn't it work to run that delegate at resolve time to update 
CurrentState? Of course, with some sort of indicator to explicitly advise 
the container to do this, else it would probably slow down things a lot.

Since I'm using 
thishttp://mikehadlow.blogspot.co.at/2010/02/10-advanced-windsor-tricks-9.htmltrick
 here, I could've imagined implementing something similar to Parameter 
and ServiceOverrides that lets me specify an explicit dependency on another 
component (with possibly implicit/case-insensitive mapping of properties to 
ctor-parameters) - however, I didn't get around to try this yet, so I'll be 
stuck with the UsingFactoryMethod workaround for now.

On Monday, February 18, 2013 10:26:55 PM UTC+1, Krzysztof Koźmic wrote:

  Yeah, since dynamic parameters are just that - dynamic, WIndsor has no 
 way to statically determine which parameters will be provided. 

 The workaround for now is to make the property mandatory when registering 
 Foo

 HTH
 -- 
 Krzysztof Kozmic


-- 
You received this message because you are subscribed to the Google Groups 
Castle Project Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to castle-project-users+unsubscr...@googlegroups.com.
To post to this group, send email to castle-project-users@googlegroups.com.
Visit this group at http://groups.google.com/group/castle-project-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.




Re: DynamicProperties vs. UsingFactoryMethod - Problems with (optional) property injection

2013-02-19 Thread Krzysztof Kozmic
yup, the factory method will get you there for now, and I'm happy to have a 
look at more constrained version of dynamic parameters for future release  

--  
Krzysztof Kozmic


On Tuesday, 19 February 2013 at 8:13 PM, bhaal...@gmail.com wrote:

 They are just a bit more dynamic than an anonymous object or a dictionary 
 passed into DynamicParameters.
 Wouldn't it work to run that delegate at resolve time to update CurrentState? 
 Of course, with some sort of indicator to explicitly advise the container to 
 do this, else it would probably slow down things a lot.
  
 Since I'm using this 
 (http://mikehadlow.blogspot.co.at/2010/02/10-advanced-windsor-tricks-9.html) 
 trick here, I could've imagined implementing something similar to Parameter 
 and ServiceOverrides that lets me specify an explicit dependency on another 
 component (with possibly implicit/case-insensitive mapping of properties to 
 ctor-parameters) - however, I didn't get around to try this yet, so I'll be 
 stuck with the UsingFactoryMethod workaround for now.
  
 On Monday, February 18, 2013 10:26:55 PM UTC+1, Krzysztof Koźmic wrote:
  Yeah, since dynamic parameters are just that - dynamic, WIndsor has no way 
  to statically determine which parameters will be provided.  
   
  The workaround for now is to make the property mandatory when registering 
  Foo
   
  HTH
  --  
  Krzysztof Kozmic
 --  
 You received this message because you are subscribed to the Google Groups 
 Castle Project Users group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to castle-project-users+unsubscr...@googlegroups.com 
 (mailto:castle-project-users+unsubscr...@googlegroups.com).
 To post to this group, send email to castle-project-users@googlegroups.com 
 (mailto:castle-project-users@googlegroups.com).
 Visit this group at http://groups.google.com/group/castle-project-users?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.
   
   

-- 
You received this message because you are subscribed to the Google Groups 
Castle Project Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to castle-project-users+unsubscr...@googlegroups.com.
To post to this group, send email to castle-project-users@googlegroups.com.
Visit this group at http://groups.google.com/group/castle-project-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.




Re: DynamicProperties vs. UsingFactoryMethod - Problems with (optional) property injection

2013-02-18 Thread bhaalsen
Dang, my colleague just linked me to 
http://issues.castleproject.org/issue/IOC-367 which seems to be exactly my 
problem - the real application does exactly that (having a WCF Service 
which doesn't want to start).

-- 
You received this message because you are subscribed to the Google Groups 
Castle Project Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to castle-project-users+unsubscr...@googlegroups.com.
To post to this group, send email to castle-project-users@googlegroups.com.
Visit this group at http://groups.google.com/group/castle-project-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.




Re: DynamicProperties vs. UsingFactoryMethod - Problems with (optional) property injection

2013-02-18 Thread Krzysztof Kozmic
Yeah, since dynamic parameters are just that - dynamic, WIndsor has no way to 
statically determine which parameters will be provided. 

The workaround for now is to make the property mandatory when registering Foo

HTH
-- 
Krzysztof Kozmic


On Tuesday, 19 February 2013 at 12:03 AM, bhaal...@gmail.com wrote:

 Dang, my colleague just linked me to 
 http://issues.castleproject.org/issue/IOC-367 which seems to be exactly my 
 problem - the real application does exactly that (having a WCF Service which 
 doesn't want to start).
 -- 
 You received this message because you are subscribed to the Google Groups 
 Castle Project Users group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to castle-project-users+unsubscr...@googlegroups.com 
 (mailto:castle-project-users+unsubscr...@googlegroups.com).
 To post to this group, send email to castle-project-users@googlegroups.com 
 (mailto:castle-project-users@googlegroups.com).
 Visit this group at http://groups.google.com/group/castle-project-users?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

-- 
You received this message because you are subscribed to the Google Groups 
Castle Project Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to castle-project-users+unsubscr...@googlegroups.com.
To post to this group, send email to castle-project-users@googlegroups.com.
Visit this group at http://groups.google.com/group/castle-project-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.