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