I'm concerned that IBinding doesn't provide enough data to do this properly.
You can't get the type of property a binding is connected to. This would not be difficult to implement for most of the binding types (i.e., a MessageBinding is always a String, an AssetBinding is always an IAsset). For the workhorse, ExpressionBinding (i.e., OGNL), this is not so good. I don't know that OGNL has the ability to provide the type of a property, short of reading it. And if the property is currently null, that leaves you with very little. I supposed OGNL could be extended to provide this behavior, but it would be tricky and may be limited to declared types rather than actual types. Again, many pitfalls there. On 4/3/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > 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 > > -- 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]
