YOUR IDEAS FOR THE FUTURE OF CFML -ADOBE MAX B.O.F. SESSION

I’ve been asked to host a birds of a feather (BOF) meeting at MAX on CFML Language Development.

The session will cover topics related to the future evolution of the CFML language itself (ColdFusion Markup Language).  UPDATE: The session will be on Monday night, at 9.30 pm in room 2008.

I’d like the the session to address the needs of

  • the CFML Community -including CF developers, Blue Dragon users and Railo users;
  • developers who are thinking about using ColdFusion and;
  • CIO’s, CTO’s and entrepreneurs who are researching development platforms.

To that end, I’m looking for input on:

  1. Specific topics you’d like discussed
  2. Concerns on the future of CFML
  3. Wish list for CFML’s direction and
  4. Specific speakers you’d like to hear from at the meeting.

Post your feedback here or email me at mark@vertabase.com

Even if you can’t make to MAX, send me your ideas. I’ll be posting the session online afterwards.

Category: ColdFusion, AIR and Adobe

Tagged:

27 Responses to “YOUR IDEAS FOR THE FUTURE OF CFML -ADOBE MAX B.O.F. SESSION”

  1. How about renaming the language, to help avoid the snobbery/misunderstanding about people thinking CFML is actually a markup language?

    Only immediate thought would be “ColdFusion Mega Language”, but there must be a multitude of M-words to mull over?

  2. Jeff Gladnick Says:

    It would be nice if there was some sort of transparency or even news coming from the CFML advisory board. I haven’t heard much from it (perhaps I don’t know where to look) since it was formed. It would be nice if there was a monthly update, and an agenda for the next meeting with requests for comments from the CFML community, especially on the area of new tags, functions, attributes, etc.

    Especially in light of the fact that some of the alternative CFML engines are starting to add impressive new features that will likely get picked up by the Adobe CF standard. Railo especially with their CFVIDEO tags is one example, and it would be nice if adobe chose the same tags/functions for it. I am hoping that Railo/Adobe corresponded when Railo chose their tag names/attributes, and I hope that goes both ways.

  3. admin Says:

    Here are a few comments from the CF Talk board on House of Fusion:

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
    Subject: CFML Language Development
    From: Don L
    Date: Mon, 27 Oct 2008 11:38:18 -0400 (EDT)
    Thread: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:57914#314398

    —– Excess quoted text cut - see Original Post for more —–
    Here’s something that pops out of my head upon reading your post. Years ago where’s ColdFusion Express (free)… naturally functionally not in par with commercial version… But I thought if one (independent developers / cf shops etc.) uses such a free platform and negotiate a price for additional tag/features (say, like today’s CFPDF, CFIMAGE etc.) with CF company like Adobe, then, it really creates win-win situation for all. Adobe can sell heavy-duty CF package to the big spenders as it does now while it does not alietnate the ‘little guys’ (an integral part of the CF development community) and provides considerable value to them. This approach/model would seem to generate more revenue for CF company/companies but no I haven’t run some detailed number crunch…

    Thanks.

    Chunshen Li (Don)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
    Subject: CFML Language Development
    From: s. isaac dealey
    Date: Mon, 27 Oct 2008 12:44:42 -0400
    Thread: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:57914#314399

    —– Excess quoted text cut - see Original Post for more —–
    Given the recent roadmap that Adobe published for CF in their marketing
    kit, I suspect they may be planning to separate some of the features in
    a few years when version 11 or so is released. I.e. you would buy CF but
    then you wouldn’t be paying for PDF generation unless you’re using it,
    because the PDF features would be in a supplemental product… and it
    would make similar or alternative products from other vendors more
    feasible. At this point it’s all guesswork though because they’re not
    really allowed to say more about their plans, just that they’re planning
    to provide a “pluggable architecture” in that version.


    s. isaac dealey ^ new epoch
    isn’t it time for a change?
    ph: 781.769.0723

    http://onTap.riaforge.org/blog

  4. Gerald Guido Says:

    I think that one of my biggest frustrations is a lack of info and a road map on features and compatibility.

    The other is a lack of a cross run time ORM. That is huge in my book.

    Another is to see the FOSS CF apps on RIAforge run on compatible versions of the different run times. What works out of the box on Adobe CF should work on the other run times with out modification as long as the tags and functions are supported.

  5. Gert Franz Says:

    Hi all,

    speaking of the pluggable architecture. Railo 3.1 will introduce exactly that. If you maybe have read my blog post about the Railo extension manager you know, that Railo’s basic feature set will be free and extendable with the extension manager which allows you to add features (payable or free) you need or not. Even applications can easily be installed like that. Just have a look:
    http://www.railo.ch/blog/index.cfm/2008/9/3/Extension-Manager
    Of course we would like to see the general development in this direction. It would be cool if Adobe would introduce something new (for Railo) like CFEXCHANGE and offer it over our extension manager for a certain amount. For us the requirements of the community are most important. So we would definitely like to have your wishes and suggestions. And I’ll try to push them through in the Advisory Committee :-)


    Greetings from Switzerland
    Gert Franz
    Railo Technologies GmbH
    gert.franz@railo.ch
    http://www.railo.ch

    Join our Mailing List
    english: http://groups.yahoo.com/group/railo_talk/
    linked in: http://www.linkedin.com/e/gis/71368/0CF7D323BBC1

  6. admin Says:

    More Comments from the CF Talk Board on House of Fusion.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Subject: CFML Language Development
    From: Don L
    Date: Mon, 27 Oct 2008 19:21:20 -0400 (EDT)
    Thread: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:57914#314414

    Thanks for sharing what is sharable.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Subject: CFML Language Development
    From: Adam Haskell
    Date: Tue, 28 Oct 2008 00:13:16 -0400
    Thread: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:57914#314422

    Not the first time this has come up:
    http://cfrant.blogspot.com/2008/04/why-adobe-should-love-open-bluedragon.html

    Gert, of Railo, also mentions a similar view in episode 10 of
    cfConversations (please forgive the crappy quality):
    http://www.cfconversations.com/index.cfm/2008/7/28/CFConversations-10-Interview-6–Gert-Franz-of-Railo–072808

    And lets be honest here it is already a plugable architecture, just do a
    CFdump on most (probably any) tag class and you will see they all extend off
    JSP tag. The only engine that does not do this currently is OpenBD but as my
    blog post above speaks to, OpenBD has a plugable architecture as well, just
    does not base it strictly off JSP.

    Adam Haskell

  7. David McGraw Says:

    I can say Gimicky tags will not prgress the language or grow the community.
    Language Features will. Something like a CFVIDEO, sounds cool, but won’t grow the language, and things like that are best left to add-on components and such.

    From the beginning of CFCHART, Cf developers have thrived off being able to walk a boss in and in less than a minute show them a chart based on some data. The charting and PDF creation is always a quick welcome WOW factor when showing off CF. however, CFCHART has fallen behind in terms of usefulness. It make a solid 1 axis chart, but it’s time to add to it…
    CFCHART needs to support multiple Y axis so you can compare to indicators of variable values on the same chart.

    The Prize feature would be form generation, validation, and manipulation.
    We all know that 95% of our jobs are dealing with creating a form, ensuring it’s validated correctly, and then save it to the DB. If there was genius way to simply define a form, the placement of the fields, required or not, and then it accepts and saves the data it would be wonderful. And no CFFORM is not a substitute, I still never use it, and although it has perhaps gotten better, its not flexible enough.

    95% of all business web development is form manipulation.

    For my own personal stuff, I created a function that allows me to write an XML document which defines the form, the defaults, the Labels, the placement, options, the TableName the field coresponds with, everything…
    and then I have code that reads that in, verifies all the fields exists, if not it adds them to the table, and then knows which fields are required, along with what message to display if they are not filled out, it also have built in date pickers for fields of date types, as well as rich text editors with a textarea flag.

    The key to this, is if my entire app is built using this definition file instead of CFML code, when there is a chance to a form, I modify the definition file, and everywhere in my app that displays the information, collects it, or reports on it, automatically picks up the new or altered fields and displays/builds the form appropriately. Granted this will not work with extremely complicated forms, or multi page / multi relational DB layouts, but atleast 50% of all forms contain simple logic, and simple validation… If somehow there could be a tag, that can slurp up a file that defines the form, and with an attribute tell it to display a list ( using a template display file ) or display edit form, and allow you to simply modify your one file that defined the form… it would be GREAT!

    Form work is tedious, and annoying, and BORING… If we have a ROCK solid flexible way to cut out all the basic forms code with out having to cut and paste code, or manage to search for all locations the form based info is displayed… it would be a killer app.

    Focus on HIGH productivity solutions for CFML. The next 10 years will be defined by how fast you can get it to market… WE already know CF rocks when it comes to speed… Let’s make it faster to bust out forms, reports, charts, and then wrap them all up into PDFs.

    Oh and Also, A Tag that allows you to create, manage, calculate, update a
    spreadsheet object would rock too. Not just like google docs, but kinda
    of… I want to be able to manage and create spreadsheets in memory, easily turn them into proper documents, and also display a web friendly editor page where users can update certain values, have all attached values update, and then lock some cells from being editable.

  8. Gert Franz Says:

    David,

    I am absolutely with you. I really hate it to create out all these forms and deal with the storing etc. For the storing of a CFC, Hibernate that we will soon integrate will be perhaps a viable option. Nevertheless I would appreciate a form or form code generator or something similar in the language. If you like it to be part of Railo, just contact me at gert.franz(at)railo.ch. We could then think of a way of how to do it.
    Maybe you can write an extension even yourself. The extension manager can help you use those things very easily.

    Gert
    Railo Technologies

  9. David McGraw Says:

    Gert, I sent you an email, further explaining my idea on the Form thing, I think to truly do it right, is too much work…

    But I sent you an email, and if you’re interested in further discussing the idea, let me know.

  10. >> I think to truly do it right, is too much work…

    That’s an excuse for laziness.

    Anything that /seems/ like too much work can always be broken up into smaller chunks.

    With regards to forms… again, I don’t think having something that works with complex/relational forms is out of reach - it’s just a case of starting with the right building blocks and working up from there.
    None of it is difficult, it’s just a matter of time.

    On the cfspreadsheet idea - I think that’s a great suggestion!
    CFML has basic csv->query support, but having that more explicit and part of a greater Spreadsheet functionality that also supports formulas/calculations, integrates with cfchart, and so on - that would be really nice. :)

  11. David McGraw Says:

    Anything that /seems/ like too much work can always be broken up into smaller chunks.

    I know, and what I mean by my comments is more based on my dislike for implementing solutions that do not cover everything… Basically, if you build a dynamic form generation solution that only services 80% of your needs, then your stuck implementing 2 solutions, and maintaining 2 sets of code for your one application, which I hate doing…

    It’s the reason why I have never used CFFORM, because it always leaves me not supporting everything I need it to do and I don’t want to train/maintain multiple ways to handle forms in one application.

    I think your right, if given the time and thought of how to do it, a solution could be developed rather well. The biggest hurdle for me is the designing of a form, as far a straight top down forms, I have already dynamically solved all the Backend problems, but designing a form that doesn’t just list each form field one after another would require a UI to drag and drop the form fields like a Visual Studio VB editor, in which the app saves the left and top pixel locations to be used on output of the form… could be done, just would take a lot of time, of which I do not have…

    I would love to work with a group or someone on a “XFL” or “Extensible Form Language” which is an editor helps the developer / power user to create a form which is nothing more than a descriptive XFL document and then a custom tag uses that to render the DB objects, and the CFC methods to manage the data, and the scripts to generate the actually form.

    And yes, a in memory CFSPREADSHEET would rock, but it would have to auto generate a editable excel sheet on the web with customizable look and feel with styles and such… I could see it being a huge feature in Financial applications, imagine being able to create spreadsheet with formulas on the fly from a DB, complete with formulas, and then the user can save their own worksheet to be brought up later, or to be updated with current sales data, etc… Turning financial applications into more working tests and examples of data for users to plan and design strategies.

  12. Bryn Parrott Says:

    I agree with a lot of what David McGraw said.

    Do some more work on CFEclipse with some more wizards to make grind work on forms easier and quicker. (expecting a few flames) Surely it would be a good idea to ‘copy’ the concepts found in Visual Studio 2008 for Forms/Database sites and help productivity along. What is already there could be made more robust and flexible.

    Inbuilt and explicit support for common site layouts/design patterns such as MVC, Fusebox and even ColdSpring would be really great. Perhaps even some layout wizards.

    Something to be done towards setting up application level role based security (what is there is really for server level security).

    Spend some time and effort on the documentation for whatever is done, and dont leave it half done like Adobe usually do.

    Spending a bit of time making the extra bits and peices like cfdocument and cflayout that were added for CF8 really work properly would not go astray.

    It would be great if the cfforms flex implementation was brought up to date to actionscript 3.

    But please dont mess with the core language(s), its more stuff around the periphery (as above) that needs work.

    - Bryn -

  13. Gerald Guido Says:

    David McGraw Had some good points. While an ORM will be awesome it only addresses half of the issue with code generation. There a bunch of code generators out there and some create forms but (going from memory here) you have to manipulate the code in order to format the forms. It is not templated like Illudium. And Illudium does not lend itself (IMO) toward form generation (nor was I able to get it to work with Railo). So I ended up having to write a helper CFC in order to get it to create forms.

    Peter is right. It is not that hard, especially with CFDBinfo. But it does take time.

    David also hit the nail on the head with the focus on HIGH productivity. That is the one thing about CF that has had me coming back time after time after time.

    Code generation is the one thing that help Ruby On Rails take off. If we had some thing that we could point to a database and have it create a working CRUD (Like Squid Head) that was template-able like Illudium and worked cross CF runtime that would absolutely CRUSH.

  14. Henry Levin Says:

    Would be nice to be able to include raw Java code within a cfm or cfc. Perhaps a new tag, something like this: raw java code. Perhaps this is already in the next version, I may just be behind. createObject(’java’, ‘class’) seems very limited.

    I would actually like to see more investment into cfscript or whatever script and less use of the markup.

    And I second the post from Peter at the beginning. But I’d move away from the CFML as a brand completely and try to bring CF even closer with Java. How about CFJA for ColdFusion Java Abstraction or CFJW for ColdFusion Java Wrapper.

  15. Henry Levin Says:

    my tag example didn’t translate in my previous post, for raw java code i meant: <cfjscript>

  16. Gert Franz Says:

    Hi guys,

    some really neat ideas out there. While the will be something we will already include in Railo 3.2, the form and ORM stuff might be something that somebody could perfectly write as an application for the extension manager. I guess we will start an extension for that as a maybe open source application and go from there.

    Looking forward to the discussion.

    Gert

  17. Doh!

    “While the will be something we will already include in Railo 3.2″

    Gert, what’s the missing word?

    Mark: Can you fix the blog not to mindlessly strip out tags?

  18. Gert Franz Says:

    Sorry that was my mistake it’s <cfscript language=”java”>

    Gert

  19. @Peter -I’ll see what kind of options there are for not stripping out tags.

  20. Hi Peter, turns out we couldn’t find a way for Wordpress to publish the code.

  21. Howard Says:

    Feedback from the LinkedIn CF Group:

    On 11/4/08 8:33 PM, Howard Scholz wrote:
    ——————–
    I have always been disappointed by the lack of completeness of CFSCRIPT. I would like to be able to create an entire CFC with just script, no CFTAGs.
    The language is lacking:
    1) A clean syntax for cfcomponent that could be written in script.
    2) Likewise for functions that are not UDF’s.
    3) Implicit getters and setters, as has been done in the Railo implementation. If I address a property myProperty in component foo like var x = foo.myProperty and the component has a method named “getMyProperty”, then it should return the value of myProperty.
    4) OnMissingMethod should apply in this case as well. If there is no getMyProperty, but there is onMissingMethod or (new function) onMissingAccessor, then control should be passed to the onMissing handler.

    I could go on, but the basic premise is that the cfscript side of the language is lacking completeness, and leaves the developer with visually jarring code,made of script interrupted with tag language, and vice versa.

    Howard.

  22. admin Says:

    Further feedback from the LinkedIn CF Group:

    parameterexists() function should not be depreciated.

  23. Jason Presley Says:

    My main issue that I have been dealing with lately is the inability to format the labels in the CFChart tag. I have not been able to find anywhere that tells me how to format numbers or dates that display on the x or y axis as well as the “tooltip” type messages when you hover over a data series. The ability to format these would be greatly appriciated.

  24. Shane Heasley Says:

    Massive infusion of built in Flex and AJAX widgets. Including high end graphing. CFchart doesn’t cut it anymore.

    Real, non-buggy, .pdf generation.

    A built in, optional, framework?

    I don’t mind mixing script and tags, faster coding is more important than pretty coding, but working with highly abstracted components and Flex causes me to agree with Howard above.

  25. The last two comments were from members of the LinkedIn CF Group. Re-published with their permission.

  26. Just discovered this blog post because Mark Phillips posted the link in the Broadchoice Workspace (thanx Mark!)…

    The CFML Advisory Committee have been working on figuring out what we consider “core”, “extended” or “vendor extension” and we’re hoping to launch the committee website at MAX but documenting everything we’re trying to cover is very time-consuming and we’re all volunteers with full-time day jobs unfortunately…

    I’m sure several of the committee will be at this BOF tho’ so you can bug us in person :)

  27. The meeting happened. Thank you all for your feedback!

    Here is the first post from the meeting -late at night. Sorry for errors or omissions.

    http://www.vertabase.com/blog/first-draft-late-night-post-on-cfml-language-development-bof/

Leave a Reply

Follow me at: twitter LinkedIn

Get More Done



Hear Mark Speak

"Mark went out of his way to give a "real-world" talk on project management that was motivating and informational. Several of our group member filled up notebooks with great tips and takeaways from Mark's talk. I would highly recommend Mark for any discussion on Project Management and his talk is great for any audience."


- Matt Schulz, PMP, CIW

Archives

Subscribe to RSS Feed

Get the feed!


Add to Google



1999-2009 Standpipe Studios, L.L.C., All Rights Reserved.

Trademarks | Privacy | Sitemap