An Architect's View

49 responses so far ↓

• 1 since1968 // Jul 24, 2006 at 5:50 PM

  CF already rocks. I don't find myself wishing for too many language-specific features. What I would like to see (following up on the RoR thread) is Adobe embrace an official/semi-official framework, testing methodology, etc. I'd like to see Ben Forta write a version of CFWACK that introduces MVC from the beginning.
  
  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.

• 2 since1968 // Jul 24, 2006 at 5:52 PM

  P.S. I know this isn't specific to CF, but I'd like to see continued, enthusiastic support for Flash Remoting built into CF. Remoting is so much faster than XML.
  
  Thanks for soliciting our opinions.

• 3 ntunney // Jul 24, 2006 at 6:03 PM

  While I can agree with some of Brian's statement, I feel that adding some additional OO functionality is a great thing. I don't think the server team's core focus should be on OOP, however, some of the features Simon has listed would be most helpful. Saying that we shouldn't add some java-type functionality to CF because of some people's usage of CF (I look at "Senior" CF developer's resumes all the time that just frustrate me and make me chuckle) it is kind of like not adopting CSS in HTML pages because people are comfortable in the way they have been doing layout all these years. It just doesn't make sense.

• 4 Stacy Young // Jul 24, 2006 at 6:18 PM

  Please make the scheduler extensible! It's currently the weakest link in the chain. Optional database storage would be great!

• 5 Ryan Guill // Jul 24, 2006 at 6:25 PM

  I intend to comment further on Brians post when I get time, and although I don't completely agree with simon's list, I dont see exactly what is wrong with cf being a "java lite". I see one of cf's greatest strengths is that it is as powerful as java in an easy to use RAD package. As RAD as rails on most levels, and yet still has the ability to handle the most complicated tasks as well. While I agree that we dont necessarily *need* a lot of those java-esque features, they would make a great addition to the language. Sure, we can all drop into java when we need something more powerful, but cf can abstract some of that out and make it much much easier and faster to develop in, and expose it easier to a much wider audience through web services, flash/flex remoting etc.
  
  Basically, I dont see anything wrong with cf being java lite, but I definately dont want us to become "watered down java / RoR wannabes"

• 6 altImage // Jul 24, 2006 at 6:55 PM

  I'd also like to see more/better admin tools. Fusion Reactor has some really nice stuff we could all benefit from. I'd also like to see some long standing holes addressed. Image manipulation keeps coming up. Also some attention to some of the small details that consistently cause me pain...like CFs behavior toward empty list elements. More functionality in QofQ's. Ability to sort and order structs better. One big one thats keeping me from using Flash forms is the ability to dynamically expand the canvas size...I hate scrolling forms.
  
  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.

• 7 barry.b // Jul 24, 2006 at 6:58 PM

  how's the breakpoints and watches "hooks" going?
  
  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...

• 8 Peter Bell // Jul 24, 2006 at 8:09 PM

  Well, I find myself voting against both presentation (cool and I'd like deeper flex integration, but it never seems to quite work the way you want it) or OO (I'm a one man team, so I can live with conventions and a little bit of duck typing instead of interfaces and nulls). I guess I'd be the lone voice asking for deeper metaprogramming capabilities?!
  
  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

• 9 Terrence Ryan // Jul 24, 2006 at 9:09 PM

  Cfrss and cfatom. Granted it is pretty easy to roll your own syndication feed creator, and it's just a little more challenging to consume it with CFXML. But seeing as how everyone either has, or will have to do this it seems like low hanging fruit.

• 10 Gary Funk // Jul 24, 2006 at 9:41 PM

  I was just making the rounds on the blogs I read when I read Mike Kelp over at EdomBlog. He has posted "ColdFusion Wishlists and a General Understanding" and has a rather long post on the subject. I must say the opinions he has expressed have me thinking. To me ColdFusion has become such a valuable tool that I often use it to do simple jobs on my desktop. The CF community is more than just a collection of programmers, architects, instructors and evangelists; we have become a very large, though distributed, clan and at any given moment,with apologies to Sean Corefield, Ray Camden and Ben Forta, each of us becomes a programmer, architect, instructor and evangelist. We are quick to offer our ideals and proud to share our code. Whatever version 8 brings us, I think it's a safe bet Adobe has spent the time, asked the questions and done the homework. I, for one, am very excited to see what Adobe will do.

• 11 bah- humbug! // Jul 24, 2006 at 10:08 PM

  Gary, that's not very comforting when one's org is in the process (as we speak) of phasing out CF completly - and one has tried every angle of persuasion to reverse the decision. To be honest, CF7 wasn't *that* much of a quantum leap (iText replaced limited CFDocument, Lucerne for a slow Verity, we never could use flashforms with any meaning).
  
  I bloody well hope CF8 is the ducks nutz.

• 12 Michael // Jul 25, 2006 at 1:19 AM

  polishing and perfecting existing tags and functions, like
  - handling empty elements in lists
  - function attribute to push processing in background (thread)
  - key/value pairs to set struct immediatly: structNew(key=value, key2=value2...)
  - cfschedule enhancements (get list and details...)
  - 3rd mid() argument optional
  - new CFARGUMENT attributes: CALLBY="reference|value", list="Yes|No" and "max, min, pattern" from CFPARAM
  
  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
  

• 13 Mark Drew // Jul 25, 2006 at 1:37 AM

  Not sure if anyone has mentioned this.. but how about in-built image manipulations? <cfimage> anyone? I know there is Alagad and a host of others, including dropping into java and doing it but c'mon, nearly every project I have done needed some image manipulation functions.
  
  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

• 14 Roger Lancefield // Jul 25, 2006 at 1:57 AM

  My guess is that Doug Hughes' decision to sell Alagad is an indication that he at least believes that the next version of CF will contain some serious image manipulation ability...

• 15 Jim // Jul 25, 2006 at 6:26 AM

  I still wish Adobe would go back and fix/improve some things before adding new features:
  
  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
  

• 16 Stacy Young // Jul 25, 2006 at 6:40 AM

  CF should be more modular. Unused features should not be included in the final bits when building a war. I'm worried this will get worse over time and have us deploying a tiny CF war that's 100mb in size!
  
  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.

• 17 Jacob Munson // Jul 25, 2006 at 7:02 AM

  +1, +2, +3, +4, +5 for better debugging!
  
  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.

• 18 Mike Kelp // Jul 25, 2006 at 7:15 AM

  In terms of Imaging stuff, one hell of an integration opportunity I see for Adobe would be to give CF server the capability to use Photoshop Droplets to manipulate images. While this would only be ideal if you didn't have to install Photoshop on the server, it would give us some solid, blazing fast image manipulation even if it did a subset of Photoshops true capabilities with them.
  
  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.

• 19 Mark Drew // Jul 25, 2006 at 7:22 AM

  Another thing I would like to see is per Application Mappings. A way to dynamically create mappings per application with a <cfmapping> or something like that added to an application.
  
  MD

• 20 Erik Yowell // Jul 25, 2006 at 8:21 AM

  1) ECMA syntax for cfscript
  
  2) ECMA syntax for cfscript
  
  ..and...
  
  3) ECMA syntax for cfscript. :)

• 21 vishy // Jul 25, 2006 at 8:44 AM

  Sean,
  
  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

• 22 Lola Lee Beno // Jul 25, 2006 at 9:41 AM

  Better debugging. It'd be nice to be able to step through a web application, especially to track down that elusive bug that occurs only in certain circumstances.
  
  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.

• 23 rk // Jul 25, 2006 at 10:21 AM

  How about improving LiveDocs a little? More examples would be great -- a simple one, a less-simple one, and a OO example for every tag and function should be the goal.
  

• 24 PaulH // Jul 25, 2006 at 10:24 AM

  same old, same old.
  - native resource bundles
  - built-in icu4j (and make it updatable)
  - setTimeZone() method

• 25 Patrick McElhaney // Jul 25, 2006 at 10:24 AM

  I'd like to be able to define create and populate complex types inline, e.g.:
  
  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.

• 26 Patrick McElhaney // Jul 25, 2006 at 10:31 AM

  I'm sorry. I just realized my last request was not buzzword-compliant. Let me rephrase:
  
  I would like native support for JSON.

• 27 Arindam Biswas // Jul 25, 2006 at 11:13 AM

  Bundle a copy of Flex Builder with CF at the same price! ;-)

• 28 Jared Rypka-Hauer // Jul 25, 2006 at 12:24 PM

  @Roger Lancefield:
  
  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...

• 29 Arindam Biswas // Jul 25, 2006 at 12:39 PM

  Bundle a copy of Flex Builder with CF at the same price! ;-)

• 30 Jim // Jul 25, 2006 at 2:10 PM

  Jared said "Basically I'd like to see some of the things that CF already does enhanced, improved, repaired, and updated."
  
  Exactly!!!!!
  
  Jim

• 31 Roger Lancefield // Jul 25, 2006 at 4:01 PM

  Jared, yes, I agree, having re-read my comment I think it would have been better if my speculation had been more abstract without directly implying what Doug Hughes himself may or may not know about Adobe's plans.

• 32 Devin // Jul 25, 2006 at 11:11 PM

  I haven't really seen anyone talk about this, which leaves me to believe that I'm probably one of the few that have strong feelings about it. In any case, I'd like to see some syntax inconsistencies improved. How many different attributes exist for naming a variable?
  
  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

• 33 Joe Rinehart // Jul 26, 2006 at 4:27 AM

  Devin,
  
  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#">.
  
  

• 34 Peter Bell // Jul 26, 2006 at 5:44 AM

  Hi Devin,
  
  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

• 35 Jacob Munson // Jul 26, 2006 at 6:48 AM

  Joe beat me to it! I was going to point out what he did (in response to Devin), but I'll expand a bit to say that I am always unsure when I'm supposed to put hashes around a variable when it's used in a quoted argument. I think generally you do have to use the hashes, but there are those odd cases (like Joe pointed out) that cause FUD in my mind. :)
  
  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.

• 36 Devin // Jul 26, 2006 at 8:50 AM

  I completely agree with the <cfoutput query="#foo#"> thing. That's what I meant about sometimes passing in a variable name while other times passing in a variable value.
  
  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.

• 37 Patrick McElhaney // Jul 26, 2006 at 8:53 AM

  "But I'm not sure how you'd fix the "hash or don't hash" problem without breaking legacy code."
  
  <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()#"/>
  
  

• 38 Rob Brooks-Bilson // Jul 26, 2006 at 9:02 AM

  Devin,
  
  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.
  
  

• 39 Stacy Young // Jul 26, 2006 at 9:08 AM

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

• 40 Stacy Young // Jul 26, 2006 at 9:12 AM

  In case my comments on the scheduler fall through the cracks. ;-) Just let me re-iterate here:
  
  Please enhance the scheduler! fault-tolerant, cluster-aware, local invocation (CFC call vs HTTP Post), extensibility i.e. DB storage as opposed to XML

• 41 Jim Flannery // Jul 26, 2006 at 1:55 PM

  I can't believe nobody's said this, with all the talk about adding debugging functions:
  
  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.

• 42 bah- humbug! // Jul 26, 2006 at 3:15 PM

  and while we're talking about debugging
  
  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

• 43 Rob Brooks-Bilson // Jul 26, 2006 at 4:57 PM

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

• 44 Mark Drew // Jul 27, 2006 at 1:13 AM

  Another feature I would love is the ability to create JAR files of CFC's so these applications can be deployed to a server with a consistent path as defined by the structure inside the jar file.
  
  I know this is not applicable to all, but it would be great to jar up applications like that.
  
  

• 45 Mark Drew // Jul 27, 2006 at 4:03 AM

  Also another thing about the syntax of cfquery... which is cfqueryparam.. whats with the cf_sql_<type> ?
  
  why cant it just be <cfqueryparam type="numeric" value="something"> ?
  
  
  MD

• 46 nick williams // Jul 30, 2006 at 7:50 PM

  how about:
  
  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

• 47 Andy Powell // Aug 22, 2006 at 7:47 PM

  How about the ability to deep copy (duplicate()) a CFC? That's all I want.

• 48 bah // Sep 15, 2006 at 3:18 AM

  just reading this now; but regarding all the backwards compatability stuff; how hard would it be for there to be an option (through CFAdmin or otherwise) to something like "Option Explicit" in old skool ASP, where you are saying your application is full sick with the current version does not need to be backward compatible.
  
  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 :)

• 49 bah // Sep 15, 2006 at 3:32 AM

  just thought of another one relating to the frameworks and sandboxing; would be nice to be able to say "no cfc" allowed in a particular directory and vice versa.

Leave a Comment