I see this as like the split between implicit and declared components. Implicit components open up the possiblity of a lot of absuses and people were initially worried. Once they started building apps with implicit components, they set individual standards and practices for when to use implicit vs. when to use declared.
The practice for default bindings will be the same. Basically, there has to be a compelling reason *not* to use ognl as the default binding. In fact, there has to be a compelling reason to specify a default binding. In only a few cases, the default binding should not be ognl (or unspecified). Listener parameters, validator parameters, asset parameters. I think those will tend to be obvious and your nightmare scenario won't happen. On 5/11/05, Patrick Casey <[EMAIL PROTECTED]> wrote: > > I don't have quite as much to say on the subject, but I will chime > in to say I'm not a big fan of default binding either. I know what I was > learning tapestry it was very confusing to figure out whether I should be > typing "ognl:foo" or just plain "foo" and whether just plain foo was going > to be parsed or a literal. > > I don't really mind typing an extra five characters if it makes my > code more consistent and readable, so I at least would rather that ognl > always meant ognl, and a literal always be a literal. For me, having these > sorts of context specific behaviors just makes the product harder to learn > and harder to debug later for no real benefit (does skipping 5 characters > while typing *really* make much of a difference in the grand scheme of > things? If so, shouldn't we all use single character variable names > exclusively?) > > I guess I did have something to say on the topic after all ... > > --- Pat > > > -----Original Message----- > > From: Vjeran Marcinko [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, May 10, 2005 9:21 PM > > To: Tapestry users; Howard Lewis Ship > > Subject: Default binding recap [WAS: 4.0: listeners] > > > > Hi all. > > > > I posted about this recently on dev list, but I think I know how to > > express > > myself better now... > > > > Anyway, in 4.0 we now have multiple choices : > > 1. listener="ognl:listeners.formSubmit" > > 2. listener="listeners:formSubmit" > > 3. listener="formSubmit" > > > > First one is 3.0 compatibile, second and third have apeared in 4.0, and > > beside being shorter, they also use reflection less, thus are probably a > > bit > > faster. > > IMHO, although the shortest, problematic is third one. > > Why? Because it is the only one that is not self-descriptive. I requires > > you > > to switch to .jwc file to know what type of value that is. True, nobody > > forces me to use that style, but thing is that I won't be looking only at > > things developed by myself, but also at other's stuff, and that will force > > me to switch files. > > > > And I think that "listener" example isn't a good one, because whenever we > > see parameter called "listener", it's a kinda standardized name, and we > > all > > know it's a listener parameter, thus default binding has much more sense > > for > > that than normally. > > Let's say you have stumbled upon some .html developed by your co-worker > > who > > loves default bindings, and all you see is: > > <span jwcid="@AttributePresenter" attribute="shortVersion" /> > > <span jwcid="@Shotter" character="simple" value="parent" /> > > > > And although you remember these AttributePresenter and Shotter components > > because you worked with them 3 weeks ago, you cannot exactly remember now > > what types of parameters these attribute/character/value are, and you > > forced > > to look at their .jwc files :-( > > > > Regards, > > Vjeran > > > <snip> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
