You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Josh Canfield <jo...@gmail.com> on 2011/09/12 22:51:20 UTC
@Value(required=false) and @Symbol(required=false)
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: @Value(required=false) and @Symbol(required=false)
Posted by Josh Canfield <jo...@gmail.com>.
> Injecting a null value feels odd. What do you think about providing
> something like:
>
> public interface NullableSymbol<T> {
While I understand the sentiment, what do you gain? You still have to do the
null check to use the value.
Specify required=false tells you to expect null.
I suppose that we could instead add support for @Nullable
http://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/Nullable.java?r=24
On Sep 18, 2011 4:44 AM, "Igor Drobiazko" <ig...@gmail.com> wrote:
>
> On Fri, Sep 16, 2011 at 4:28 PM, Josh Canfield <joshcanfield@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 <hl...@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 <joshcanfield@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 <
joshcanfield@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-unsubscribe@tapestry.apache.org
> > >> For additional commands, e-mail: dev-help@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-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> Best regards,
>
> Igor Drobiazko
> http://tapestry5.de
Re: @Value(required=false) and @Symbol(required=false)
Posted by Igor Drobiazko <ig...@gmail.com>.
On Fri, Sep 16, 2011 at 4:28 PM, Josh Canfield <jo...@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 <hl...@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 <jo...@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 <jo...@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-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@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-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: @Value(required=false) and @Symbol(required=false)
Posted by Josh Canfield <jo...@gmail.com>.
> 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.
> 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.
On Mon, Sep 12, 2011 at 3:27 PM, Howard Lewis Ship <hl...@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 <jo...@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 <jo...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: @Value(required=false) and @Symbol(required=false)
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <jo...@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 <jo...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: @Value(required=false) and @Symbol(required=false)
Posted by Josh Canfield <jo...@gmail.com>.
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 <jo...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org