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 <[EMAIL PROTECTED]> 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 <[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] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
