If tapestry was going to distinguish the binding type from the attribute name, then yes, because you'd have to have a unique attribute name, which means that you have to have the attribute name declared in the DTD since tapestry uses a validating parser. A possible workaround for custom types would be something like:
<binding name="foo" custom="prefix:value"/> But then, really, we're back where we started, right? :) Or... perhaps the binding prefix could stay for value... Then you could have attributes for the framework-defined binding types, and still have the prefix-method around for custom-types? In all reality, how often are people /really/ going to define their own binding types? Robert Jamie Orchard-Hays wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
