Thank you for sending feedback.
I am aware of the nature of FactoryDefaults/ApplicationDefaults. It's a
good system, easy to understand, and works.
I have thought about this before posting as I use something similar already
in my code. I don't have default value conflicts, however, I do
occasionally have trouble with being unable to override a FactoryDefaults
value because it can only override it in one module.
I want to use the symbol as an ID to set/retrieve an overriding value with.
I also want to avoid processing the default and holding it in a map the
life of the application when it isn't needed.
I use Tapestry IoC for a modular application framework (not the tapestry
web framework). Maintaining many modules used in a variety of combinations
requires lots of defaults management and overriding. This is just one of
those things which I'd like to customize and I haven't looked at extending
the annotation processing yet. I'd appreciate being pointed at the
class/module to alter the annotation processing.
And, I have thought about it because I am using something similar now. I
use a Values service I inject and do:
> values.get(Service.THE_SYMBOL, DesiredType.class, theDefaultValue)
This way the symbol's key, it's default value, and its use are all close
together. If an application default or L10N value overrides the symbol,
then the default is never processed or stored. And, a different module's
implementation can use the same symbol and a different default value
without overriding it in FactoryDefaults.
So, the @DefaultValue annotation would allow me to eliminate this line and
instead have this parameter:
> @Symbol(Service.THE_SYMBOL) @DefaultValue("some default value")
> DesiredType value
On Tue, May 28, 2013 at 12:53 AM, Dmitry Gusev <dmitry.gu...@gmail.com>wrote:
> I can see one problem here -- nothing prevents you from specifying more
> than one @DefaultValue and you may get a conflict too late, as far as I see
> you can't control this. Have you thought about it?
>
>
> On Tue, May 28, 2013 at 12:23 AM, Eli Doran <e...@elidoran.com> wrote:
>
> > I've used @Symbols a lot. I appreciate its flexibility and coercion
> > ability.
> >
> > I started programming around it though and instead accessing SymbolSource
> > and TypeCoercer directly because it is missing the ability to specify a
> > default value, and the ability to ignore when a value can't be found.
> >
> > I made another service which uses SymbolSource and TypeCoercer to accept
> a
> > default value and avoid throwing an exception when a value isn't found.
> >
> > The more I use this the more I miss simply using @Symbol on a parameter.
> I
> > have to inject this new service and make the method call (I know, little
> > work really).
> >
> > I keep thinking adding an optional default parameter to @Symbol, or
> another
> > annotation like @DefaultValue would enhance the current functionality
> > without affecting how everyone is currently using it and how it behaves.
> >
> > Is this something the flexibility of Tap IoC would allow me to override
> > some processors or decorate current services to alter in my own
> > applications?
> >
> > Is this something anyone else is interested in having in Tapestry IoC?
> >
> >
> > A part of my motivation for this is it seems a nuisance being required to
> > put a default symbol value in the FactoryDefaults/ApplicationDefaults for
> > every use of @Symbol. I want to retain the distributed configuration so
> it
> > can be overridden but often I'd rather specify the default value in the
> > class using the Symbol. It keeps things together.
> >
> > Thank you
> >
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
