Help the Committee - Summary — An Architect's View

Help the Committee - Summary

June 13, 2009 · 13 Comments

After the "Help the CFML Advisory Committee" thread got so long (145 comments at the time of writing this!), some folks asked for a summary. I just posted a detailed summary with explanations to the committee mailing list. Here's an abbreviated summary:

In first place with 18 votes was: introduce a set of objects!
In second place with 11 votes: use pure function notation using body= and sql= to pass in strings to mail() and query() respectively.
In third place with 9 votes: tagname(attributes) { writeOutput("string"); logic(); writeOutput("string"); }
In fourth place, a new idea, with 6 votes: introduce E4X syntax to allow tags in script.
In last place, my poor, unloved favorite, with just 4 votes: tag { }

Since we still need to handle custom tag invocation somehow, my recommendation to the committee is to look more deeply at the function notation, with a view to adding a form of cfimport that introduces a prefix/taglib so custom tags could be invoked as:

pfx:mytag(a=1,b=2,body="this is the body");

which would be equivalent to:

<pfx:mytag a="1" b="2">this is the body</pfx:mytag>

Without the body attribute, it would be a simple tag invocation like this:

<pfx:mytag a="1" b="2">

Thank you everyone for contributing to the thread! I'll keep you posted on what the committee decides to do next on this tough issue.

View count: 1504

Tags: cfml-advisory · coldfusion

13 responses so far ↓

1 Justin Carter // Jun 15, 2009 at 8:57 AM

The only hang-up on using a named body="" argument is if a custom tag already has an attribute called body then there will be a clash. Probably fairly rare but it could be possible.

Would it be worth also considering having the "tag body" as an unnamed argument that comes either first or last in the function call?

pfx:mytag("this is the body", a=1, b=2);
or
pfx:mytag(a=1, b=2, "this is the body");

Similarly for cfquery/cfmail...

cfquery(datasource="myDSN", name="qContacts",
"SELECT * FROM contacts"
);
or
cfmail(from="some@dude.com, to="other@guy.com",
"You've got mail"
);

I still think tag{} and E4X would be great for the flexibility of the language. You should be able to use script anywhere when it suits, *and* you should be able to use tags anywhere when it suits :)
2 Tom Chiverton // Jun 17, 2009 at 1:22 AM

Seems a sensible compromise. Are you also goind to look at 'here documents' or multi line strings so long SQL etc. can be made readable:
cf:query(a=1,b=2,sql=">>EOF
this is the body
and more here
and there
<<EOF
");
or
cf:query(a=1,b=2,sql="this is the body\
and more here\
and there");
3 Sean Corfield // Jun 17, 2009 at 11:14 AM

@Tom, CF strings are already multi-line!
4 Nolan Erck // Jun 22, 2009 at 11:59 AM

@Justin

The problem with an "unnamed" argument would be, it'd break doing things like "argumentCollection" on a function call. Personally, I'd rather see this be a case where "a small amount of CF8 code might break when you upgrade to CF9", and just ask people to rename their existing "body" argument to something else. Maybe Adobe could even update the "code profiler" tool that shipped with MX (to make sure all legacy code would run with the new MX engine). Then everyone would know, in advance, if their app is in danger of a naming conflict.

...not that anyone asked my opinion. ;)

-nolan
5 Justin Carter // Jun 22, 2009 at 2:33 PM

@Nolan: Yeah fair point. It wouldn't really break argumentCollection though, it just wouldn't be able to be a part of the argument collection struct that way - which is probably fine since a tag body isn't something you've ever been able to pre-configure and use in an attributeCollection anyway so I don't think the script version would suffer for it :)
6 Aaron Neff // Jun 24, 2009 at 7:36 PM

@ Justin

I agree w/ continuing to cater to developer preference (whether it be all-tag, all-script, or tag-and-script). So, even if it is in addition to one of the all-script suggestions, I believe it is very important that the tag{} suggestion *also* be implemented (to retain existing flexibility). ..btw, I already voted for tag{}, so I know this doesn't really count as a vote - just elaborating/agreeing :)
7 Aaron Neff // Jun 24, 2009 at 7:49 PM

Also, I'd like to retract my semi-vote for the 'cf'tagname() suggestion, since I agree w/ UDFs being properly scoped (and thus unaffected by the addition of new built-in functions).
8 Adam Tuttle // Jun 26, 2009 at 6:20 AM

Sean, How would the proposed notation (pfx:mytag(a=1,b=2,body="this is the body");) work for child custom tags? They aren't extremely prevalent today, but where you can find them, they are usually brilliantly used. See MangoBlog's templating system, for one example.
9 Sean Corfield // Jun 26, 2009 at 8:57 AM

@Adam, that's exactly the root of the problem we're wrestling with - and why this is such a hard problem to solve!
10 Joe // Jul 1, 2009 at 1:59 PM

I would like to be able to do:

<cfset cfcWhatever.new({name='joe',email='joe@here.com'},true)>
11 Sean Corfield // Jul 1, 2009 at 2:17 PM

@Joe, the CFML2009 spec will contain this syntax:

<cfset obj = new cfcWhatever( { name='joe', email='joe@here.com' }, true )>

as an alternative for:

<cfset obj = createObject( "component", "cfcWhatever").init( { name='joe', email='joe@here.com' }, true )>

(and, yes, full struct and array literal support will be part of the CFML2009 spec).

Does that address your comment? If not, could you explain in more detail what you're suggesting?
12 Joe // Jul 4, 2009 at 4:52 PM

That is great Sean. Big step forward. Also it would be awesome if we would have the ability to overload methods. Thank you
13 Sean Corfield // Jul 6, 2009 at 6:48 PM

@Joe, you cannot have method overloading in a dynamically typed language without a huge performance overhead.

An Architect's View

CFML, Clojure, Software Design, Frameworks and more...