I like it. Along the same lines I was thinking that the translator parameter could be dropped in favor of an implied/inferred target translation type which would handle the "majority" of cases.
As always, anything that makes my lazy fingers type less code is a huge +1 from me :) On 4/3/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > I've been thinking of ways to reduce the amount of typing/XML when > building Tapestry pages. It's more of the "convention" style of > development. > > For example; the value parameter of a form element (TextField, > TextArea, etc.) is required. Often, not always, but often, the > component id matches the name of a property of the encloding page or > component. > > I think that you should be able to omit the value binding in that > case, and let the TextField figure it out. What the exact (flexible, > extensible) mechanism is for this, I'm not sure. > > Likewise, Form's should look for listener methods "doSuccess", > "doCancel", "doSubmit" as defaults for the corresponding pararameters. > > DirectLink should look for a "doFoo" listener method as the default > for its listener parameter (where "Foo" is the capitalization of its > component id). > > I think we could come up with defaults for displayName on TextField > and friends as well. Any others jump to mind? > > So, the wiring of a parameter is based on > 1) Explicit binding > 2) Autowiring > 3) default-value > 4) Failure > > > -- > Howard M. Lewis Ship > Independent J2EE / Open-Source Java Consultant > Creator, Jakarta Tapestry > Creator, Jakarta 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 Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
