I think that "more readable != shorter" by all means...
When default-binding is defined on a parameter then one cannot determine the
binding type just by reading the source code of a component. Therefore the
source code is harder to read. The binding definition falls apart two parts
in 2 separate files: the real <binding> and the default-binding which
actually defines the binding type.
It may seem trivial in case of listeners but it is not so logical for other
types.
For a very simple example the component developer decided that Submit's
label parameter's binding type is "literal" by default. I personally never
use it with literal: (instead almost always with message:), so when I see
<component id="sample" type="Submit">
<binding name="label" value="submit" />
...
then "submit" is a literal but it could be a message key or an OGNL
expression
as well.
I must check the Submit component's specification to make sure what it
really is.
It is application/developer dependent which default binding type fits best,
but in my opinion this changes even in an application!
This will be even worse in real applications and especially in case of
complex
third-party component libraries.
To make the component sources more consistent and easier to read,
default-binding should be removed, and if no explicit binding prefix is
defined then it should be handled as
- ognl in jwc/page
- literal in template
If default-binding remains in the framework then the only way to make the
sources easy to read is to always use an
explicit binding prefix. So if one wants to create easily shareable sources
then default-binding saves no coding just forces some extra code:
the ognl: and literal: prefix should always be explicitly defined as well.
Br,
Norbi
----- Original Message -----
From: "Chris Nelson" <[EMAIL PROTECTED]>
To: "Tapestry development" <[email protected]>
Sent: Wednesday, July 20, 2005 7:48 PM
Subject: Re: Default binding prefixes: good or bad?
Umm, how is listener="listener:doSubmit" more readable
than listener="doSubmit"?
Just curious...
--- Norbert Sándor <[EMAIL PROTECTED]> wrote:
I would choose #2 and completely remove
default-binding to enforce well
readable, consistent binding definitions.
If a binding prefix is not defined:
- in jwc/page it is ognl:
- in template it is literal
Br,
Norbi
----- Original Message -----
From: "Howard Lewis Ship" <[EMAIL PROTECTED]>
To: "Tapestry development"
<[email protected]>
Sent: Wednesday, July 20, 2005 5:35 PM
Subject: Default binding prefixes: good or bad?
With the new betas out, I'm thinking that it's
become easier to
discuss the binding prefixes.
I like how succinct the prefixes are but if we can
get a consensus, we
can change things around.
I would suggest that, if we remove explicit default
binding prefixes
on parameters, we still use a simpler system of
defaults: literal:
for HTML (or other templates), ognl: for XML and
elsewhere (such as
annotations).
<form jwcid="@Form" listener="doSubmit">
vs.
<form jwcid="@Form" listener="listener:doSubmit">
vs.
<form jwcid="@Form"
listener="ognl:listeners.doSubmit">
I prefer #1, but would be satisified with #2.
Either is better than
#3 (as it stands in Tapestry 3.0).
What are people finding now that they are
(hopefully) playing with Tapestry?
--
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]
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
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]
