Right--that was the problem Howard mentioned. Would we actually need
custom types in the DTD, or is that just a convenience?
Jamie
On Aug 12, 2005, at 12:18 PM, Robert Zeigler wrote:
Jamie Orchard-Hays wrote:
The brief history is that at first people thought the default
bindings
would be a good idea, but in use a lot of developers kept getting
confused--"is it literal? Is it ognl? What is it?" So, after a
lot of
discussion on the list, we voted an agreed to move to clarity and
consistency over terseness. I suggested using:
<binding name="foo" expression="bar" OR value="bar" OR
validators="bar">
as a way to enjoy terseness, clarity and DTD completion/
validation, but
I believe that Howard said there was a problem with this approach.
Jamie
The issue with this approach is that every time you add a binding
type,
you have to extend the DTD. Which makes it very difficult for
users to
add custom binding types, etc.
Robert
On Aug 12, 2005, at 10:17 AM, Kevin Menard wrote:
Howard Lewis Ship wrote:
How about:
<binding name="displayName">literal:E-mail Address</
binding>
<binding name="validators" value="validators:required,
email"/>
<binding name="value" value="email"/>
This is legal in 4.0 as well.
It seems like it might be a bit easier to read. It's still overly
verbose and prone to typos. I guess packing two bits of
information in
a single string just really doesn't sit very well with me. I
think it
makes the whole thing harder to read. In order to really
understand it,
I have to find the first ':' and separate the two entities in my
head.
It's a mental step that really isn't necessary if they were just
split
out to begin with. Additionally, by explicitly splitting them up
there's really no way to screw that mental step up. I just have
this
sinking feeling that trying to represent two pieces of data in a
single
unit is going to cause more room for error than if the two were
dealt
with in isolation.
So, I see there being a mental block any time someone needs to
read the
value, which is going to cost everyone time every time they read
it, at
the cost of saving the initial writer a few seconds of typing if
there
were an actual "type" attribute. I also see an increased risk
of typos
that won't be caught until runtime, which will also lower
productivity.
Perhaps I'm missing something here? I'm not really sure what we're
gaining but I can certainly see what we're losing. I'll admit to
not
having used Tapestry on any huge in production webapps and my total
experience with the framework has only been about a year, so
maybe my
lack of experience is somehow a roadblock.
Also, please don't take this as a crap on all your work. I am
generally
very pleased with Tapestry 4 and I have nothing but the utmost
respect
for you folks that are pouring all this energy into making
Tapestry a
better product.
Thanks,
Kevin
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: tapestry-dev-
[EMAIL PROTECTED]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
