tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From RonPiterman <rpiter...@gmx.net>
Subject Re: T5: default binding is prop even in template
Date Wed, 17 Jan 2007 15:14:40 GMT
B.S.Navin wrote:
> 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.

I must disagree: take the title parameter of shell as example: we all 
know it is a string - should it be default prefixed with message, prop 
or literal ? all cases are used, literal maybe less often, but is surley 
used for quick prototyping - ouch! I have to look at the docu :(

now look at listener: isn't this one obvious?

So default prefix might be a very idee, but not everywhere...

I would throw in the air a convention suggestion:

so it woold be great to have a good fine grained *convention* as for 
where to use default prefix, and where not...

Cheers,
Ron




> 
> 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