I think that's clutching a bit, Al, and just sounds like apologetics to me.
According to your premise, there could be situations in which there are organisations that have an automated coding standard which they have written *specifically for OBD* (remember: CF already supports this). Even if that was true - and, come on: it isn't - it's even more of an edge case than those that would find it helpful to be able to quickly comment-out an attribute from a tag whilst they're troubleshooting something, or just want to do what I have done in a multi-line CFML tag so as to clarify what's going on. Because if they're coming from CF they're going to have the expectation to be able to do this. This is a "fail" for OBD, to use the popular vernacular. Other systems support such a construct just fine, and no-one squirms about that. One that I use fairly frequently is the ability to embed comments within a regex: regexes get complicated very quickly for the untrained eye, so having inline comments is very handy. CFScript allows for comments in the middle of a statement, no probs. Also bear in mind that CFML is not XML or XHTML, and does not have any W3C standard. The only "standard" is "what Adobe decides to do" (The CFML Advisory Committee was a nice idea, but it didn't pan out, I think). So if we were talking about standards adherence being a driver for OBD... then that's *more* reason to implement this. Not less. And - equally - it's "how CF works" that defines what's correct practice or not. Not - as I said before - people's opinions of whether they like a certain construct or not. -- Adam On Jul 10, 8:16 pm, Alan Holden <[email protected]> wrote: > Perhaps the phrase "unreadable" was not meant to refer to the human act > of reading. > > I have experienced some entities - with a large development staff - that > need to enforce a set of coding standards. They employ scripts that will > parse (or "read") a developer's cfm file - when checked in - apply a > long sequence of regular expressions to insure that the code follows > their standard, and spit out a QA report. > > Having a bracketed tag nested within another one could present a problem > there. It also could be at odds with some XML/XHTML/W3C spec that I'm > too lazy to research right now. > > There are two opinions at odds here: 1) OpenBD's CFML should behave > exactly like Adobe's CFML, and 2) Nesting a bracketed tag within another > one is not a correct practice. Tags should contain attributes. > > I've spent enough time on this list to realize that opinion 1) is not > considered as some "prime directive" here - especially when another > opinion has a reasonable amount of merit. > > Al Holden -- Open BlueDragon Public Mailing List http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon online manual: http://www.openbluedragon.org/manual/ mailing list - http://groups.google.com/group/openbd?hl=en
