You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2006/04/03 21:34:45 UTC
Component autowiring
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Component autowiring
Posted by Gordon Henriksen <go...@mac.com>.
On Apr 3, 2006, at 4:55 PM, D&J Gredler wrote:
> Maybe if a FieldLabel's field parameter isn't set and its id is
> "XYZLabel", you assume the corresponding field's id is "XYZ"?
>
> As a side note, doing stuff like this means you *really* have to
> document it well, so that 1) users know to use it and get the
> productivity boost and 2) users aren't surprised by unexpected
> behaviour when they aren't intending to use it.
Well, any introductory materials need to be rewritten to start people
off abusing the new feature, and only as an advanced topic cover the
details of “customizing” it…
— G
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Component autowiring
Posted by D&J Gredler <dj...@gmail.com>.
Maybe if a FieldLabel's field parameter isn't set and its id is "XYZLabel",
you assume the corresponding field's id is "XYZ"?
As a side note, doing stuff like this means you *really* have to document it
well, so that 1) users know to use it and get the productivity boost and 2)
users aren't surprised by unexpected behaviour when they aren't intending to
use it.
On 4/3/06, Howard Lewis Ship <hl...@gmail.com> 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.
snip
I think we could come up with defaults for displayName on TextField
> and friends as well. Any others jump to mind?
Re: Component autowiring
Posted by an...@di.uoa.gr.
This will be useful, but let me see if i get this straight:
Autowiring will happen for some required parameters when no
specific value is defined for them. How is this different to
making the parameter optional and providing 'correct' default-values ?
>From Howard Lewis Ship <hl...@gmail.com>:
> 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: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Component autowiring
Posted by Norbert Sándor <de...@erinors.com>.
I think Tapestry is far from this game yet :)
But you are right: it is almost sure that these "automagical" features
would probably make more harm than good to the framework - IMO.
Let's wait for the reaction of the developers ;)
Regards,
Norbi
Ron Piterman wrote:
> Just another thing:
> There is a german card game called "doppelkopf" - I played it once and
> never again:
>
> Before we started, my friends explained to me the rules -
>
> then, almost every time I had a winning hand, a new "exception rule" -
> some special case - popped up -
>
> In my memory, this game is one of 5 simple rules and 50 exceptions
> from these 5 simple rules.
>
> some how this reminds me of tapestry...
>
> Cheers,
> Ron
>
>
> Ron Piterman wrote:
>> A Great Idea - IMO comes from the same idea-bug where default binding
>> came from - looks nice on paper, will make things complicated and
>> inconcistent in practice.
>>
>> I do believe that "making things easier" for the developer the way it
>> is practiced in tapestry is not very constructive.
>>
>> an example would be html component definition ( jwcid="@Any" ) -
>> while adding flexibility it opens a door to bad practice (IMO) -
>>
>> it enables fast developement of the first tapestry page - but
>> possibly causing you a great headache when maintaining your
>> application - so you don't really know where each component is
>> defined - you have to find it...
>>
>> There are some other features like this: let the user do the same
>> thing in 5 different ways. IMO this is no help. on the contrary. It
>> makes learning tapestry harder :
>>
>> to define a component do that: ...
>> or do that: ...
>> or do that: ...
>>
>> the result is confusing - now if there was a functional benefit...
>> ok, but just in order to avoid typing xml ? no thanks :-)
>>
>>
>> Cheers,
>> Ron
>>
>>
>> Howard Lewis Ship 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: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Component autowiring
Posted by Ron Piterman <rp...@gmx.net>.
Just another thing:
There is a german card game called "doppelkopf" - I played it once and
never again:
Before we started, my friends explained to me the rules -
then, almost every time I had a winning hand, a new "exception rule" -
some special case - popped up -
In my memory, this game is one of 5 simple rules and 50 exceptions from
these 5 simple rules.
some how this reminds me of tapestry...
Cheers,
Ron
Ron Piterman wrote:
> A Great Idea - IMO comes from the same idea-bug where default binding
> came from - looks nice on paper, will make things complicated and
> inconcistent in practice.
>
> I do believe that "making things easier" for the developer the way it is
> practiced in tapestry is not very constructive.
>
> an example would be html component definition ( jwcid="@Any" ) -
> while adding flexibility it opens a door to bad practice (IMO) -
>
> it enables fast developement of the first tapestry page - but possibly
> causing you a great headache when maintaining your application - so you
> don't really know where each component is defined - you have to find it...
>
> There are some other features like this: let the user do the same thing
> in 5 different ways. IMO this is no help. on the contrary. It makes
> learning tapestry harder :
>
> to define a component do that: ...
> or do that: ...
> or do that: ...
>
> the result is confusing - now if there was a functional benefit... ok,
> but just in order to avoid typing xml ? no thanks :-)
>
>
> Cheers,
> Ron
>
>
> Howard Lewis Ship 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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Component autowiring
Posted by Norbert Sándor <de...@erinors.com>.
I fully agree with Ron.
Extension libraries may contain these features but not the core itself,
so everyone can decide whether (s)he wants to use them. The core should
be flexible enough to allow such complex extensions of the framework,
but its features should remain well-defined and easy to understand (and
remember).
I think it is more important to make the proposed functional
enhancements for 4.1 and even for 5.
I think that instead of some "syntactic sugar", many Tapestry users
would be happy to see some advanced features in 4.1 which are planned
only in version 5 (based on the WIKI).
Regards,
Norbi
Ron Piterman wrote:
> A Great Idea - IMO comes from the same idea-bug where default binding
> came from - looks nice on paper, will make things complicated and
> inconcistent in practice.
>
> I do believe that "making things easier" for the developer the way it
> is practiced in tapestry is not very constructive.
>
> an example would be html component definition ( jwcid="@Any" ) -
> while adding flexibility it opens a door to bad practice (IMO) -
>
> it enables fast developement of the first tapestry page - but possibly
> causing you a great headache when maintaining your application - so
> you don't really know where each component is defined - you have to
> find it...
>
> There are some other features like this: let the user do the same
> thing in 5 different ways. IMO this is no help. on the contrary. It
> makes learning tapestry harder :
>
> to define a component do that: ...
> or do that: ...
> or do that: ...
>
> the result is confusing - now if there was a functional benefit... ok,
> but just in order to avoid typing xml ? no thanks :-)
>
>
> Cheers,
> Ron
>
>
> Howard Lewis Ship 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: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Component autowiring
Posted by Ron Piterman <rp...@gmx.net>.
A Great Idea - IMO comes from the same idea-bug where default binding
came from - looks nice on paper, will make things complicated and
inconcistent in practice.
I do believe that "making things easier" for the developer the way it is
practiced in tapestry is not very constructive.
an example would be html component definition ( jwcid="@Any" ) -
while adding flexibility it opens a door to bad practice (IMO) -
it enables fast developement of the first tapestry page - but possibly
causing you a great headache when maintaining your application - so you
don't really know where each component is defined - you have to find it...
There are some other features like this: let the user do the same thing
in 5 different ways. IMO this is no help. on the contrary. It makes
learning tapestry harder :
to define a component do that: ...
or do that: ...
or do that: ...
the result is confusing - now if there was a functional benefit... ok,
but just in order to avoid typing xml ? no thanks :-)
Cheers,
Ron
Howard Lewis Ship 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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Component autowiring
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <hl...@gmail.com> 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 <jk...@gmail.com> 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 <hl...@gmail.com> 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: tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> > --
> > 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: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://opennotion.com
Re: Component autowiring
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <jk...@gmail.com> 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 <hl...@gmail.com> 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: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> 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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Component autowiring
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <hl...@gmail.com> 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: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://opennotion.com
Re: Component autowiring
Posted by Kevin Menard <km...@servprise.com>.
On 4/3/06 3:34 PM, "Howard Lewis Ship" <hl...@gmail.com> wrote:
> 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.
Heh, it'll be interesting to see how people feel about this. Allowing
default bindings to be specified in components didn't go over too well . . .
By the way, I'm for it. Anything that reduces the potential number of typos
is a good thing for me.
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org