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: [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]
