Sold!
This is the best argument so far (IMO). Informal bindings HAVE to be
literal in templates, which means only confusion if formal parameters in
the template have ANY other default.
Making specification bindings use literal by default will just be
painful to work with (too many "ognl:"s) - I believe that pain would
outweigh any consistency gain. I am comfortable with the idea that
template component declarations are handled differently from
specification component declarations (afterall they do look completely
different).
Seems Tapestry 3 got it right :-)
I like Jamie's suggestion to add DTD support for different binding types
- we need not lose the flexibility to add new binding types in the
future do we? The framework provides some standard ones (literal,
message, listener etc), but we can leave the expression="abc: syntax for
when someone wants to create a new prefix. If that prefix makes sense
to the framework as a whole, it can be added in later, and given DTD
support.
Richard
Mind Bridge wrote:
Hi,
Just my 2c:
At the very least, the informal parameters must always be 'literal' in
the templates to eliminate involuntary mistakes by the designers. This
is not at stake at the moment, but the leap is not that great from there
to formal parameters.
Similar logic can be used for 'novice' users -- with default-binding
they will feel like they can only code by example, as involuntary
mistakes would be much more likely. Not having default-binding would
make the code a bit longer, but at least you would need far less
knowledge to be productive (which is what Tapestry is about).
In other words, a new developer could start working much faster, rather
than waste a lot of time to ponder what the templates mean.
Someone said that shorter does not always mean clearer, and I think that
in this case he is particularly right.
An unrelated matter: I would suggest to replace 'literal' with 'text' or
sth short like that -- 'literal' is just too long, albeit verbally
accurate.
-mb
---------------------------------------------------------------------
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]
