Luis, dependencies can be marked required if they are a constructor arg, but is there a way to denote require/optional for mixins specified in cfproperty metadata?
I still wish there was a way to mark constructor arguments so WireBox would overlook them completely and NOT try to resolve them. Right now all constructor args are assumed that I want WireBox to supply them regardless of whether or not they are required. (Builder.buildArgumentCollection() )
My use case for that is occasionally I’ll have a component that can be instantiated directly, or extended, but I ONLY need to supply the constructor arguments via the super scope from the sub class when it is extended. If I’m creating it directly, I don’t need to supply the constructor args. Now, I could mark them as optional and let WireBox silently fail every time it tried to resolve them, but I’d rather have a way to say “Hey, ignore me WireBox!” on my constructor args since I won’t want WireBox even wasting any time looking for them, or worse yet, digging up some random model with the same name as my cfargument’s name.
(I originally brought this up in February in this thread: http://groups.google.com/group/coldbox/browse_thread/thread/f90cbcc1269207b3/4a91a5b760603d7c)
I have updated the logging as it was definitely not good to not say
what target was requesting the dependency so it could log it.
Second, I could have sworn constructor arguments where optional if the
'inject' annotation was not there. I guess I missed that, but the
original intent was that constructor arguments only get wired if they
are marked with 'inject' same as properties, setters,etc. So now, it
should skip constructor arguments that have NO inject annotation or
are set as required = false. Now remember, this is only the case when
autowiring is enabled. If you define the constructor arguments in
your binder then this is skipped.
BuildDSLDependency now should log a not found dependency as an error
and throw an exception. Why, well, because in all reality, you have
requested something and the object target should be a good citizen
object, meaning if its dependency that was marked and requested is not
found, then an exception should be raised. As for Andrew's use case,
I would suggest a provider or custom factory method, as that is not
the original intent of the wiring.
I also updated the di discoveries as I found out that cf caches
metadata on objects. So adding items to it would not reflect changes
unless you clear the template and component cache.