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]
