Discussions

News: Bitter Coldfusion experts on CFML vs. JSP

  1. A couple of bitter Coldfusion experts have written an article aimed at convincing Coldfusion developers not to give-in and switch to JSP. They discuss the benefits of CFML and issues with JSP, going so far as to suggest that "JSP 2.0 is an admission of failure of the original JSP spec -- and even that it's struggling to become more like CFML."

    Read Why Java Should Not Temper ColdFusionML Talents.

    I thought this part was also technically interesting:

    "With both CFMX Enterprise and BlueDragon Server JX, you can run JSPs and servlets alongside your CFML templates and can even natively integrate the two. You can share session and application variables between CFML templates and JSP/servlets, transfer control among them and "include" information among them, and more. "

    Threaded Messages (77)

  2. As an argument from a Pepsi representative about the disadvantages of Coke.

    ColdFusion might be the correct implementation for your application. Then again, it might not. All I can say is choose very carefully. Once you start down the road of Enterprise Application Development with a particular paradigm, it's very difficult to turn-that-puppy-around.

    Might it be that some people don't switch to J2EE out of pure laziness? I wouldn't know, I'm already doing J2EE. Just a thought.

    JC
  3. CFML black book[ Go to top ]

    How many CFMX developers use JDBC inside their cfm pages? How many books show you how to mix cfml code with java objects? And what about the java tools you need to build these apps? All this stuff is just not published and it is very much hidden but you can use java with CFMX in ways very few people know about. Java was the tool which built CF. cfusion.jar file has 99% of all the java class files which make up all the cf tags. Anyone can use java to create a CFopen project.
  4. Good thing they're sticking with cold fusion. I wouldn't want these experts working with me on a project. There's a lot of FUD about JSP thrown out in this article. To paraphrase, they say, "even if you decide to separate your application, which is a best practice, there are so many choices and things you have to do so why don't you not follow best practices and continue to shove everything into the page?" Please, that's ridiculous. The reason there are so many decisions to be made on a J2EE web app is because there are choices; you aren't locked into an architecture. In fact, something like CFML in the Java world would be just another markup language, like JSP or velocity or freemarker. It wouldn't dictate the entire architecture, which cold fusion does.

    I'm sure that CFML has advantages over JSP as a scripting language. That's what it was designed for. But that in no way changes the fact that CFML forces a design strategy on you that is difficult to maintain and scale. I may be wrong but my impression is that MVC, or even something like ASP.NET, is extremely difficult using CFML. The authors write "So more than just having to learn Java, they must become familiar with the process of segregating the application into layers. Again, CFML is evolving to support that notion, so it won't remain foreign for long." So CFML doesn't support separation now (it's "foreign") but as a dying standard (which is in such dire straits that it requires this article in its defense) it will at some point in the future? The authors have obviously been doing cold fusion apps for so long that they're not aware of other architectures, or they're scared of them. Let's face it, once you get into MVC and one of the many frameworks, they're not that difficult. I also like how the choice of possible frameworks and architectures is used here as a bad point: "There are so many how could you possibly choose one?" Sorry, but last I checked, choice was a good thing.

    Is it any wonder that Cold Fusion is dying? Am I missing something?
  5. Putting it into JSP pages FOR THE PURPOSE OF EXTRACTING DATA FROM AN IN-SESSION TRANSIENT DATA HOLDER is rather trivial. There is much power in them thar hills o' Java. Implementing tags, usually after usage patters dicate they are useful (at least in my case) is a great thing to do as well.

    Developers, do yourself a favor. Buy an OO book, learn about Polymorphism, inheritance, and patterns, and learn Java. If you don't you'll be left in the dust in the next 10 years.

    Cheers!

    John C. Dale
    Chief Architect
    Down in the Desert, Inc.
  6. Developers, do yourself a favor. Buy an OO book, learn about Polymorphism, inheritance, and patterns, and learn Java. If you don't you'll be left in the dust in the next 10 years.

    >
    While they are at it, better learn about Aspect-Oriented Programming as well.
  7. I'm not exactly thrilled with the original article but there are some points here I felt a need to respond to.

    First off, many folks have a somewhat outdated view of ColdFusion, based on earlier versions of the product / language. Yes, it started out life as a simple, high-level (but fairly powerful) tag-based language that was meant to be easy to learn, so that HTML coders could build dynamic sites. Over time, it grew features that allowed better structured code to be written. As the language stands today - enshrined in the Macromedia ColdFusion MX product - it's easy to write well-structured code that follows best practices, e.g., full separation of presentation and logic, design patterns, MVC... CFMX has simple, object-like "components" that let you encapsulate data and methods as well as inheritance and polymorphism.

    It might be worth noting that Charlie Arehart works for New Atlanta who produce Blue Dragon and that product supports ColdFusion pretty much on a par with Macromedia's early ColdFusion 5 release (from two years ago). Blue Dragon does not support any of the language features that support encapsulation, inheritance and polymorphism.

    Seasoned software engineers coming to ColdFusion MX today are able to rapidly build complex, enterprise-class web applications that follow best practices. It's true that there is not (yet) the wealth of framework examples and so on that the Java world benefits from but as a RAD language for J2EE-based web applications, it does a pretty darned good job. And, contrary to what some people think, it most certainly can scale.

    I'm a seasoned C++ and Java developer that came to CFMX less than two years ago. I CF a lot, despite my initial skepticism (see http://www.corfield.org/coldfusion/). I can generally get stuff done faster in CF than in JSP / Java. If I need raw Java speed or power, I can use that and still leverage the RAD aspect of CF. The availability of ColdFusion MX as a "Java Verified" application is an important step in the evolution of ColdFusion and it provides more choice for web developers. Choice is most certainly a good thing.
  8. Hmm, I see that between starting to write that and pressing Reply, Charlie has been posting in this thread. Well, that's what happens when you're too busy working to actually finish a post and press Reply I suppose :)
  9. Yes, Sean. Good to see you here. I'd like to point out that (with the caveats of my previous notes about how the article had been edited), I was writing it not just about BlueDragon but about CFMX as well. In this respect, I'd like to think we're on the same side.

    I've been making the case (as you did, so well) that they're both "not your father's CF", to paraphrase the old Oldsmobile commercials. (BlueDragon has many more CFMX-like attributes than people seem to realize. I'm working to change that understanding, but clearly we still don't have CFC's, and I said that already.)

    Anyway, I'd like to forestal any cute puns about my reference to Oldmobile and the state of that company. CFML is NOT the next Oldmobile. At least with respect to why New Atlanta has picked up the CFML torch, it's perhaps more like Jeep being bought by Chrysler. Jeep customers don't want to see it go away, and there's a business to be made satisfying their needs.

    You'll never pursuade a LandRover customer to switch. But that's not the point. The point is that Jeep remains and clearly has its purpose, argue against it as some might.
  10. Many of the anti-CF posts here seem to have this idea of CF-programmers as a lesser breed of programmers. CF certainly allows bad programmers to actually get stuff done, which has led to much spaghetti-code. Good programmers can actually use the RAD features to produce solid, well-organized code super-fast. Our Content Management Solution PublishHQ is based on CF. If we had used Java, we would not have been able to compete against the often much larger development teams of competitors. Our product excels in features and a user friendly management editing environment. I have often wondered why Java web applications often look so shoddy. The reason, in my mind, is the enormous hassle to write GUI-code (and perhaps the preference of many Java programmers to write a beautiful engine over creating a very useful GUI). We do experience scalability issues that CF can't solve for us very well. But then, our product isn't aimed at amazon.coms. Our team is certified on Java and Cold Fusion and we also implement Java solutions, so I just want to make the point that we're not blindly applying Cold Fusion to every problem we see.

    Cold Fusion MX ís Java. The next step logical for many CF shops is to implement Java at the business logic and data tier to improve the scalability and raw power of their applications while keeping the ability to be extremely productive on the GUI-side. But it is not strictly necessary to use Java to have a powerful application. Cold Fusion applications can, and should, be well structured, modular and adher to professional design principles. And when this is the case, a business manager should ask himself the question: "do I really *need* my application to handle millions of users real-time? Do I really *need* to scale to 100 servers?" If this is the case, Java may be a more logical choice. However, you do pay in terms of significantly longer development times both in initial production and maintenance. If you can have an engine built on CF for a fraction of the price you can get a Java application for, and it *is* very well designed and it suits the job. Well, then the story becomes very easy: it's cheaper.

    The stories I saw here about servers crashing every day. Well, we've been developing CF since 1996. I'm sure people have problems but the image portrayed here of CF as being totally unreliable is simply a gross misrepresentation of the facts. Our many clients and servers run reliably. If they didn't, we wouldn't be around anymore.

    JSP 2.0 certainly seems to bring Java developers more of the ease of development that Cold Fusion programmers have always enjoyed. From the development point of view I'm very excited about this because I believe in Java and I believe that this will alleviate a lot of tedious work that JSP1.1 forced you to do to write powerful GUIs. It certainly makes the landscape for Cold Fusion more competitive.

    At the end of the day Cold Fusion still delivers RAD functionality unrivalled in the market. And now that Cold Fusion templates actually compile to Java bytecode, it also offers a lot of the power of Java and, if you feel that's not good enough, allows you to integrate seamlessly with "proper" Java components and custom tag libraries. Cold Fusion doesn't require you to fiddle with configuration files, create ANT-script, configure remote debugging on Tomcat servers, worry about having the right package version in your classpath, etc.,etc. It just runs out of the box.

    I love Java but I feel that there is still plenty going for Cold Fusion.

    Kind regards,

    Marc Schipperheyn
    CTO
    <theFactor.e>
    http://www.thefactore.com
  11. Amen, brother! :-)
  12. "Many of the anti-CF posts here seem to have this idea of CF-programmers as a lesser breed of programmers. CF certainly allows bad programmers to actually get stuff done, which has led to much spaghetti-code. Good programmers can actually use the RAD features to produce solid, well-organized code super-fast."

    This is a very insightful comment. I was around when financial analysts, despairing of ever getting meaningful MIS from "Corporate Systems", became amateur programmers using Lotus 123. Professional programmers laughed, knowing that when the author left the firm would have an undocumented piece of spaghetti code to throw out. The analysts laughed when systems say "Can do that in about 6 months for about $30,000".

    There is no doubt that professional prgrammers will do a good job with the best and most powerful technical tools.

    But for a small business, tools like Filemaker, or Excel, or even CF/Dreamweaver enable someone who really understands the business to get some thing useful working at a reasobale cost. Of course the people doing this often don't have professional progamming discipline, and develop things that no one else can maintain. But don't blame the tools. For to translate a real entrepreneurial understanding to working code with the higher powered professional tools is a BIG PROJECT that small businesses can't afford.

    A professional, using Filemaker, say, can produce a perfectly good, maintainable application, within the limits of that product. It will work just fine for many, many situations and will cost far less than doing it with SQL 2000.
  13. We used to be a Cold Fusion site. While it was great in the beginning and helped us to move very fast, it scaled terribly. When our traffic started to ramp up, the CF servers crashed hourly.

    I understand they have ported the codebase to Java. Is it any more reliable now?
  14. Jordan,

    We're using clustered Jrun with CFMX, it's not stable at all, we hit some heavy load and we're in trouble. We're somewhat convinced that this is because Jrun is cheap and cheerful. We're going to deploy CFMX into Weblogic and see if this improves. I mean, we've got servlet and EJB apps deployed into Jrun and we have all sorts of grief with those and Jruns connection pools. Also, CFMX standalone ships with Jrun but in such a mode you can't deploy WAR's and EAR's into it. I can therefore understand why people reckon CFMX isn't stable, I don't think CFMX is all bad, it's just the Jrun engine isn't very solid. After that and the magic number issue we had compiling tt6

    The nice thing about CFMX is that I write Java which I can then integrate with CFMX directly through script. So we have rules processing logic which is shared by our frontend CFMX app and our backend JSP/Servlet application, both of which have to apply the same logic in certain circumstances. Therefore if you were going to migrate away from Coldfusion and to Java this is the version to do it in.

    Regards,
    Max
  15. Jordan,

    We're using clustered Jrun with CFMX, it's not stable at all, we hit some heavy load and we're in trouble. We're somewhat convinced that this is because Jrun is cheap and cheerful. We're going to deploy CFMX into Weblogic and see if this improves. I mean, we've got servlet and EJB apps deployed into Jrun and we have all sorts of grief with those and Jruns connection pools. Also, CFMX standalone ships with Jrun but in such a mode you can't deploy WAR's and EAR's into it. I can therefore understand why people reckon CFMX isn't stable, I don't think CFMX is all bad, it's just the Jrun engine isn't very solid. After that and the magic number issue we had compiling the Apache module, I'm not at all impressed with Jrun

    The nice thing about CFMX is that I write Java which I can then integrate with CFMX directly through script. So we have rules processing logic which is shared by our frontend CFMX app and our backend JSP/Servlet application, both of which have to apply the same logic in certain circumstances. Therefore if you were going to migrate away from Coldfusion and to Java this is the version to do it in.

    Regards,
    Max
  16. The reasons your ColdFusion server bog down:
    1) Sql syntax coded in the cfml pages. You needed to change all your sql syntaxes in cfml pages into stored procedures(Coldfusion MX server) at the database level. Why? It is because each request from the clients will cache on your web server instead of Database server. Here is the math -- 2MB/Client X 1000 = 2 G of webserver resource.(2MB of the database resource using store procedure.)
    2) Make sure your join statements in SQL has less than three tables for each query.
    3) Use Coldfusion Components syntax (Coldfusion MX server).
    4) Use Mercury Loadrunner to test your applications before you deploy it.
    5) Upgrade your Coldfusion Server to Coldfusion Server MX6.1.
  17. To me, this article will rather convince developers to move over to JSP / JSTL than the other way around:

    o As the authors admit themselves, JSP 2.0 and JSTL use an approach similar to that of CFML, so CFML does not seem to have any real advantage over JSP.

    o In addition, the fact that JSP 2.0 and JSTL are or are going to be endorsed by all app server vendors gives JSP / JSTL a serious advantage.
  18. The web site itself runs on CGI. Impressive for "Open Enterprise Trends"!

    Denis.
  19. The importance of JSP, CFML, and any other scripting language has decreased dramatically ever since popular adoption of Model 2 specifications. Why mix more logic (than absolutely necessary) with the view? Who cares if scripting languages are more powerful? They're hard to debug, and they get messy really easily. I think only obsolete coders, masochists, and newbies still heavily dabble with this stuff. Custom tags are (in most cases) more than enough.
  20. As I suggested in my first post...[ Go to top ]

    It's probably due to laziness.

    It's simple to write apps that doing need to scale...

    It's impossible to write apps that will scale using inferior technology, but at least getting the functionality in place will be easy...

    It's difficult to write apps that will scale using scalable technology (.NET or J2EE or even PHP if done correctly, and depending on the type of application).

    So, the lazy man tends to use the inferior technology whether he's writing an application that needs to scale or not.

    So ladies and gents, if you don't already know Java, Climb the mountain. Learn Java, and you'll see how nice the view really is from up here.

    John C. Dale
    Down in the Desert, Inc.
  21. Go away from CF[ Go to top ]

    There are a lot of view technologies in Java (JSP, XMLC, Velocity, FreeMarker, etc.) and they are very robust. If you don't want to go with Java go to PHP. At least there are a lot of solutions in PHP. ColdFusion is just a dying technology...

    Lofi
    http://www.openuss.org
  22. Folks, as one of the listed authors of the subject article, can I shed a little light (rather than heat) on the issue? First, the article was edited quite a bit by the editor before its release and sadly I didn't get to correct some things that got left with improper context. I'm now working with the editor to get that online article corrected for a few things.

    That said, I still stand behind the bulk of the article. The article was written originally to be addressed to CURRENT CFML shops that already have a heavy investment in it and the CFML developers in those shops being led to J2EE.

    The main point (some of which was lost in the editing) was that for those shops, BlueDragon and ColdFusion MX offer advantages that allow them to keep their CFML while also leveraging the J2EE platform.

    I'd like to say to some of those on this thread who are pointing up their previous bad experiences with CF, please do consider that the language has evolved, as has the platform. Indeed, another point lost in the article is that both BlueDragon (a new alternative for CFML) and CFMX (the latest version of CF), both out last year, are both built atop a Java platform.

    BlueDragon runs atop ServletExec (both products being from New Atlanta, who have been in the JSP engine business from the very beginning) and CFMX runs atop JRun (both from Macromedia, who acquired them both from Allaire).

    And both companies have recently released versions of their products that allow you to run your CFML apps atop a J2EE server of your choice, thus making CFML simply another alternative for web application scripting. (In fact, New Atlanta is releasing a .NET version offering the same native integration on that platform, making CFML the only web development language capable of running natively across such wide range of platforms.)

    Still another point lost in the editing that I'd wanted to add to this article for the Java audience is that a CFML script on either BlueDragon or CFMX can do pretty much anything that a JSP one can do: integrate with other JSPs and servlets (doing includes, forwards, sharing session and app variables, etc), integrate with beans and EJBs, be processed behind filters, support event handlers, and lots more. In the end, both products run the CFML as Java bytecode. You can even call upon Java libraries directly from within a CFML page. CFML really is just another way to write Java code, in the end.

    Some here have jumped on the point that CFML folks typically lump query and output processing (model and view) on the same page. Before you slam CFers for that, please read the whole article. I make the point that this is something that JSPers can do just as easily, and that it's not recommended for either audience.

    But despite the protestations of many, there will be those who will do it anyway (in JSP as well) and often out of naiveté. I (along with many others) am trying to evangelize better practices in the CFML community. There's no question they can learn much from the Java community (and from OO practices).

    Again, both BlueDragon and CFMX are bringing CFML folks closer to the Java community. One can take the stance that they ought to just abandon their boats and hop on the mother ship. But the practical reality is that many shops have substantial, enterprise-class investments in CFML. (Further attesting to the fact that, in the right hands, it can be very scalable and capable.)

    So the argument in the article was primarily to those CFML developers, to say that you don't need to give up CFML. You can run your CFML alongside JSP apps and even integrate them, and even do it without an underlying CF server (running instead as a web app on a J2EE server).

    It's true that a secondary point in the article was that JSP (by many people's accounts, even in the Java world) is not all it's cracked up to be. Our point in arguing in favor of CFML was more to say, "sure, it's getting better, but it's just getting closer to CFML". For that audience, moving has to be more carefully justified.

    It's very easy for them (or more likely their management) to be led by their noses (perhaps kicking and screaming) to abandon their CFML apps. Again, if they thought they had no choice or that the grass was clearly greener on the other side, they'd go along, if unwillingly.

    We don't think they should. Look, the tone was unfortunately made to be a little more anti-JSP than it should have been, especially in a newsletter for a Java audience. But that's water under the bridge.

    The main point is that CFMLers (and Java fans) all need to give CFML new consideration in light of the increased possibilities for native integration on a Java platform. It no longer needs to be an either/or or "us against them" kind of prospect. Sorry if the edit left it focusing more on that. There was a lot left unsaid, and if I get a chance to do that article over for another outlet, I'll clarify a lot of points that I think would temper some of the ill feelings some may have.

    Still, I know that for some, it doesn't matter what I add. Java purists will likely always dispute the fundamental argument in favor of CFML. Just keep in mind that there's as much venom and animosity spouted against things like Struts, Velocity, Freemarker, etc. (not to mention .NET, PHP, etc.) Hey, to each their own. As Rodney King said, "Can't we just all get along?" :-)

    More important (and another point lost in the editing) is that for some developer groups and some companies (and some budgets and some development timeframes), there's a place for a simpler approach to web app development. For managers facing growing backlogs, along with the high costs of skilled Java developers and the need to reduce development timeframes, there's real value in a simpler, more accessible approach. Especially one as complete and mature as CFML.

    Again, I grant that it's easy to let that simplicity get away from you, but that's about managing people and their skills. The language can support better separation of concerns, which is still another thing not clarified in the article. When I said, "CFML is evolving to support that notion", I was referring to a new feature introduced in CFMX called CFCs or ColdFusion Components, where the model of an app can be clearly segregated from the view (and they can also be used to provide CFML with other benefits of component-based development).

    It's new and still being assimilated into the psyche of CFML developers (though they would have understood that it's what I was referring to). CFC's are evolving still further in the upcoming RedSky edition (next upgrade) of CFMX. BlueDragon will be adding that support when the final specs settle from that upgrade.

    Even with CFC's, though, another argument could be made that the model could (and perhaps ought to) be done in pure Java and called from within the CFML view. We wonder if indeed that may be the better approach in some instances, leaving the model (or other component-based processing) to benefit from the pure OO foundation on which Java is built, rather than trying to shoehorn OO-like processing into CFML as CFCs offer (and which RedSky is supposed to improve). Again, this makes the case for considering CFML as an alternative view technology.

    Look, I'm writing on TheServerSide. I read TheServerSide. I've been doing Java for just over 2 years (a babe, I know, in the world of readers here). I am clearly more of a CFML advocate (7 years) and I do realize that many CFML developers are woefully unskilled. I make that point in the article.

    But the solution isn't to force them all to pure Java and JSP. We all know that the notion of a JSP page being all that an "HTML editor" needed to worry about doesn't really stand up. It's inevitable that more Java creeps onto a page, or as Brian Lee proposed, custom tags pop up. Just as the JSTL tries to standardize that (with some things like Query tags that make even many Java purists cringe), the point is that CFML is like one big standard tag library.

    As I said before, it's as much about what one's comfortable with, and knowing the pros and cons of each. The article was clearly written primarily for a CFML audience. When I heard it was being refitted for a java audience, I feared this reaction and wanted to have a chance to recraft it. The timing just didn't support it. I hope this clarification has helped a little.

    /charlie arehart
    CTO, New Atlanta
  23. cf vs. java[ Go to top ]

    cfmx is based on java, in fact, the whole thing is a servlet application. my opinion is that you could either pay macromedia some money to get many useful tags or spend your time go create them on your own. i love the fact that you can pass a string such as "01/01/2003" as a date "object" in coldfusion on the fly, without any programming. who would want to program such a mundane logic. also, the whole thing about separation of presentation and logic might be the best in terms of technology, it might not always make sense when time and resource are scarece.

    -- derek
  24. RE: cf vs. java[ Go to top ]

    i love the fact that you can pass a string such as "01/01/2003" as a date "object" in coldfusion on the fly, without any programming.

    >

    yes, and that object of course represent the 2003 of januari in 2001? Or is it the 1 of januari in 2003 or even januari the first in 2003? ;D

    /Anders
  25. RE: cf vs. java[ Go to top ]

    "01/01/2003" is january 01, 2003. what is your point? remember that cf is developed in us. the fact is that one can suck in any language. look around and see if any of your fellow java developers and maybe even yourself are writing a java method that tries to accomplish 10 different business logics. java, oo, lays the fundation for clean programing, but if you suck, it doesn't matter what language you use. if you conscientiously make a good effort to write clean code, you can do that in coldfusion. strut is nice, but fusebox is not too bad either. don't judge too fast when you don't know all the facts.

    java is awesome for complex logic, there were many times i wished i could call a method recursively in cf as easy as in java -- i mean, just let the machine do the work! so java is superior, but cf is not too bad.
  26. RE: cf vs. java[ Go to top ]

    In Java:

        Date date = new SimpleDateFormat("MM/dd/yyyy").parse("01/01/2003");

    In JSP 1.x/2.x with JSTL:

        <fmt:parseDate pattern="MM/dd/yyyy" value="01/01/2003"/>


    Man, all that parsing logic was brutal. ;-)

    Of course the better approach would be to use locale-sensitive components and/or tags that deal directly with parsing and rendering Date objects, so you wouldn't even need to explicitly call on a DateFormat class.
  27. RE: cf vs. java[ Go to top ]

    In Java:

    >
    > Date date = new SimpleDateFormat("MM/dd/yyyy").parse("01/01/2003");
    >
    > In JSP 1.x/2.x with JSTL:
    >
    > <fmt:parseDate pattern="MM/dd/yyyy" value="01/01/2003"/>
    >
    >
    > Man, all that parsing logic was brutal. ;-)
    >
    > Of course the better approach would be to use locale-sensitive components and/or > tags that deal directly with parsing and rendering Date objects, so you wouldn't > even need to explicitly call on a DateFormat class.
    >
    gaah, that punch line was mine, my preeeciooous! ;)
  28. RE: cf vs. java[ Go to top ]

    dude, i don't get you guys. you are still writing more code. what don't you understand the meaning of "more"? besides, judging on a single line of code is not enough. cf is simply simpler, and some people like that. why do you think jsp 2.0 exists? when jsp 3.0 or beyond becomes simpler than cf, then i'll say cf is out, but not yet.
  29. RE: cf vs. java[ Go to top ]

    Chill :)

    I didn't say that cf was "going out", nor did I say that the java solution where faster/shorter. I just pointed out that using such a simple string notation for dates in particular is very evil (atleast for web applications that are published on the internet). Unless you as a developer are ignorant of the fact that not everybody is in the same timezone as you. Which many non-americans experience every day when people say things like

    "server going down for maintenance at 02:00 Pacific time" or whatever...

    Why not use standard time atleast? (GMT)

    PS. I'm sure it's easy enough to use time zones in cf - you just IMHO gave a very good example of a common web development error.
  30. CFML just cannot compete in any way with JSP/Java... JavaScript is essential to web page programming these days and Java is similar to Java Script.. By using JSP the whole world of Java is opened to the web page programmer... CFML was kind of like a precursor to JSP and just deals with minor embedding and preprocessing issues.. it adds some databse preprocessing.. it is a tiny and simple fraction of what Java provides.. No knowledgeable person would choose CFML other than for a tiny project (requiring one person) where one has access to a CFML programmer.. It can't compete and will eventually disappear (like Pascal).. The article is an absurd justification by CMFL programmers to justify stubbornly sticking with CFML when a technically astute programmer would have switched to ASP or JSP a few years ago.. It is an absurd proposition to stick with CFML, kind of like continuing in Pascal today... It only takes a few days to learn enough Java JSP to switch over.. The depth of Java is in a myraid of features and libraries entirely outside the scope of CFML... Two years as a Java programmer is plenty.. One of Watson and Crick only had 1 yr genetics experience before discovering the Double Helix.. If you don't know it after 2 years you haven't looked at the feature or don't have the background..
  31. Again, I think you miss the point of the article, and of Charlie Arehart's message on this thread. What if your company has hundreds or thousands of pages code in CFML and now you want to switch to J2EE--what are you going to do with those "legacy" CFML applications? Rewriting the CFML in JSP just isn't practical from a business perspective.

    Both New Atlanta BlueDragon and Macromedia ColdFusion MX give you the option to run CFML within J2EE webapps and provide integration with the underlying J2EE platform. Either of these products give you the option to quicky and easily migrate existing CFML applications to a J2EE server. You could then either continue to enhance and maintain the applications in CFML, or slowly migrate them to JSP in a controlled manner.

    On a somewhat separate note, there's a new JSR for supporting non-Java scripting languages in J2EE web applications:

    http://www.jcp.org/en/jsr/detail?id=223

    The description doesn't mention CFML, but you may want to note that both Macromedia and New Atlanta are on the Expert Group, so you can expect that CFML will be addressed in some way by this JSR.

    Vince Bonfanti
    New Atlanta Communications, LLC
  32. It is true that projects heavily invested in CFML can benefit extensively from products that allow both CFML and JSP to co-exist... Legacy systems have always presented a difficult economic balancing act between porting and maintainance.. My objection to the article was that it tried to portray CFML as a viable choice going forward for new products and somehow a viable competitor to JSP.. It is not, and not necessarily because of any flaws in design or implementation, but because the market has already made it's choice and is unlikely to reverse itself.. In that regard, it would be nice to see a product from New Atlanta that converted CFML code to JSP code... I might accept the peculiarities of a machine generated port rather than continue with a "fading" technology, with the inherent problems increasing over time..
  33. JavaScript is essential to web page programming these days and Java is similar to Java Script


    I know quite a few people who wouldn't hesitate throwing you out a 10 story building for saying something like that

    >kind of like continuing in Pascal today

    ever heard of something called delphi ? it seems to be doing quite ok
  34. "For managers facing growing backlogs, along with the high costs of skilled Java developers and the need to reduce development timeframes"

    In today's economic environment, skilled java developers are a bargain. Besides I've known many computer science grads from Georgia Tech and the like without a job... and I've heard of many experienced professionals take unheard of salary cuts...

    Beginning app development exclusively with JSP, CFML, or some other scripting language is fast and simple in the Begining... however, 80% of the cost is not in initial development. Most of the cost is in application maintenance (upgrades, fixes). This is where scripting in general is really weak. Pair poor debugging tools with spaghetti code (most of it a result of code organization due to aestetics since the logic is mixed with presentation- different browsers are picky about html, css, etc...), and the inability to really comment your code; and costs for a company skyrocket (as well as the loss of sanity of the development teams) - even for "simple" applications.

    Instead of comming up with new features to match languages like java, if scripting languages like CFML want more use, scripting languages need atleast need a better debugger. Bug hunting in script is like shooting in the dark

    Yeah, I don't see the point of companies with pure CFML applications to migrate to a pure JSP implementation - that would make very little sense. However, it's wise for a company to migrate to something that supports an MVC framework like J2EE or (cringe) .NET, to keep development costs down and timeframes short. CFML can be part of the MVC. Unfortunatly, only two companies support CFML in their products, and that's a both higher risk and a limitation in choice as opposed to adopting what's almost universally supported.

    Brian Lee
    Senior Programmer
    Accenture
  35. Sure, the fact that "only two" companies support CFML isn't ideal--but that fact that New Atlanta has entered the market with a strong solution does certainly vsatly improve the situation compared to when there was "only one" company supporting it.

    And of course you're right about the vast majority of expense being in maintanence, and traditional spaghetti-like CFML code has been a contributor to poor performance, maintanence challenges, and more. You hold the "mixing logic and presentation" card, but again that's being addressed with new constructs--and more importantly, greater appreciation by CFML developers of the importance to do that.

    I must say that I don't get the "inability to comment code". As for debugging tools, CF4 and 5 (paired with ColdFusion Studio or HomeSite+) offer interactive debugging, with breakpoints, ability to modify variables on the fly, and more. And CFMX added a new CFTRACE tag that's smart enough to output (to screen or a log) only while in debugging mode.

    Finally, again, CFML *CAN* support MVC. It's just that the tools to do so are new. It will take time for CFML developers (and the rest of the world) to come to grips with that.

    And while one could assert that such developers "might as well rewrite in Java if they're going to rewrite at all", that again presumes that they have Java skills on hand. Whether their is a growing boatload of unemployed Java programmers is only relevant in a macro sense. The bottom line is that if a company has skilled CFML developers on-hand, with domain experience and familiarity with the existing system, architecture, etc., it's far less expensive to refactor the app than to refactor their staff.
  36. Forgive me for my cold fusion ignorance =)

    Yeah when I do think about it you aren't really limited to two companies, it's really just one. Macromedia makes a lot of great products, but stuff like Jrun is too unstable for production. New Atlanta is really the only choice for this route... From my experience with servletexec, New Atlanta is a good company with great products, but it is still a concern when there's only one viable company for going this route mixed with j2ee (besides providing an editor).
  37. Forgive me for my cold fusion ignorance =)


    That's ok. We're here to help. :-) I really do mean that in so far as evangelizing better CFML practices among that community, and better appreciation of CFML's place in the Java community. That article, as it was written, wasn't really the right one for doing the latter, and again I hope to rectify that. If not in that article, then in a future one. Heck, my reply above is virtually an article. ;-}
     
    > Yeah when I do think about it you aren't really limited to two companies, it's really just one....

    Thanks for that compliment. We really are proud of our success in the java server field and hope to bring the same level of effort, quality, and success to the CFML field.

    I know that to many in the Java world it's a bit tawdry to be a commercial company offering such solutions. And we realize that CFML (indeed, BlueDragon) won't be a solution for everyone. But our success so far has clearly demonstrated that for the right need, we really do have the right solution.

    Look, we all know that a debate over the merits of any technology on forums like this will almost always degenerate into bickering between camps. And as much there can be light shed on the discussion making it worthwhile, there will also inevitably be those will argue against something either with dated perspectives, or harshly critical ("you'll never beat my solution") ones. No one wins in those debates.

    I hope that what I've said to this point will address the concerns raised above, but I know inevitably some will want to prolong a debate between CFML and JSP. Let's give that a rest.

    Again, it's not really an either/or proposition. The two can co-exist, and in some environments that makes sense. The CFML language is evolving, as are its developers, and indeed the platforms on which it's supported. That's the more important message, than the focus on whether JSP is better than CFML. That's a schoolyard fight none of needs to watch. :-)
  38. CFML vs. JSP/STRUTS[ Go to top ]

    Since many developers are switching to STRUTS,WEBWork,JSF, etc. they wrote how cool CFML is. I dont think that CFML can offer advantages that are comparable to STRUTS + TILES + VALIDATOR.

    I use STRUTS and I dont write business logic and SQL queries in my JSP pages. I dont want to end up with unmaintanable code. So it doesnt matter how easy one can do it in CFML.


    Maris
  39. For what it's worth, I've used JRun in production on numerous projects and found it to be super stable. I have had trouble with a certain other server, making it appear unstable, but then found that the instability was due to my misunderstanding of a few config settings on that server. My own errors while setting that server up shouldn't be stated as objective truth, and the same goes for JRun.

    Even though I like JRun well enough (who really *likes* any app server, anyway, or who cares which one they use anymore?) and find it solid when tuned, does macromedia even intend to keep making it? I mean, they seem to give it a pretty cold shoulder.

    I am not a fan of CF, but would imagine that if a shop has a bunch of legacy CF code, it's a good thing that they can port that to Tomcat or whatever without spending money to rewrite it. I also think that the guys who use CF are mostly web developers and designers, and you can't really tell those guys to just write your own custom tag instead. That's a solution for us Java developers not for web guys who just know basic SQL and how to use tags.
  40. is to build up a site quickly and the client doesn't care if the server coredumps once a day.

    we are in the middle of porting our app from CF to j2ee. and our client does care when and if the server crashes.

    what i don't understand is why peoeple would even consider using cold fusion these days? everybody is shifting to adapting open standards - which cold fusion is not. and if you want to write jsps in cold fusion, you might as well use jrun - why go through another layer with a bunch of overheads. :-)
  41. is to build up a site quickly and the client doesn't care if the server

    >coredumps once a day.

    This may have been true for the old ColdFusion *Server* products. The point of BlueDragon (and CFMX) is to replace the ColdFusion Server with a CFML engine, written completely in Java, that runs on top of a J2EE server. The the J2EE provides you with performance, scalability, and reliability.

    >we are in the middle of porting our app from CF to j2ee. and our client does
    >care when and if the server crashes.

    For small or medium sized apps, rewriting from CFML to JSP is certainly an option. For large or huge apps, it's not. BlueDragon costs $2500/CPU, so if its costing you more than about $10,000 to rewrite your app in JSP, then you haven't chosen the most cost-effective solution for migrating your CFML app to a J2EE server (having said this, I do realize there are other reasons to consider rewriting).

    >what i don't understand is why peoeple would even consider using cold fusion
    >these days?

    Not everyone should--this isn't necessarily a solution for everyone, but for some people with specific needs. For people and organizations who have a significant investment in CFML in terms of existing code, training, and skills sets, using a solution such as BlueDragon or CFMX to run CFML on J2EE might make more sense than retraining or rewriting.
  42. <
    That's my point right there. It's a fairly huge overhead running on top of J2EE without access to many of J2EE capabilities. And that overhead kills the scalability, perforamce and reliability of J2EE. So why use CF?

    The only way that makes sense to use CFMX is with a long term plan to port CF into java by supporting existing CF codes and writing new ones with java - at least i know that was what many companies wanted to do when allaire announced MX. unfortunately, aftre MX was released, most quickly realized it's not possible with the way MX allows developers to use java objects.

    <
    depends. i personally haven't seen a CF site that can't be ported over to java in less than a year at max - mostly due to the fact "old" CF didnn't scale well and didn't perform well under heavy load (problems with variable lockings, heavy usage of windu or windows registry, etc). maybe MX and the next version of MX(whatever its called) would work better. but i wonder if supporting CF with the hope MX would get better would be a smarter decision than investing a year and $$ and be free from those unknowns.

    CFML is what it is - a markup language. I personally think allaire/macromedia should've stuck to the idea of markup/scriping languages and fine tune the product to better support small to medium size applications, instead of trying to compete with app servers for large apps.
  43. Another this vs. that thread....[ Go to top ]

    These types of threads appear about almost every major operating system, and in this case language. There is however a fair bit of mis-information coming from the Java/JSP side of the house that I would like to comment on. Before I get in to this, I am a developer and write in several languages. I firmly believe that every language has it's purpose, and that a decent developer will use the language that suits the application.

    == ColdFusion isn't stable or isn't fast under load ==
    Clearly this is either an opinion based on inexperience with the platform, or someone that wrote some shoddy code and put it in production without going through proper regression and performance testing. What constitutes load? 3000-4000 simultaneous users? 60 million pages a month? ColdFusion can definitely can handle load, with properly written and architected code. Doesnt't that apply to all platforms :). I've seen some JSP sites that are downright slow, almost unusable. That certainly doesn't mean that JSP or J2EE is slow, just poorly written code. The issue that ColdFusion has, is that the language is relatively easy to pick up and you have a lot of developers that were never taught some of the basics.

    == You can't write properly architected applications. ==
    Really? I'll agree that ColdFusion simplifies the underlying core of J2EE, but you can write just about anything that you have an imagination for. You can write a complete web based api for instance that resides in memory, that's self documenting and can be exposed as a webservice whenever you feel like it. You can completely separate business and presentation logic, using XML and a component architecture. Architecting an application is an exercise in using your imagination to produce an architecture that fits your application going forward. While architecture is dependant on the underlying core, there is always more than one way to skin a cat.

    Saying that, I think Macromedia has an interesting road ahead. They are servicing two sets of developers now. They have the developer crowd that stays within the basic tag set and creates relatively simple applications. But, with the functionality in MX they also have developers creating complex applications using components, web services, xml and using the power of the underlying JAVA architecture.
  44. ColdFusion can definitely can handle load, with properly written and

    >architected code

    I do not think you have ever used CF.
    "The other issue could allow ColdFusion Server templates to be overwritten with a zero byte file of the same name."
    My coworker posted about this problem to CF user forum a few years ago.
    Alaire support just deleted this message after few minutes.

    http://www.macromedia.com/devnet/security/security_zone/mpsb01-07.html

    It takes three years to fix this kind of problems and you have no way to fix it yourself.
  45. Jouzas, pure criticism, specially the ones based on "few years ago" issues and facts is so boring. It's very easy for anyone to criticize anything, Just google words such as "PHP sucks" or "Java is slow", etc... It reminds me all the waste of energy discussing the "sex of the angels" in the Windows "versus" Linux stuff. What a waste of time... Sorry.

    Well, a "few years ago", PHP, ASP, ColdFusion, Java (know as "slow") and so many technologies are so insecure, slow and crappy that I can't imagine how people used it... Please talk about things you know, not things you "heard", specially when it cames from other "eons" in the Internet time. We're not discussing what is best or worst. This is all relative but looks you don't know it (maybe because you're unexperienced). But anyway, let's back to the thread focus.
  46. What a waste of time... Sorry.

    Agree, it is the last last message.
    >Please talk about things you know, not things you "heard"
    I know it too much.
  47. ColdFusion is good business for me. I have had 2 clients call me to convert to Struts so I made a few $.

    I am doing more Flash data entery forms.

    .V
    www.baseBeans.com
    (new bP just released for download)
  48. Let me paint you a picture...[ Go to top ]

    You just get a job with a pretty cool company with cool people.

    You first assignment, however, is to make sense of, take ownership of, and maintain a big application that runs on top of an application that runs on top of a J2EE container application. Now, consider that half (roughly) is written with cold fusion and half is vanilla JSP, and flows are intermingling between the two technologies, and variables, attrs, and params are being passed back-and-forth between the two technologies.

    If this is a typical application, you won't have a site map or good documentation for the flows (as a practice, with each use-case, I tend to do a quick activity diagram that details the flows with comments about sticky impls, gotchas, or potential performance improvement to-dos, but my practices are the EXCEPTION).

    Now, you're told to improve the performance of the application.

    After you wake-up from the hospital after having your brain-hemorage, you have a chance to contemplate this picture. Honestly, it's like having to wipe the butt of the people who shat that awful mess in the first place, right?

    Who wants to do THAT?

    Trust me...J2EE and Java. Learn the libs, the syntax, and the paradigms. One language from front-to-back. Drop your poop rags and step forward!

    Cheers.

    John C. Dale
    Down in the Desert
  49. as does PHP, ASP, Perl, C++, yadda yadda.

    It's important to use the right tool for the job.

    It just so happens that Java is the right tool for Enterprise apps. These days, why bother writing an internet application that, if successful, will be doomed to failure by non-scalability and performance?

    Anyway, I'm back to coding. I have J2EE apps to write ;)

    John C. Dale
    DITD
  50. Java is the right tool for Enterprise apps.
    J2EE is a fantastic.
    OK, we all agree on that.

    A lot of people also agree that :
    - the complexity of J2EE/Java is still a major issue (especially for the presentation layer),
    - pure J2EE/Java might be lot of overkill for many simple to medium size applications, where scripting languages are more appropriate.

    ColdFusion MX and CFML is one of the answers to those issues.

    The problem on this thread is that most of the pro-JSP people don't know anything about the latest release ColdFusion (MX) and not much about CFML.
    Whereas most of people talking about ColdFusion here (Charles, Vince, Sean, Marc) know and have been working with CFML and JSP/Servlet.

    Again, the purpose of this thread is not to compare ColdFusion and J2EE/java (ColdFusion is a J2EE/java app!) but CFML and JSP/Servlet.

    For your information, with ColdFusion MX and CFML, you can :
    - use existing Java Frameworks (STRUTS and others),
    - use JSP tags/taglibs (JSTL and others),
    - interoperate with JSP pages,
    - use Java servlets,
    - use Java objects, including JavaBeans and Enterprise JavaBeans.

    MVC/Model 2 can be very easily implemented (even more easily than with JSP/servlet).
    Most common design patterns can also be implemented with CFML.
    CFML debugger is great.

    So please, please refresh your outdated view of ColdFusion and stop saying that :
    - "ColdFusion is an inferior technology" : it is a J2EE/java scripting language (CFML is compiled to java bytecode),
    - "CFML is a tiny and simple fraction of what JSP provides" : you have the same access to the java universe from CFML,
    - "CFML is only for beginners" : it's like saying that "JSP+JSTL is only for beginners",

    My .2 cents for monoglot CF-ers : learn java and leverage its power in conjunction with ColdFusion MX.
    My .2 cents for monoglot fanatic slashdot Java-ers geeks : try to look around, stop neglecting other technologies and plate-form (.NET), there are not as bad as you might think... ;)

    It's important to use the right tool for the right job...
    It's never good to be a technology fanatic.

    ColdFusion MX has definitely its place in the web development universe.

    In my opinion, there are many cases where ColdFusion MX and CFML might be used :
    - RAD development (I don't think you can't find an easier and most productive plate-form on the market today),
    - CFML-based View layer of J2EE apps (instead of JSP),
    - Server side components of Rich Internet Applications (CFCs to be called by Flash clients through Flash remoting).
  51. Hi CF experts,
    I have used CF a few years ago too. It was a lot of problems:

    1. Security,
     not safe session management ( persistent CFID, CFTOKEN )
    2. Performance,
     simple, but useless cache implementation ( CFCACHE )
    3. No way to intercept requests ( CGI variables are undefined in Application.cfm )
    4. no good ways extend ( too simple JAVA and C++ interface, no custom functions )
    5. dangerous ( cflock )
    6. Too many bugs ... ( memory leaks, crapy smtp, cfexecutive workaround, ... )
    ....

    This technology can be good for trivial applications (1 - 10 pages ), but there are a lot of better and free technologies for this trivial use case.
    I believe the most of things are solved in new versions, but I can not trust this technology more and it is too expensive to experiment with CF versions, It took a lot of time to rewrite CF applications with JAVA.
    I think it is not a very good place to discuss about this crap.
  52. 1. Security,

    >  not safe session management ( persistent CFID, CFTOKEN )

    ColdFusion MX use the session management of the underlying J2EE server.

    > 2. Performance,
    >  simple, but useless cache implementation ( CFCACHE )

    Caching is very easy to implement with CFML (cfcontent and cfcache tag), much easier than in JSP.

    > 3. No way to intercept requests ( CGI variables are undefined in Application.cfm )

    CGI variables are defined in Application.cfm.

    > 4. no good ways extend ( too simple JAVA and C++ interface, no custom functions )

    CFML is very easy to extend (much easier than JSP) :
    - CF custom tags,
    - CF user defined functions,
    - jsp tag lib (as in JSP)
    - CFX API for java/C++...

    > 5. dangerous ( cflock )

    Was true in previous version of ColdFusion.
    Not true with ColdFusion MX anymore.

    > I think it is not a very good place to discuss about this crap.

    The ColdFusion version you're talking about is probably very old...
    It is even not possible to compare it with JSP : at this time, JSP even did not exists and J2EE was just at its beginning.
  53. It is no problems with CFML as markup language,
    release it as Open Source, developers will fix it themself, I can help too.
    Is it secret or to crappy for open source ?
  54. CFML is not a proprietay language. You can write a server to interpret it whitout paying a cent to Macromedia. This is what BlueDragon (from NewAtlanta) does. You clearly don't know nothing about ColdFusion... Why Java is not OpenSource??? It's too crappy for it? Come-on... this all pure and unbased criticism. Please refresh your mind and post some good, new and intelligent comments.
  55. When not to use CFMX[ Go to top ]

    <quote>
    A lot of people also agree that :
    - the complexity of J2EE/Java is still a major issue (especially for the presentation layer),
    - pure J2EE/Java might be lot of overkill for many simple to medium size applications, where scripting languages are more appropriate.
    ColdFusion MX and CFML is one of the answers to those issues.
    </quote>

    Nope, surely not. You don't need EJBs, etc. for a simple presentation layer. CF is not comparable with J2EE. CF is just comparable with JSP/Servlet, XMLC/Servlet, Velocity/Servlet, etc. + a data access framework. Why do you think someone should begin with CF (if he/she has to write a new application)? I'm not talking about handling and maintaining "old" applications.

    There are many other good "free (Open Source)" solutions in Java, which are also very easy to use. Check out Enhydra, which gives you an easy to use presentation layer (XMLC and not JSP based, but you can also use JSP if you want to), OR/Mapper DODS, integration with IDE out of box. Enhydra has a simple concept and very easy to use (No EJBs). And everything is Java/servlet-based. You also have Enhydra Director to build clusters for your Enhydra applications. There are others too: Jakarta Turbine. It uses JSP or Velocity.

    So, for building a new (also very simple) application, you don't have to use CF anymore. You have many choices in Java and almost all are free.

    It is different if we are talking about maintaining old applications in CF.

    Regards,
    Lofi
    http://www.openuss.org
  56. When not to use CFMX[ Go to top ]

    CF is not simple, it just looks like simple before you start to use it in production. It needs a lot of workarounds and knowlege for performance tuning, security, synchronization and you do not have CF source code and no way to fix it. PHP, TCL, perl, JAVA ... are much better solutions and CF is not comparable with JSP/Servlet, this stuff is not open and there is nothing to compare.
    If developer has no source code and can not modify it, he has nothing.
    I am tried to "fight" with this crap, but the best solution is to rewrite applications with open technologies and I did this (It was much more simple than CF).
  57. When not to use CFMX[ Go to top ]

    It's funny to see how people get stressed regarding this issue. If JSP is so superior to CFML (on top of J2EE) why all the anger and fear (for some desperate comments I've saw here)? Kudos for some sensate and technical "defenses" of JSP and even Java, since some people are making confusion comparing CFML with Java. I liked the Lego and concrete metaphor and agree with it despite of the arrogance and prepotency in many other comments. To clarify again: CFML is not comparable with Java!!! Let's talk about server scripting technologies such as JSP, ASP, PHP, etc.

    It's incredible to se that some people forget (maybe because the fanatism make us blind) that the factors involving an application/software/anything is much more than 0 and 1's. Deciding between CFML and JSP plataforms just as plataforms is uselles if you don't analyze the large amount of factors (technical, HR, administration, etc, etc) involved.

    Please use what is better for you and your business/clients. Jouzas, who cares about your personal experience with CF? It doesn't mean nothing for me and my decisions. Saying: CF is bad because once upon a time, I was using it and... bla, bla, bla... is so empty as saying: blond girls are better/prettier than others because I date with a very beautiful one... Take a look around, there are lot of people using it sucessfully in small, medium and large apps (just to mention two larger ones: Boeing and Embraer (the 4th larger world jet-line producer, here in Brazil).

    Again, let's use what is better for us and our business/clients. For those interested in what CFML (and ColdFusion) is (in a very "entry-level" basis) please take a look in the http://www.cffaq.com.

    Abraços!
    Alex
  58. When not to use CFMX[ Go to top ]

    Please use what is better for you and your business/clients. Jouzas, who cares about your personal experience with CF?

    Yes, nobody cares about my personal experience, CF support does not cares about it too. Fine, I just not going to use "better" versions and I solve my "personal" problems myself.
  59. <Java is the right tool for Enterprise apps.
    J2EE is a fantastic.
    OK, we all agree on that.

    A lot of people also agree that :
    - the complexity of J2EE/Java is still a major issue (especially for the presentation layer),
    - pure J2EE/Java might be lot of overkill for many simple to medium size applications, where scripting languages are more appropriate.

    ColdFusion MX and CFML is one of the answers to those issues.
    >>

    i just want to make a couple of points briefly.

    First of all, many people implies J2EE include ejb, jms, etc. That doesn't have to be the case. Simple MVC based application (such as struts) can still be considered J2EE app, and those models fit in the small to medium application nicely.

    In my previous job, we were using CF MX - and i'd also like to add that we had some great CF developers who would write pretty good looking codes.

    Some might make points on different issues of CF (or java/j2ee for that matter). My take on CF - yes all the offerings sound neat and smart, but based on my experience as well as what i hear from my friends who are darn good CF developers, MX is buggy and not as reliable as CF 5. You can certainly build cleaner app using cf components, but it's nowhere close to be called an OO technology ( constructor, abstraction and interface layer, etc are not there).

    having said that, i also want to point out jsp is not the superior technology for templates. I used to work on netscape application server 2.1(used to be kiva) which had this propritary thing called template basic engine and template data engine. it did more than what current version of struts does. you could build a fairly complicated presentation layer with it while maintaining all the business logics in the "applogic" level. it's a shame that netscape throw it away to join .com alliance with sun.
  60. Here's my 2c; an extremely long message in a very tired thread. Well: "The road of excess leads to the palace of wisdom." William Blake.

    I've read all the arguments and I have also spent couple of years working on a cold fusion system (roughly 120 kLOC; I've got scars). I'm ignorant of the mx fixes to cfml but through v3, v4, v4.5 I'm sick of hearing "ah yes those problems you are having are all fixed in the next version" so if you're going to try to convince me that it actually works now I'm too jaded to be swayed by mere words.

    Stability:

    If you track down the readme from v4.0 etc. you will see that there was a memory leak in the C++ implementation of Cold Fusion Server (pre MX) that couldn't be fixed for several years so they just added a daemon thread to bounce the server every 24 hours.

    Trying not to argue on tech grounds:

    Oh I have mountains of technical arguments against cold fusion (note I haven't mentioned java yet) but I'm trying not to pitch them here. Many of them rely on intimate knowledge of cfml and very few of the cfml programmers I have spoken to about this stuff have the skills or experience to debate these aspects (even those senior in the user groups). Most Java programmers have never heard of Cold Fusion. Other technical arguments in the architectural stratum (as opposed to the nitty gritty of the implementation) have been understood and articulated here from both camps, notably the eloquent Charles Arehart.

    Who the hell am I?

    If I sound arrogant I apologise. I've been programming different systems for 23 years. I know enough to know how little I know and though I can be swayed by informed debate and empirical evidence such stuff is rare. It's notably absent from many bold productivity and viability claims presented.

    CFML Language Design:

    When Simeon Simeonov invented the "language" he had never designed one before, had no training in it and I'm afraid it shows. He was a trained economist though and in its way that shows too :). It took more than 5 years (v5 aka MX) before there was a proper grammar. With an ad hoc parser there could never be many decent dev support tools. VB and Perl had the same problem and both of these have new grammar-generated parsers now (or soon). Note that none of the language design community sites pay the slightest bit of attention to cfml though they collectively cover the history and debate of literally thousands of different languages (including tag libraries and the whole xml thing).

    Poor JRun:

    Note that CMFL was Allaire's only product until it bought JRun from a company called JRun. Later Macromedia bought falling Allaire shares since their earlier server product ("Drum") failed maybe because graphics programmers can't design servers. Note also that JRun development is run by one individual (who bugs the JBoss developers list with inane questions). JBoss has in the order of 10 core developers, BEA Weblogic reportedly 7, IBM WSAD has 100(!) or something. Please take these figures with a grain of salt, I can't prove it so if you know better then speak up - it's hearsay but it does fit.

    Macromedia aren't stupid. They did buy a lemon, but then they had nothing better and it was a cheap lemon with some juice left. First thing they did was drop Spectra. Spectra was a very large CFML implementation of a content management framework. It really was not maintainable (like all large CFML systems) and so it was canned.

    The next thing Macromedia did was make CF a part of a suite where everything has an MX next to it. Perhaps to solve the apparent problem that all the different suite members have different version numbers and perhaps following microsoft's trend into two letter acronyms: (CE,ME,NT,XP). Modern execs love to have a "total solution" product suite. They also finished the rewrite in Java. When they finally released Cold Fusion MX (v5) it silenced all the arguments from CFML zealots that had concentrated on the myth that Java was too slow. The new Java codebase was faster than the old C++ one (though that was due to compilation to servlets as with JSP rather than running in an ad hoc interpreter).

    CFML developers are monoglots:

    The unfortunate thing about the CFML community that I can tell is that it is full of people who have never progressed to another language. They started with CFML because it was easy to get started. They developed a guestbook, then a message board and then they got paid to do bigger stuff. They are still on their first language and they have not been developing long enough to see their first language wither away. They will. We all do if we stay in the game long enough. All the VB developers I know seem to suffer from the same malady. The same problem does exist in the Java community, however, my observation is that many developers who choose java have quite a few languages under their belt. The shame about the article is that it discourages these CFML people from taking the now shortened step into something better (since it's all sitting on Java now anyway).

    As a developer who often chooses Java, I am convinced that we will move on to something better, and I will be one of the first. I'm interested in moving on, I accept that new technology replaces old and that some good stuff gets left behind. Only beginners don't know that. In business terms it may have had market share and it may be eroding only slowly (I don't know) but it seems clear that as every other similar technology has moved on and become general purpose (as Perl did from it's awk-like beginnings or as PHP is doing by breaking out of tag-land), CFML will need to present a strategy for being more than just a way of creating a message board without needing to know about architecture.

    I'll repeat one point made here that appears to be missed by many commenting on CFML vs JSP. It may make sense to compare CFML and JSP, or JSP+JSTL, or webmacro, or velocity etc. but it makes no sense to compare CFML to Java. If you are doing that then you're comparing Lego to reinforced concrete. You don't see construction companies building skyscrapers with Lego because they don't want to wait for the concrete to dry! It's fine if you're talking about little jobs (that will never become big) but it is a high risk investment for companies that need a scalable and maintainable architecture. Many do not realise they do need such a thing until it's too late. (B1FF Hax0r told us he could build anything.) Unfortunately I need to qualify my usage of the term "scalable" because most CFML developers I have known have trouble understanding any other form of scalability than volume processing (i.e. more hits). The kind of scalability I'm talking about is system scale and complexity. Anyone who has written large scale systems knows that complexity kills (hint: if you don't count lines of code or use other formal metrics then you're probably not writing a big system).

    One relevant thing I learned from the legendary "The Pragmatic Programmer" (Hunt & Thomas): learn a new programming language every year and read a technical book every month. Or as Dale said "drop your poop rags and step forward" heh.
  61. J2EE vs CF[ Go to top ]

    We have tried to install a development environment for the last 3/4 weeks without much success on a W2K server for Oracle 9i AS. It is full of a patchwork of patches (much crap). Our management thinks that spending lots of $$, just to produce html web pages is great. Sorry, html/js/css/dhtml is a poor model for applications. Standards are very weak throughout the the web (ie., XML, Javascript). At least CFMX can be installed easily and produces good results (ie., use Oracle stored procedures for db), if the developer is more concerned with performance/functionality and form. I'm not impressed at your 23 year, since I have more. It is not years but brains.
  62. This is probably true. There's nothing wrong with being a beginner. I'm a Cold Fusion developer (CF is too simple for me to call myself a "programmer") looking to learn Java after the results of a Rational load test proving without a doubt that Cold Fusion (v5) doesn't scale. It can handle many simultaneous users, yes, but not when they're doing the exact same thing at the exact same time.

    The rag on CF is that it is unscalable (at least for v5). The rag on J2EE is that it is too complex. What J2EE really needs is a book similar to Ben Forta's Cold Fusion Web Application Construction Kit, with which almost all Cold Fusion developers got their start. If someone could write a book called The J2EE Web Application Construction Kit or whatever, they could get a huge mindshare of CF developers. I've used the JSTL, and it's very CF-like, so much so that it really doesn't make sense to continue to use CF.
  63. I've used the JSTL, and it's very CF-like, so much so that it really

    > doesn't make sense to continue to use CF.

    To paraphrase Lloyd Benson's retort to Dan Quayle in the '88 primaries, "I know JSTL. I've worked with JSTL. JSTL, you're no CFML".

    Please, Henry, asserting that JSTL supplants CFML is like saying that a roller skate supplants a car. JSTL is just a lightweight set of tags to be added onto JSP. And the number of tags in JSP is equally limited.

    Just as others have asserted you can't compare CFML to Java (because Java is SO much more, I'll grant), so too is the set of tags enabled in JSP+JSTL (a couple dozen) hardly a step toward the richness of CFML (nearly 100).

    When you add to that the fact that a CFML page can leverage underlying Java libraries as well, is indeed reduced to Java in the end on both CFMX and BlueDragon, and that running atop a J2EE server totally changes the instability/scalability picture that challenged the standalone server in CF 5 and before, and one really has to change their arguments against it.

    I'll grant, again, that it will take time to for everyone to "get it". But, hey, there are plenty who still don't get (or buy into) Struts, Velocity, Freemarker, etc. Change is difficult. Opinions are hard-formed. But we won't let that stop us. We know that we have a case that's compelling to many.
  64. Over time, the JSTL will have more functionality, and Java will become easier to work with. Java simplicity is a stated goal of Sun. And given the open source nature of the JSTL, which I grant cannot now match CF, theoretically all of CF's functionality could be reproduced in a short period of time.

    Extending your metaphor, yeah, Bentsen had a great, memorable soundbite, but he still lost the election.
  65. I too suspect that the JSTL will evolve in time. The question is, how long? And when will it (if ever) match CF's simplicity. Sure, it may be a goal Sun has, but it won't come quickly or easily.

    Indeed, as for whether "CF's functionality could be reproduced in a short period of time", this would not be the first attempt to do so.

    A few years ago, a group of ardent Java developers saw the ease of CFML and began toying with an implementation of CFML tags atop Java. The project, first called TagFusion and then TagServlet, was a modest success. There was even talk at the time of making it an open source project. But it became clear that really matching CFML's richness was not going to be that easy.

    Indeed, it was from that foundation that New Atlanta acquired and renamed the product BlueDragon, and has since (along with key folks from that original team and the engineers who made ServletExec great) brought the product to the point where it's nearly feature-compatible. Our website, newatlanta.com/bluedragon/, offers info on the few remaining differences.

    As for this:
    > Extending your metaphor, yeah, Bentsen had a great, memorable
    > soundbite, but he still lost the election.

    Logic students, help me out: is that "argumentum ad hominem", "non causa pro causa", or "Ignoratio elenchi"? I can't recall. :-)

    Anyway, on another subject, I found it quite intriguing that a whole new thread was spawned yesterday here at TheServerSide: "TSS Opinions: Proprietary vs. Standard Solutions. Which is Best?", at http://www.theserverside.com/home/thread.jsp?thread_id=20354.

    While the focus is more on the old object/relational debate, and even the using SQL extensions conundrum, much of it applies to the argument for CFML as well. Though, there as here, too many fallacies of argument will likely ever permit satisfactory conclusion of the debates.
  66. CFML Programmer and proud of it[ Go to top ]

    I read all this talk about which is the best language for bigger or better applications, and believe me it makes e puke. I got into the business of designing web sites by chance and then into programming web applications by necessity. Before I give you a piece of my mind, let tell a bit about my history with CFM.

    Back in late 1995 a friend told me he wanted to create a web site, but did not have much money to spend. So we decided to teach ourselves HTML, and guest what, we did, in less than 5 days we tough ourselves HTML, designed and published the site. Other people found out and before I knew it I was making money from home. About a year later my friend calls me and says he needs my help once more.

    I so happens, that his site is successful, has a lot of user, much more information to post, wants to charge users to access, critical data, and DON’T KNOW HOW. Needless to say me neither. So we online to do some research, before long we come across allaire.com.

    Downloaded ColdFusion and some sample files, several hundred pages, scripts from different sites. My friend was too busy with his business so I though myself CFM, designed an Access 97 database, rewrote the entire site in CFM; and fell in love with it ever since.

    What’s my point?

    It is that I resigned my job, and dedicated my free time to CFM, and as long as CFM is alive, since some of you think it will die soon; I will continue to support my family and myself with this simple and unassuming language. I’ve read ASP, JAVA, etc., but prefer to continue to work with CFM, to date I have designed more than 20 sites, big and small, and if you want to see my first creation visit www.fedcrimlaw.com.
  67. What is that smell? .....[ Go to top ]

    not sure, but it could be fear.

    Over the past year or two, I think that small, yet extremely vocal sections of the Java community have become incredibly defensive of the language, to the point of spreading half-truths and in some cases, really, really big fibs.

    Reading some of the messages here, I'm amazed that some folk aren't writing websites in assembler.

    Judging by the fearful posts, I had a definite feeling that I was missing out on something, so I downloaded a freee copy and gave it a go.

    <
    My God! You're right! ... but neither is JSP. Big deal. The language is designed to be an easy fit for web developers, which I imagine is the reason it has remained so popular. I suspect the other reason is that CFML pages render very nicely in DreamWeaverMX; a pity the same still can't be said for JSP.

    <
    Yes that really is a bind isn't it? The developer edition is free, and hosting companies will host a coldfusion site for about the same price, or less than the cost of hosting a Java site. This really doesn't make much sense though, since I would imagine that running a ColdFusion engine would require the same or more resources than Java. Neither comes close to the near-nothing cost of a LAMP setup though (if you don't mind putting the work in, which I do).

    <
    JSTL does not come anywhere close, to the simplicity and sheer breadth of functionality contained in the CFML tag base, and that's not including the huge number of free tags available from third parties. Having spent a few weeks rummaging around, I believe the secret is that CFML *integrates* with the ColdFusion application rather than just sitting on top of it, like JSTL sits on top of Java. Will JSTL match CFML? I have no idea, but judging by what Sun churned out as JSF after so many years of development, I'm not holding my breath.

    <
    I have some really bad news chaps. The vast majority of companies don't care. Open source is popular because it is free, not because companies now have the ability to fix bugs in it. What they want is, reliable, well supported, stable code. They don't want to be told "You've got the code - fix it yourself" when they find a problem. Personally, I'd rather pay for good code than get bad code for free. I mean free is great and all, and there are stunningly good free apps and frameworks about, but I use them because they're good, not because I'm too cheap to get something better.

    I've got some way to go learning ColdFusion, but I can definitely see some potential. Of course, it won't be suitable for every site (I still have no evidence that this thing will scale up to really big applications), but small/medium sites I can put together in no time at all.

    What really gets me is that folk seem to think there is no room for more than one technology. That strikes me as really strange. I'll be using both Java and ColdFusion, and now that I've picked up the learning bug again, .NET is next.
  68. Hi,

    CFML will die when Java Dies. Atleas that is what is the present Scenario. I started my career in CF3.0, then moved to PHP, Java and ASp, a CRM product called e-Point and now back to CFMX6.1. What an amazing change in CFML fromm 3.0 to MX. It has moved from C++ to Java Platform. Every cfml template is an extension of the ServletContext Class. So CFML Essentially lives inside a Java Runtime Engine. Most of the functionalities provided by CFML is sufficient to run the normal websites that has features such as Shopping/cataloging/etc. But view CFML as an abstraction over JSP/Servlet based implementation. In fact the best way to use CFMX properly is to model ur System using Java Class/Object relationships and then use CFML to do the functional tasks such as responding to user inputs and displaying web pages. Simple. In fact it is one of the most intelligent and sophisticated implementations of the Servlet Specification. Everyone was making a loud noise that Java is a platform. But not many have really tried hard to create a good scripting language based on Java like what happened with PHP/perl based on C,C++. CFML is an excellent scripting language based on Java. what you write is CFML and what gets executed is Java. It is just a simpler way to do things. If you do not like this, then you would not like XML either. You are better of sticking to SGML instead. You say that by using Java U are not locked to a vendor. Who said that?. Sun Micro Systems? IBM.. Balls. If you invest in IBM Websphere for a project that too six months to complete, will you immediately migrate to BEA Weblogic for your next project just to prove that Java will run on both?. Non sense. You may well do it as long as your client is running the business from a Venture capitalist fund. ColdFusion is here to stay. It is a new approach to make Java more freidnly and approchable to not-so-bright programmers. End of the day we all do it for our living. For our survival. God has not said that if you write 10 million lines of code, I will grant you a life without death/sorrows. Not even the founders of Java will be willing to reward you. It is business. So learn as much as possible. Learn to appreciate the beauty of creation. Each creation/invention has a meaning. These are all just tools in the hands of a Programmer to do his job. Simple.
  69. Extending your metaphor, yeah, Bentsen had a great, memorable soundbite, but he still lost the election.

    Forget about Macromedia for a second. The real winners and losers are the customers that use the software. As much as CF (etc.) have helped those customers, it's been a win for them. With the more recent CF-related announcements, interop with other Java technologies has become simpler, opening up possibilities for those same customers, again allowing for more wins.

    If those customers hate CF (etc.) because it sucks and they feel locked in, then it's a loss. But (from my limited experience) that is generally not the case; CF was the "VB" of the early web sites, and a lot of people like it because it made their lives easier. (As a caveat, I happen to like a lot of things about VB. I wish Java tools developers had to use the crap that they produce to make "real" business applications, and we'd probably see a lot better tools if that were the case. Same for Microsoft -- you can't easily build "real" business apps in their .NET tools, although it's easy to make web services that don't do anything.)

    Over time, the JSTL will have more functionality, and Java will become easier to work with. Java simplicity is a stated goal of Sun. And given the open source nature of the JSTL, which I grant cannot now match CF, theoretically all of CF's functionality could be reproduced in a short period of time.

    And if CF has contributed to the concepts that will make JSTL a success, then we should give it credit where due. There's no reason why CF has to "lose" in order for JSTL to "win".

    Here's to better tools, easier frameworks, and higher quality servers. And if some of them come from Macromedia, then more power to them.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  70. Coldfusion = Crap[ Go to top ]

    Why are we even talking Coldfusion on this site??? I've worked at 2 Forture 500 companies RECENTLY that have used CF and it sucks. We had to rewrite the junk code into Java because of scalability and maintenance problems. Here some reasons to ignore these so called CF experts and burn your Cold Fusion documentation and disks.

    1.) It's not a standard and only two companies support it. These are by no means IBM, SUN, BEA, and Oracle...
    2.) Why would you use CF when you have backend Java code. Much easier to fully integrate with Java.
    3.) If you have Java on the backend - for goodness sake write you app in all Java and leverage you experience and talent base.
    4.) If you want a simple brochure site with limited dynamic functionality write your app in PHP - it's as powerful and free...
    5.) CF does not and will not ever scale for enterprise class systems because you have a mix of business, presentation, and data logic.

    Do yourself a favor and forget about Coldfusion, buy yourself a good J2EE book, fire your Cold Fusion resource, hire some good Java programmers, and relax because your enterprise system will work and scale if you follow today's patterns and best practices for Java development. These CF goons are just in survival mode trying to convince themselves and others CF will still be around... If they were any good they would be wanting to learn Java, C++, .NET, or some other enterprise class language. My guess is they are incapable...
  71. Coldfusion = Crap[ Go to top ]

    Well I'll be pulling your t-shirt from the mail, Thomas, that's for sure.

    And to think I've wasted all these 20 years of IT experience and the last 7 in CFML only to end up in such a dead end. And all the customers I'm serving. To think they're all idiots! Thanks for waking me from my dilerium.

    Now, back to the real world, your comments added nothing to the debate. Let's categorize this fallacy argumentum ad hominem.

    Look, you love Java. You hate CFML. Bad experiences, that's a shame. But CFML is (now) Java. And all your arguments about mixing business logic and presentation are just as easily held against poorly written apps. The bad experience was likely against the older C++ based implementation. CFMX and BlueDragon run atop J2EE. Can you really have read the entire thread and still not get all this?

    The good news is that people are getting it.
  72. Coldfusion = Crap[ Go to top ]

    Look, you love Java. You hate CFML. Bad experiences, that's a shame. But CFML is (now) Java. And all your arguments about mixing business logic and presentation are just as easily held against poorly written apps.

    Of course, I meant to say "poorly written JSP apps".
  73. I would now like to debunk the notion that, even as a mere tag library, cfml is a spectacularly poorly designed technology.

    One example:

    <cfif [expression]>
     This gets shown if expression is "true" although "yes" works fine, and of course there are no types or classes so the notion of a boolean is just a bag of case insensitive string expressions.
    <cfelse>
     This gets shown if expression is "false", or "no" or "1" or 1.
    </cfif>

    The above three tags are not valid xml. You can't just add the trailing slash to <cfelse/> because it isn't modelling the containment of the two conditions. It may be valid xml if you did, but it would still be stupid because <cfelse/> is not used like a real unary tag, it is actually containing the text between it and the </cfif>.

    See some of the cf community commenting on whether you bother to add trailing slashes for unary tags.

    http://www.markme.com/mtadmin/mt-comments.cgi?entry_id=2540

    Not being valid XML is really bad for a "just another tag library for j2ee". I've sucessfully used XSLT to generate JSP and the result can be easily checked for XML compliance. It's a great way to catch problems in your tag soup. With CFML all the "easy to use" automatic coercion in cold fusion can hide the fact that you've missed a doublequote or something and you may only see the disaster in some browsers.

    So if the [expression] above is a variable that has a "boolean" value and you write the above <cfif> tag with it in, then again, you're not writing XML. Remind me again, why am I typing all the angle-brackets?

    Also If cold fusion is really just another tag library for doing well-designed web apps on J2EE then <CFQUERY> has no possible use. No well-designed web apps mix SQL with HTML. Charles, you could blame the programmer for using the built-in dangerous language constructs - you can blame the programmers for everything - but then all of the RAD advantage of CFML comes from quick and dirty "big ball of mud" architectures ( http://www.laputan.org/mud/mud.html ).

    If you were doing things properly, just what exactly would CFML give me? Headaches:

    The keys in cold fusion associative arrays are not only case insensitive strings, but if you get the list of keys it returns them all in uppercase. That's just plain rude.

    There are dozens of languages I like - not just Java, but CFML is one of the worst technologies I've seen ever. I'd even rather write VB!
  74. This discussion will never end... But is very nice to see so much worry from the many specialists and "gods of Java" here...

    ColdFusion is typeless and I love it. I also love all the other "craps" mentioned here. It makes me spent more time planning the application, living and enjoying life than endless coding sessions. Maybe CFML is not a better language for a super-advanced/critical-mission bank system, super-huge high-traffic websites/applications and so many others. But it's definitively perfect for what it was originally created: RAD web applications. And now, I can mix the "super-high-extreme" powerfull of Java with my poorly and crappy applications maded in CFML. I can also run those crappy things over a super-max-hyper IBM Websphere server and integrate it with those designer's idiot and fluff Flash interfaces, just as the one we have in the horrible and user-unfriendly website from Macromedia - http://www.macromedia.com and many others that are emerging in the web recently. Yes... you're damn right... Why facilitate and create alternatives when you can difficult things? Let's spent months to do something that can be easly done in weeks, let's drive a war-tank (scalable, super-robust and unbreakable) to go to the mall... (oh, I forgot: we all work in places that super-extreme-mega escalability is necessary), there's no place for the "weak" ones...

    That being said, what's the reason to criticize CFML that much? Why people insist to compare CFML with Java when they are totally different things? If CF doen't work for you, don't use it. Simple that. I can google and post A LOT OF IDIOT and unfudable stuff regarding JSP, and even Java. Criticism is everywhere, and nobody/nothing is immunized, including CFML (specially when is an alternative for JSP)... Again: use what is better for you. I can say that ColdFusion have it's own space and market share and the future horizon is very interesting for this technology.

    Just to mention an argument that criticism is everywhere and it's the esiest thing to find over the web (including this thread):

    http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm

    Why Yahoo! picked PHP instead of Java?? Why some big companies choose one or other technology? Why Boeing use CF massively? Why Bank of America does the same? Why a small and inexpressive website that sells nuts and stupid things use it too and others use a pre-fabricated ASP script? Its a matter of choice and I choose CFML for many times because it's very good in what it do. The rest is pure radicalism, and radicalism is also easy, earn money not.

    I'm sure this is not the place to share successful histories with ColdFusion, but I'm sure we're plenty of similar and sucessuful cases, just look around (and not to past)... It's sad to see so much anger and flaming. Come-on, we all believe Java is a very nice thing and we support it, althought I can ran my crappy CFML over .Net too (who knows the future?).

    Of course, this is my personal opinion and as a ColdFusion developer I'm "above" you guys from the pure Java paradise... Sorry for that.

    Abraços,
    Alex
  75. including jsps in cfml[ Go to top ]

    hi you experts,

    @ macromedia.com nobody could help me.

    probably there is somebody here that can help me:

    i have a big coldfusion application and i try to integrate some jsp pages in this application.

    everything works well on jrun with coldfusion 4 j2ee exept one thing:

    i do include a jsp file in an cfm file with getPageContext().include(blabla)

    the include works well but after the include i want to make a cold fusion 'redirect' witch cflocation. probably this sounds strange but...

    the cflocation-redirect does not work and i think the problem is, that the jsp-output is directly sent to the client... so i cannot send any other http-header instructions...

    has anybody found a workaround or is there a possibility to set no flush for included jsp files?

    i know... i'm italian... and italians don't speak english ;-)

    ciao & grazie
  76. CFML == Custom tag library[ Go to top ]

    Having experience with both CFML and Java/JSP, I can offer some insight for those java developers unfamiliar with CFML.

    From a java perspective, the Cold Fusion MX implementation of CFML is nothing more than an extensive (and expensive) JSP custom tag library. Macromedia doesn't want to admit it, but it's the truth. Having said that, it is probably the most feature and functionality rich tag library available, and there're tons of supporting classes that ease everything from issuing SQL queries to sending emails.

    Since CFML in this context is just a JSP custom tag library, by extension CFML templates are simply JSPs. They go through a similar life cycle to JSPs, except that there's an additional step:

    CFML templates --> JSPs --> servlet source --> servlet classes

    From a strict MVC perspective, this means that all logic ends up in the view. Cold Fusion Components, or CFCs, aren't components at all; rather they are HashMaps/ArrayLists that reference script classes that behave like methods.

    Way back in the "Before Time", prior to the Allaire purchase of Live Software, Live shipped with JRun a servlet called CFAnywhere which enabled JRun to execute CF templates with most of the commonly used CFML tags. A cynic might suggest that the Live acquisition was fueled in part by the existence of CFAnywhere, which promptly disappeared from the JRun product.

    The thing I find most uncomfortable about using CFML is the vendor lock-in, even with the availability of BlueDragon. Even though I use vendor tools and products, I resist using any vendor-specific libraries. What would be cool is a freely available, open source implementation of the CFML language, even a subset of it, like what's available with Cold Fusion Express.

    J
  77. CFML == Custom tag library[ Go to top ]

    What would be cool is a freely available, open source implementation of the CFML language, even a subset of it, like what's available with Cold Fusion Express.

    John, I have good news for you. You can get a free implementation of the CFML language. It's not open source, for the reasons I described above. I was writing the note about the TagServlet/TagFusion history when you posted your note. Just saw it now.

    Anyway, we (New Atlanta) do offer a free version, but it's much more powerful than Allaire's old CF Express from the CF 4.5 timeframe. It held back a tremendous number of tags. We hold back only a few. I wrote about it in a blog entry of July 1, FAQ: "I've heard BlueDragon has a version free for deployment. Is that true?".

    Yep, that's free for deployment, not just for testing. (All our BlueDragon versions are available free for testing and development.) We do want to make it easy for folks to use CFML without having to pay for it. We even offer support with it (on our public mailing list, or through separately purchased direct support).

    You had also written:
    From a strict MVC perspective, this means that all logic ends up in the view.

    Again, I'll argue that that's not about the language but about the developor's coding practices.

    And you wrote:
    Cold Fusion Components, or CFCs, aren't components at all; rather they are HashMaps/ArrayLists that reference script classes that behave like methods.

    I'll just add BlueDragon doesn't currently support components. We, too, see them as a little half-baked for some of their use cases. The next version of CFMX, called RedSky, is due to change them quite a bit, especially their ability to work as true objects. We're waiting to see how that turns out.

    Finally, I have to say that I thought I recognized your name. I did a search here on TSS and found this note from you of Oct 24, 2001:

    <snip>Having said all this, I think it's a cool idea: the ease of development of CF with the performance and scalibility of Java application servers. It's about time...

    That was true then, and it's true now. You also mentioned hope in that message about being able to deploy CF as a WAR file. You can, and with BlueDragon/J2EE you can deploy both the CFML runtime and your app as a webapp. We really are trying to solve the important problems of integration of CFML and J2EE.

    I wish folks would let go of their tired debates about whether CFML makes sense. The bottom line, as has been repeated by many others here, is that for many shops it does. And whether they choose ultimately to move to pure JSP/servlets/etc., the fact that our solutions enable them to do that at a more controlled and practical pace is not insignificant--to them.
  78. to the experts[ Go to top ]

    hi you experts,

    @ macromedia.com nobody could help me.

    probably there is somebody here that can help me:

    i have a big coldfusion application and i try to integrate some jsp pages in this application.

    everything works well on jrun with coldfusion 4 j2ee exept one thing:

    i do include a jsp file in an cfm file with getPageContext().include(blabla)

    the include works well but after the include i want to make a cold fusion 'redirect' witch cflocation. probably this sounds strange but...

    the cflocation-redirect does not work and i think the problem is, that the jsp-output is directly sent to the client... so i cannot send any other http-header instructions...

    has anybody found a workaround or is there a possibility to set no flush for included jsp files?

    i know... i'm italian... and italians don't speak english ;-)

    ciao & grazie