Yeah, that does seem like a pretty elephant sized stumbling block for that.
Maybe it's not important for the majority of cases anyways, as long as the docs get cleaned up and the old validators removed. Esp if the EditObject idea you blogged about materializes in a form that is widely accessible. On 4/3/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > 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] > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
