tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "B.S.Navin" <bsna...@effigent.net>
Subject Re: T5: default binding is prop even in template
Date Wed, 17 Jan 2007 14:49:49 GMT
I too am for default binding types for parameters - I feel, it does  
not make much difference if a developer needs to look at the  
documentation to know what's the default binding, or if he needs to  
explicitly specify the binding. In either case, he needs to know the  
binding type for that parameter.

So default bindings for parameters shouldn't affect developers much.

I also second Markus' idea of allowing the default to be overridden.  
This feature may be really helpful for projects that use custom  
bindings, whose values finally result in the same Class type.

- Navin

On 17-Jan-07, at 6:25 PM, Markus Joschko wrote:

> Wouldn't it be possible to combine both approaches?
> If no explicit binding type is given a default binding type for a
> parameter is assumed?
> The disadvantage is that it might confuse people as it allows to do
> the same thing in two different ways.
>
>
> On 1/17/07, D&J Gredler <djgredler@gmail.com> wrote:
>> I like the direction Howard is taking with the bindings, but I  
>> think Ron has
>> a good point. What matters is not only what the developer has to  
>> *do*, but
>> also what the developer has to *know*. This extends even to areas  
>> like
>> Jesse's suggestion of making this configurable: if this is  
>> configurable,
>> that configurability is just one more thing that Tapestry developers
>> can/should be aware of.
>>
>> A good test might be to ask: "given that the developer knows the  
>> standard
>> available binding types, will it be obvious which binding type  
>> corresponds
>> to this parameter?" Once this is done, it becomes a matter of  
>> debate as to
>> whether the increased load on the developer (having to conciously  
>> think
>> about the obvious default for a parameter) is worth the savings (less
>> typing, more concise code, DRY).
>>
>> I'd say continue down the per-parameter-defaults path without even  
>> making it
>> configurable, as long as they're all obvious and it's not going to  
>> create
>> any rifts in the community...
>>
>> Just my opinion, of course.
>>
>>
>> On 1/17/07, RonPiterman <rpiterman@gmx.net> wrote:
>> >
>> > At the late alpha / early beta days of T4, I was getting very  
>> confused
>> > with default binding, and argued strongly against it.
>> >
>> > I still think this can be very confusing - and am wondering if  
>> there is
>> > anything one could do to avoid the confusion:
>> >
>> > (Is default prefix going to affect both templates and annotations?)
>> >
>> > One thing we could do is decide as a development guideline, only  
>> very
>> > obvious bindings get a default prefix:
>> >
>> > most obvious for me are listener bindings, (today's) source,  
>> value and
>> > index in For, value in Form - any others com in mind?
>> >
>> >
>> > I must say I have my thoughts about the way the new mantra "let the
>> > framework do things for the developer" is being aplyied:
>> >
>> > for me, the mantra would be : "let the developer KNOW LESS"  
>> instead of
>> > DO LESS.  The default binding issue is not different. If I have  
>> to look
>> > at the docu in order to KNOW which default binding a parameter  
>> has -
>> > then its a bad feature. If used with great care - then maybe it can
>> > rock...
>> >
>> > Just my two Euro-Cent...
>> >
>> > Cheers,
>> > Ron
>> >
>> >
>> >
>> >
>> >
>> > Howard Lewis Ship wrote:
>> > > I'd really like to explore the potential for this approach  
>> (default
>> > > binding prefixes for parameters).
>> > >
>> > > I haven't gotten a lot of feedback ... Kent is very opposed to  
>> the
>> > > idea.  Jesse and a few others are for it. I think it will be  
>> neat.
>> > >
>> > > I'd don't want to ride roughshod over Kent's wishes, but I  
>> don't know
>> > > how to proceed ... we need a protocol for evaluating the  
>> results of
>> > > this experiment and deciding whether to commit to it or not  
>> while the
>> > > Djinn is still in the bottle.
>> > >
>> > > Ideas?
>> > >
>> > > On 1/16/07, Jesse Kuhnert <jkuhnert@gmail.com> wrote:
>> > >> That should be two. ;) (maybe my previous post wasn't clear  
>> on this)
>> > >>
>> > >> On 1/16/07, Howard Lewis Ship <hlship@gmail.com> wrote:
>> > >> > Well, that's one :-)
>> > >> >
>> > >> > On 1/16/07, Nick Westgate <nick@key-planning.co.jp> wrote:
>> > >> > > +1 for Howard's per parameter defaults. It looks great.
>> > >> > >
>> > >> > > I was firmly in the other camp, but the time seems right
 
>> with T5.
>> > >> > > (Still pondering Kent's latest post on this.)
>> > >> > >
>> > >> > > Cheers,
>> > >> > > Nick.
>> > >> > >
>> > >> >
>> > >> >
>> > >> > --
>> > >> > Howard M. Lewis Ship
>> > >> > TWD Consulting, Inc.
>> > >> > Independent J2EE / Open-Source Java Consultant
>> > >> > Creator and PMC Chair, Apache Tapestry
>> > >> > Creator, Apache HiveMind
>> > >> >
>> > >> > Professional Tapestry training, mentoring, support
>> > >> > and project work.  http://howardlewisship.com
>> > >> >
>> > >> >  
>> ---------------------------------------------------------------------
>> > >> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> > >> > For additional commands, e-mail: dev-help@tapestry.apache.org
>> > >> >
>> > >> >
>> > >>
>> > >>
>> > >> --
>> > >> Jesse Kuhnert
>> > >> Tapestry/Dojo team member/developer
>> > >>
>> > >> Open source based consulting work centered around
>> > >> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.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
>> >
>> >
>>
>>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message