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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> >> That should be two. ;) (maybe my previous post wasn't clear
on this)
> >>
> >> On 1/16/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
> >> > Well, that's one :-)
> >> >
> >> > On 1/16/07, Nick Westgate <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >> >
> >> >
> >>
> >>
> >> --
> >> 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: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
