Re: Required parameters: also not null?
don't forget the BeanEditorForm... object may as well be null "Howard Lewis Ship" <[EMAIL PROTECTED]> 25.06.2008 00:06 Bitte antworten an "Tapestry users" An "Tapestry users" Kopie Thema Re: Required parameters: also not null? Working on this now, and there are plenty of cases where a binding is required but the value may be null; for example, TextField (the value may initially be null, but must be bound). On Tue, Jun 24, 2008 at 1:17 PM, Matt Kerr <[EMAIL PROTECTED]> wrote: > the 'value' proposition you mention is forward compatibility, no? > > i guess if fwd compatibility is not a concern - sure, do whatever. > > > On Tue, Jun 24, 2008 at 3:23 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: >> True, my concern is that we'll find that every use of required=true >> also has acceptNull=false, in which case we add complexity without >> providing value. >> >> On Tue, Jun 24, 2008 at 12:12 PM, Filip S. Adamsen <[EMAIL PROTECTED]> wrote: >>> +1 on something like that. >>> >>> -Filip >>> >>> On 2008-06-24 19:48, Thiago H. de Paula Figueiredo wrote: >>>> >>>> Em Tue, 24 Jun 2008 14:32:15 -0300, Matt Kerr <[EMAIL PROTECTED]> >>>> escreveu: >>>> >>>>> why not specify whether params allow null - rather than break things ? >>>>> default to the old behavior. >>>>> >>>>> it's not uncommon to have a null param - dunno why it would be >>>>> different in a component. >>>> >>>> Agreed 100%. Required = some value must be given to the parameter. Not >>>> null = some not null value must be given. Required != not null. >>>> >>>> We could add some like this to @Parameter and support it in tapestry-core >>>> easily: >>>> >>>> boolean acceptNull() default true; >>>> >>>> Then anyone writing components would get the automatic null value checking >>>> if wanted or needed without disrupting old code or changing how parameters >>>> work. >>>> >>>> Thiago >>>> >>>> - >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator Apache Tapestry and Apache HiveMind >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Required parameters: also not null?
Working on this now, and there are plenty of cases where a binding is required but the value may be null; for example, TextField (the value may initially be null, but must be bound). On Tue, Jun 24, 2008 at 1:17 PM, Matt Kerr <[EMAIL PROTECTED]> wrote: > the 'value' proposition you mention is forward compatibility, no? > > i guess if fwd compatibility is not a concern - sure, do whatever. > > > On Tue, Jun 24, 2008 at 3:23 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: >> True, my concern is that we'll find that every use of required=true >> also has acceptNull=false, in which case we add complexity without >> providing value. >> >> On Tue, Jun 24, 2008 at 12:12 PM, Filip S. Adamsen <[EMAIL PROTECTED]> wrote: >>> +1 on something like that. >>> >>> -Filip >>> >>> On 2008-06-24 19:48, Thiago H. de Paula Figueiredo wrote: Em Tue, 24 Jun 2008 14:32:15 -0300, Matt Kerr <[EMAIL PROTECTED]> escreveu: > why not specify whether params allow null - rather than break things ? > default to the old behavior. > > it's not uncommon to have a null param - dunno why it would be > different in a component. Agreed 100%. Required = some value must be given to the parameter. Not null = some not null value must be given. Required != not null. We could add some like this to @Parameter and support it in tapestry-core easily: boolean acceptNull() default true; Then anyone writing components would get the automatic null value checking if wanted or needed without disrupting old code or changing how parameters work. Thiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator Apache Tapestry and Apache HiveMind >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Required parameters: also not null?
the 'value' proposition you mention is forward compatibility, no? i guess if fwd compatibility is not a concern - sure, do whatever. On Tue, Jun 24, 2008 at 3:23 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > True, my concern is that we'll find that every use of required=true > also has acceptNull=false, in which case we add complexity without > providing value. > > On Tue, Jun 24, 2008 at 12:12 PM, Filip S. Adamsen <[EMAIL PROTECTED]> wrote: >> +1 on something like that. >> >> -Filip >> >> On 2008-06-24 19:48, Thiago H. de Paula Figueiredo wrote: >>> >>> Em Tue, 24 Jun 2008 14:32:15 -0300, Matt Kerr <[EMAIL PROTECTED]> >>> escreveu: >>> why not specify whether params allow null - rather than break things ? default to the old behavior. it's not uncommon to have a null param - dunno why it would be different in a component. >>> >>> Agreed 100%. Required = some value must be given to the parameter. Not >>> null = some not null value must be given. Required != not null. >>> >>> We could add some like this to @Parameter and support it in tapestry-core >>> easily: >>> >>> boolean acceptNull() default true; >>> >>> Then anyone writing components would get the automatic null value checking >>> if wanted or needed without disrupting old code or changing how parameters >>> work. >>> >>> Thiago >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Required parameters: also not null?
True, my concern is that we'll find that every use of required=true also has acceptNull=false, in which case we add complexity without providing value. On Tue, Jun 24, 2008 at 12:12 PM, Filip S. Adamsen <[EMAIL PROTECTED]> wrote: > +1 on something like that. > > -Filip > > On 2008-06-24 19:48, Thiago H. de Paula Figueiredo wrote: >> >> Em Tue, 24 Jun 2008 14:32:15 -0300, Matt Kerr <[EMAIL PROTECTED]> >> escreveu: >> >>> why not specify whether params allow null - rather than break things ? >>> default to the old behavior. >>> >>> it's not uncommon to have a null param - dunno why it would be >>> different in a component. >> >> Agreed 100%. Required = some value must be given to the parameter. Not >> null = some not null value must be given. Required != not null. >> >> We could add some like this to @Parameter and support it in tapestry-core >> easily: >> >> boolean acceptNull() default true; >> >> Then anyone writing components would get the automatic null value checking >> if wanted or needed without disrupting old code or changing how parameters >> work. >> >> Thiago >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Required parameters: also not null?
+1 on something like that. -Filip On 2008-06-24 19:48, Thiago H. de Paula Figueiredo wrote: Em Tue, 24 Jun 2008 14:32:15 -0300, Matt Kerr <[EMAIL PROTECTED]> escreveu: why not specify whether params allow null - rather than break things ? default to the old behavior. it's not uncommon to have a null param - dunno why it would be different in a component. Agreed 100%. Required = some value must be given to the parameter. Not null = some not null value must be given. Required != not null. We could add some like this to @Parameter and support it in tapestry-core easily: boolean acceptNull() default true; Then anyone writing components would get the automatic null value checking if wanted or needed without disrupting old code or changing how parameters work. Thiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Required parameters: also not null?
Em Tue, 24 Jun 2008 14:32:15 -0300, Matt Kerr <[EMAIL PROTECTED]> escreveu: why not specify whether params allow null - rather than break things ? default to the old behavior. it's not uncommon to have a null param - dunno why it would be different in a component. Agreed 100%. Required = some value must be given to the parameter. Not null = some not null value must be given. Required != not null. We could add some like this to @Parameter and support it in tapestry-core easily: boolean acceptNull() default true; Then anyone writing components would get the automatic null value checking if wanted or needed without disrupting old code or changing how parameters work. Thiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Required parameters: also not null?
why not specify whether params allow null - rather than break things ? default to the old behavior. it's not uncommon to have a null param - dunno why it would be different in a component. On Tue, Jun 24, 2008 at 12:54 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > I've been thinking of a change to how component parameters work. > > Currently, the required attribute of the Parameter annotation > indicates that a component parameter must be bound (either explicitly, > or to a default). It makes no assurances that it is bound to a > non-null value. > > I'm considering changing that, so that there would be a null check > for component parameters that are required, with an immediate failure > if the value bound to a required parameter is null. > > The question is: is this a destabilizing change? Has anyone written > components with required parameters that are allowed to be null? > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
