• Simon Horwith wants to see lots of Java-like stuff added, as well as several more mainstream enhancements.
• Brian Kotek wants to see less Java and more presentation tier power.
• Brandon Harper wants to see more administration, more enterprise control and integration support.

So, first up, despite being a huge advocate in the past for adding Java-like features to ColdFusion, I want to go on record as saying that I do not think ColdFusion needs interfaces or constructors or null or method overloading (heaven help us!) or any number of other Java-like features. We have full integration with Java and we can drop into Java whenever we want and use Java if we're so attached to those features.

If anything, I think ColdFusion would benefit more from taking cues from other dynamic languages such as Smalltalk and, yes, Ruby.

Brandon's list is mostly focused on enabling ColdFusion to play better in the enterprise space from a pragmatic, management and administration point of view and I like his list.

Brian's list isn't very specific but I like his thinking: the Java-like stuff would get used, true, but would mostly benefit a small core of OO developers whereas the vast majority of ColdFusion developers would benefit far more from having the effort and resources expended on things that solve general real-world problems, which are mostly user interface and integration issues.

Feel free to comment here on on Simon's, Brian's or Brandon's blogs. I'm sure we'll all watching all those comments now.

Even if it's pie-in-the-sky, I'd love to see a CF console where I can pass parameters to a CFC on the command line and see what it returns. The ability to work with models in Rails without having to refresh a browser page is a treat.

Thanks for soliciting our opinions.

Basically, I dont see anything wrong with cf being java lite, but I definately dont want us to become "watered down java / RoR wannabes"

I guess I really wish Adobe would spend some effort really polishing and perfecting the subtle nuances of what they have before trying to throw in every feature just to keep up with other languages on paper.

mind you, nothing beats CFDUMP and notepad when you're desperatly debugging some suss value on a live server.. while the boss is tapping his fingers...

I pity those platforms that are totally locked into their IDE for debugging...

It's funny that there has been so much fuss about RoR. The more I look into it, the less I like Rails, but I've got to say that Ruby is a real hackers language and now I'd love to be able to see more metaprogramming "everything is an object" capabilities in CF.

I know it's an edge case as almost no CF'ers would use it, but just for the framework authors - imagine having the ability to create a system allowing developers to use XML to easily create their own abstract data types tying into a rich validation/transformation handlers and scaffolding that would be strong enough to hold up proper enterprise applications . . . I'm working on doing something like this in CF, but it's syntactically a little crude!

Just thought I'd throw in something a little different - I couldn't honestly justify this as a good use of Adobe's development budget. Although on another note, for us fans, finishing what they started with cfscript would be nice . . .

Best Wishes, Peter

I bloody well hope CF8 is the ducks nutz.

and more: - function to "read" current settings and stack (is showdebugoutput set to yes or no? is transaction active or not? ...) - a tag or two to make cf-template programming easier than today where i have to write #chr(60)#cfif ...>...#chr(60)#/cfif> - more settings dependend on CFAPPLICATION not cf-admin (mappings...) - debug tags (dump, abort...) bound to an user/ip so website visitors are not affected by debugging - debugging with breakpoints... (reactor) - better cluster handling in cf-admin and cluster-communication tags

Better editions for hosting providers (so that every host that has CF doesnt have to fudge it, such as sharing DSN's etc)

A Remote Console to manage CF servers would also be awesome (ok ok, I know cfide/administrator does the job beautifully)

I am coming round to Sean;s way of thinking, the only thing that has bit me recently is the handling of null;s from Java, and coldfusion thinking that the variable is now undefined because its a null (its a null, not undefined!)

MD

1) CFChart/CFDocument - I just installed CF7 and was all excited about charting and CFDocument til I learned you can't print CFChart. &$%^@*&.

2) Verity - I really like the Verity spider but I struggled for two days to get it to work (again) with CF7. Seems like this could be made easier somehow...

3) Reporting - the Fusion Authority Quarterly Update has a nice article in it where someone picks apart and points out all the flaws in the Report Builder.

4) Scheduling - this could be improved in many ways

5) Server Tools - migrating non-enterprise CF Server is a huge pain. How about building in some kind of simple - 'export settings' tool?

6) Adobe should buy Fusion Reactor and bake it in.

7) Adobe should look at Blue Dragon features missing in CFMX - competition is good!

Jim

While I believe the server admin/monitoring is important, perhaps those elements should be able to operate in standalone fashion ...and communicate with a cluster rather than being part of one. Similar model to Weblogic's admin console.

Ok, maybe I only get one vote, but if so, my ONLY vote is for better debugging. Common CF developers, you guys get fancy debugging while you're building CF, spread some love our direction! :)

I guess I should be specific, so people don't think I mean expanding the cfdump tag. I'd like to see all the stuff that Integral's upcoming FusionDebug will do. That should be supported in an API or something, so that all of the IDE developers can hook into it and provide /real/ debugging to their users.

Just a random thought that passed me by. Anyway, in case you don't already know...I'm for interfaces, static methods, and a real constructor.

Something that also made me think was optional strong typing. I think it would be a really good way to beef up performance by allowing for more compile time type checks (pretty much removes the "don't type for performances sake!" duck typing argument) and offer flexibility for all types of CF programmers. ActionScript implements this beautifully and makes it very desirable in my opinion. When you want it, it is there, otherwise you can pretty much ignore its existence if you choose. I like the idea of making CF "the best of both worlds" in cases like these.

MD

2) ECMA syntax for cfscript

..and...

3) ECMA syntax for cfscript. :)

I would like to see how much memory the cfm page I wrote is consuming right away. Maybe before starting out the page give your server stats like total memory etc., and then a simple button on your dreamweaver which calculates the total amount of memory the page will consume and individual memory the cftags in the cfm page consumes.

vishy

And better debug reports - creating a template to mail back errors generated on clients' servers was not trivial because some error messages couldn't really be contained within cfmail tags. I can't remember the whole details since I'm no longer at that company and don't have access to the codebase, but I was tearing my hair out over this.

thingsWeDontNeed = ['interfaces', 'null', 'constructors'];

me = [first: 'Patrick', last: 'McElhaney', age: 28];

people = [[first: 'Sean', last: 'Corfield'], [first: 'Brian', last: 'Kotek'], me];

I find myself reaching for this type of construct all the time when I'm writing CF code. It would be invaluable in unit testing.

I would like native support for JSON.

I don't think drawing conclusions from Doug's decision to sell Alagad is very productive. It's just a little intrusive and unfair to put words in Doug's mouth like that... sorry, but it just kind of felt wrong when I read that.

@topic:

There are a few UI/presentation fixes I'd like to see, like paragraphFormat() generating compliant HTML and stuff, but beyond that, I think it's a waste of time for me and most of what I do.

Enhancing the OO tools also seems like a lot of work for little reward.

I'd like to see things like getMetaData() fixed so that it returns better, more helpful information on a webservice instance, for example. I'd like to see xmlSearch() fixed so that it can return things like the xmlText of an element. I'd like to see an alternative to DOM XML handling. I'd like to see the ability to create a handle on a file and read it line-by-line instead of having to read a 15MB text file into memory.

Basically I'd like to see some of the things that CF already does enhanced, improved, repaired, and updated.

I would like to see fileRead(pathToFile[,startPos,endPos]), fileWrite(pathToFile,content), fileDelete(pathToFile,failNotice,failureContainer), etc. I think than having to write cffile and cfdirectory tags for something as straightforward as reading, deleting, or updating a file is a bit of overkill... and I'm not talking about cfscript, I'm talking about companions to fileExists() and directoryExists().

Heh, OK, I'm going to have to write my own blog post on this because I could go on for far too long here in a comment.

Laterz...

Exactly!!!!!

Jim

cfquery name="..." cfhttp result="..." cfsavecontent variable="..." (and there's probably more)

Sometimes you pass in a query name, sometimes it's the query value.

Why is the "var" attribute of cfdump abbreviated when the word "variable" is not abbreviated in other uses?

And speaking of var, what's with this syntax:

cfset var name="value"

That's completely inconsistent syntax from everything else. I constantly catch my coworkers trying to do things like:

cfset var.name="value"

I don't blame them. If var is a scope, make it like every other darned scope!

cfreturn variable

Who came up with that? Wouldn't you think it'd be more consistent as

cfreturn variable="#variable#" ?

The language itself is starting to look like a web application built by 10 people each with their own coding style (yeah, you know exactly what I mean!)

I could go on and on and on... and I realize this is all little stuff, but it all adds up and can potentially start making the language a bit confusing and hard to remember especially for beginners.

I realize that once syntax decisions are made, it's difficult to change due to backward compatibility and people that are already accustomed to the current syntax. But the longer you wait (or if never), eventually things like that will continue to build and you'll end up with a language that just doesn't make sense. It's like that web application that was built 5 years ago, and over time is in badly need of a good ol' code scrub...which never happens because it works and you have other priorities. Another 5 years pass and it's gotten so bad that no one wants to touch it and scrubbing it now would be a daunting task compared to if you had done it a long time ago.

However, if both Flex and actionscript are making syntax changes (for the better), then why can't ColdFusion???

After playing with Flex2.0, I've really grown to like the flexibility (pun intended) of the pure xml syntax. To me,

cf:set name="#varname#" value="varvalue"/

is sooo much more consistent with today's standards, especially when compared to the ugliness of

cfset "#varname#"="varvalue"

Why make an ugly hack like that to a language rather then making slight syntax changes to begin with. Again, it just keeps building up.

If you needed to create a multiline variable...

cf:set name="varname" cf:value value line 1 value line 2 value line 3 /cf:value /cf:set

When you're staring at code all day, I sometimes think it'd be such a relief to work with nice clean consistent code

I agree with most of what you're saying. When people ask me what I'd like to see changed, a lot of the little points you bring up come to mind. Personally, one that gets me constantly (and that should be easy to implement) is the difference between "named" and value attributes.

For example, why is it:

<cfloop collection="#foo#">

But:

<cfoutput query="foo">

I can't begin to count the number of times I've typed:

<cfoutput query="#foo#">.

While I'd also like to see some inconsistencies cleared up, I think breaking backwards compatibility would only be an option if it was possible to write a 100% automatic conversion program and even the the FUD that would be caused could be very damaging to CF. Plenty of decent products have hit "the begininning of the end" by releasing a version that wasn't backwards compatible.

Also, while I understand the idea of <cfset name="var" value="val">, while CF is a tag based language, that kind of change would make life extremely difficult for people trying to do more complex programming in it. Adobe would really have to go the whole hog and provide two complete sets of syntax - a (hopefully ECMA compliant) cfscript and a set of tags for the two different use cases.

Best Wishes, Peter

Speaking of FUD, I have to grudgingly agree with Peter. Not that I like to disagree with Peter, but backwards compatibility has to be considered more important, I think. As far as Devin's complaints, I think compatibility can be obtained, if they were to introduce a 'variable' attribute to all the tags that name it differently, but keep the 'name' and 'var' for legacy apps. 2 or 3 versions down the road they can remove the legacy syntax. But I'm not sure how you'd fix the "hash or don't hash" problem without breaking legacy code.

And maybe it's just me, but I've never quite understood the reasoning behind the idea that backward compatibility being more important then language improvements. I'm not saying that I think backward compatibility is unimportant. But if you have a legacy application running in CFx, and you don't want to spend the time to update the application for CFx+1 (or the client isn't willing to pay for it, or whatever the reason may be), it's not like you HAVE to upgrade the application server! Okay, okay, so maybe you have no choice if you're on a shared account in which the host provider is upgrading the server. In any case, why would you want to upgrade an application server software if you're not willing to upgrade your application to take full advantage of the new server software? If you're purpose it so implement a some new features, I'd just assume tidy up some code while I'm at it anyway.

<cfloop query="#foo#"> breaks in current versions of CF. All they have to do is check whether the value is a string (the name of a query) or a query (the query itself).

I would love to see that improvement, because then I could write code like this.

<cfloop query="#fooGateway.getAll()#"/>

I completely disagree regarding backward compatibility. Maybe if you only have one or two small apps, it isn't an issue. However, for Enterprises that have chosen to standardize on ColdFusion, it's just not feasible to have to rewrite, port, etc. an entire portfolio worth of applications because of backward compatibility issues. Minor changes are one thing. What's being proposed here is something else entirely.

I can also tell you that not upgrading the application server is not an option. Eventually, vendors stop supporting older versions of application servers. Most companies pay maintenance so that they can keep their infrastructure current, from both a support and security standpoint. It isn't always about immediately implementing the latest and greatest features. In larger companies, upgrading to a new version of an application server is usually not trivial. There's a lot of planning, testing, and documentation that goes into an otherwise "simple" server upgrade.

While I wouldn't mind seeing some of the language inconsistencies fixed, I just can't see that as a good thing if it doesn't handle backward compatibility.

Our organization would fall into that group. What about supporting both original *and* new conventions? Just mark the old as deprecated and move on?

Please enhance the scheduler! fault-tolerant, cluster-aware, local invocation (CFC call vs HTTP Post), extensibility i.e. DB storage as opposed to XML

FIX THE DEBUGGING WE'VE GOT! So that the execution times are accurate! So that just having it on doesn't make the execution time an order of magnitude or so greater!

Some of the optimization projects I worked on in CF5 just wouldn't have happened if I'd been trying to do them in CFMX.

www.techfeed.net/blog/index.cfm/2006/3/28/PHP-Debugging-is-Better-Than-ColdFusion

www.techfeed.net/blog/index.cfm/2006/3/24/ColdFusion-Debugging-Can-Be-Painful

I'm fine with deprecating constructs, as that's the mechanism that CF's always used in the past.

I know this is not applicable to all, but it would be great to jar up applications like that.

why cant it just be <cfqueryparam type="numeric" value="something"> ?

MD

cfloop query="recordset" group="group" ?

Having to use cfoutput gives me the runs. Second on the calls for cfscript completion and scheduler updates.

thanks nick

As an aside, it would be nice to be able to define "types" of cf pages to make frameworks more bullet proof; in a way I think this is sandboxing parts of an application saying you cant use cfqueries in your cfm page, they should only be in cfcs etc etc - now I've made myself think damn it...hmmm

I remember doing a design where I moved the CFIDE in CF 6 for security reasons (which broke a few bits of the CFAdmin) and had to tell people about the "unknown" attribute scriptSrc in cfform only to find in verion 7 this has now been added to the CFAdmin - which still breaks the CFAdmin :)

my preference is to have better control over external tasks such as cfhttp and cfinvoke. though the fusion reactor would be sweet. I mean what is the point of allowing a stored proc to run for 60 seconds only to return control to the cfm page which is allowed to run for 20 seconds and tell it to get lost (even though processing has completed correctly) - it would be just better to say "ok, if you are a cfstoredproc etc etc and you ran for a while, I can't actually kill you, so I'll let you run and will not add it up to the time spent running"

Additionally I would like to be able to create new cf servers on JRun where it /kept/ the /all/ the settings I just bloody made with my XML (vi) editor including the metrics - these 2 points are also mentioned by b harper. The installation is pretty weak where you have an "out of the box" install and then have to lock it down for ages, really it should practically "not work" when you install it due to security reasons.

Additionally allowing the cfadmin to have no password in a production environment is a weakness.

Proper whitespace mgmt?

Case sensitive variables?

Enforce scoping of variables (cfadmin option)

that is all for now :)