andyhot wrote:
Kent Tong wrote:
Howard Lewis Ship <hlship <at> gmail.com> writes:
I haven't gotten a lot of feedback ... Kent is very opposed to the
idea. Jesse and a few others are for it. I think it will be neat.
When Tapestry 4 was in development, I had voted for having default binding
prefixes for each parameter.
Now... let's just say i'm not sure any more - which explains my late reply.
So, since i don't yet have a preference, let me throw in this:
How about sidestepping the issue by either
-) making parameter names (somehow) imply the binding prefix.
-) having one-letter uppercased aliases for each prefix
I can't see the point here: to save me time tipping listener: (and
making typos more unlikly) make the template much more unreadable ?
I don't know why people want default prefixes - the benefit for me would
be to spare me input unneccessary bla into the template. instead of
typing: listener="lisenter:..." type listener="..." - and - as a
glorious sideeffect, make often mistakes such as (today) listener="..."
(unprefixed) which end up in an exception, not existant.
are you using VI for developement? ;)
Cheers,
Ron
I don't really see much future in the first, but the second is
interesting...
Here I'd like to explain why I am opposed to it. The supposed major
benefit of using default binding prefix is DRY. Why DRY? If there
is code duplication and for some reason I change this code, then I
will have to change some other code. This is bad for maintenance.
Now, let's return to the issue. Consider the following example:
<input type="text" t:type="TextField" value="prop:name"/>
The thinking behind default prefix is that there is linkage between
TextField+value and prop. However, let's consider changing TextField
to something else say PropertySelection, do we need to change prop?
No. What if we need to change the parameter? There is seldom such need
at all. What if we need to change from prop to say an imaginary ognl
prefix, do we need to change TextField or value? No.
As you can see above, there is absolutely no ripple effect of changes.
Therefore, this code is not violating DRY. So, what is the real
benefit of default prefix? The only benefit is saving some typing for
the programmer writing the code and less text to read for the
programmer reading the code. What is the cost? As Ron said, it is the
extra step in the mental process of a programmer writing or reading
the code: "What is the default prefix here?". Obviously, mental
process is the bottle neck in programming, not finger or eye ball
movements.
--
Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
---------------------------------------------------------------------
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]
