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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
