On Fri, Sep 16, 2011 at 4:28 PM, Josh Canfield <joshcanfi...@gmail.com>wrote:
> > So what gets injected if the symbol isn't defined? tapestry-ioc
> > already throws an exception if a symbol does not exist.
>
> I would expect null if it's not required and not present.
>
Injecting a null value feels odd. What do you think about providing
something like:
public interface NullableSymbol<T> {
T get();
boolean exists();
}
which would be used to inject a nullable symbol value instead of the
symbol's target type.
So, instead of:
@Symbol(value="foo-symbol", required="false")
private String foo;
you would use:
@Symbol("foo-symbol")
private NullableSymbol<String> foo;
> > Although we are not methodical about it, there is an intuitive split
> > between service interfaces that other code uses vs. interfaces that
> > user code implementes. SymbolSource would fall into the former camp
> > (user code does invoke it, but does not implement it), so adding a new
> > findXXX method would be reasonable, and I think, better than
> > introducing an exception.
>
> True, the service is probably not implemented by anyone so adding the
> method could be added easily enough.
>
> If there is no objections I'll add this along with the field to the
> annotation.
>
I think it's absolutely ok to add new methods to SymbolSource interface.
>
> On Mon, Sep 12, 2011 at 3:27 PM, Howard Lewis Ship <hls...@gmail.com>
> wrote:
> > So what gets injected if the symbol isn't defined? tapestry-ioc
> > already throws an exception if a symbol does not exist.
> >
> > Although we are not methodical about it, there is an intuitive split
> > between service interfaces that other code uses vs. interfaces that
> > user code implementes. SymbolSource would fall into the former camp
> > (user code does invoke it, but does not implement it), so adding a new
> > findXXX method would be reasonable, and I think, better than
> > introducing an exception.
> >
> > On Mon, Sep 12, 2011 at 2:01 PM, Josh Canfield <joshcanfi...@gmail.com>
> wrote:
> >> This issue is in line with what I want to do:
> >> https://issues.apache.org/jira/browse/TAP5-1531
> >>
> >> In order to preserve the interface I would add a specific runtime
> >> exception "SymbolNotFoundException" instead of adding a method to the
> >> SymbolSource interface.
> >>
> >> On Mon, Sep 12, 2011 at 1:51 PM, Josh Canfield <joshcanfi...@gmail.com>
> wrote:
> >>> I don't always want to provide default values for symbols used
> >>> throughout my application, especially when used to configure third
> >>> party applications which provide their own defaults. I'd rather be
> >>> able to detect null values.
> >>>
> >>> Any objections to adding a "required" attribute to @Value and @Symbol?
> >>>
> >>> Josh
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> >> For additional commands, e-mail: dev-h...@tapestry.apache.org
> >>
> >>
> >
> >
> >
> > --
> > Howard M. Lewis Ship
> >
> > Creator of Apache Tapestry
> >
> > The source for Tapestry training, mentoring and support. Contact me to
> > learn how I can get you up and productive in Tapestry fast!
> >
> > (971) 678-5210
> > http://howardlewisship.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: dev-h...@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: dev-h...@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
