Jim, lots of interesting points. We absolutely agree that many shops are still at 4.5 (if 5), and they may be facing (as you) a "move" to J2EE. Are you sure that you have no hope of preserving your CFML apps on the "pure WebSphere" standard? You can, with either CFMX for J2EE or BlueDragon/J2EE. Many CF developers are still unclear about the distinction of how those products work.
In case any readers are, the point with them is that you can say to the managers or IT guys, "no problem. We're prepared for the move to WebSphere/WebLogic/SunOne. etc. Our CFML code will run atop it as a standard J2EE web application, rather than as a separate service." As I've said in a previous note, there is quite a difference between the degree to which BlueDragon's deployment approach is more standard, but both provide an answer to the "move to J2EE" challenge. And our BlueDragon/.NET does the same for those moving to an "all .NET" solution. As you've so eloquently restated, CFML is a language. Even .NET supports multiple languages. And JSP is evolving all the time to become more like CFML (see Vince's article in the June CFDJ on this topic). If any would argue, "yeah, but you have to pay to be able to run CFML on top of J2EE", that's true. Again, our CFML apps benefit from more than just a language but indeed a framework that many struggle to implement in other more complicated ways (based as they are on "pure java" coding). CFML abstracts that complexity from us. Indeed, while some IT folks and managers see CF as a toy, partly that's due to the old notion of Macromedia's CF as a separate service, with all the vagaries that have occurred with it in its carnations over the years. Now with two ways to run CFML on a standard J2EE server, the arguments about "CF being a toy" are diminished because it's real java! It will take time for that message to get through to everyone. Again, Vince has tried to help clarify that message in two CFDJ articles in February and April of this year. See all 3 of them at http://www.newatlanta.com/products/bluedragon/editorials.cfm. But another more substantial reason people see CF as a toy (or more accurately, CFML applications as primitive and non-scalable) is really about coding practices more than the language or the server implementation. Since so many came to CFML from no or little programming background, they fell into practices that were simple and natural, but not well-architected. In the JSP world, they call it "model 1" programming, where both the query and the processing logic and the output of HTML all take place on the same page. As anyone who's built a more substantial app (and had to maintain it) will attest, that simplistic design becomes very difficult to sustain. People are forced to trash an app because it's just easier to rewrite it than modify it, for all the spaghetti code and tight coupling of what are also referred to as "model", "view", and "controller". CFMX introduced CFC's, which are a step in the direction of gaining clearer separation of those things. But to be honest, they're not the only solution. Even careful design using CFINCLUDEs and custom tags, or just UDFs whether by CFSCRIPT or CFFUNCTIONs can help. Again, we appreciate the value of CFCs and CFFUNCTION, and now that RedSky will improve on the design, we look forward to implementing those features later this year. Of course, there's the whole notion of using them as objects. Again, RedSky has been announced to address that aspect. Still, not everyone will use CFC's for object-oriented processing. Some will not use OO at all, but can still get value from CFC's. But then others will want OO but not care for CFC's, perhaps even with RedSky's improvements. To be honest, many ask, "if you're going to use objects, why not leverage a platform that supports them natively". Naturally, the fact that we enable you to run CFML natively on J2EE and .NET means that it may very well be a better practice to help folks implement true OO processing in the native components for each platform (javabeans/EJBs/classes or .NET objects, applications, and services). Indeed, yet another benefit we'll offer with that is native integration with COM objects. Since with BlueDragon/.NET your CFML will run directly on the .NET platform (no java-com bridge as with CFMX) it propose to be an awesome platform for folks needing to leverage COM objects. I'm surprised to hear the assertion that BlueDragon could be marginalizing CFML. On the contrary, it would seem that both your arguments and ours should do the opposite by bringing issues to clearer light. The only real challenge, again as is the point of my writing here, is the confusion people have--both in and outside the CFML community. There's a lot to understand: both the distinctions between standalone server versions of CF and BD, as well as native J2EE and .NET implementations, application development practices, and more. It's a challenge that we (and I) take up wholeheartedly. As I said previously, I do think that in some quarters we're in a battle for CFML's life. We all know that it's totally unfortunate if people are left with the wrong impressions and make decisions to leave it without fully understanding all these things. We're trying to help prevent that. To the degree that confuses those who see it all simplistically, maybe it's just as well. While many can stay at that very low level of understanding for their simple applications and environments, the fact is that the web application development platform has matured and there are clearly two strong contenders, J2EE and .NET. There's no denying that. We have an excellent tool in CFML. The challenge is to help people see that as a tool that can run just fine on those platforms, and that there are tremendous integration points. Our mantra is "don't rewrite, re-deploy". With BlueDragon, you can move your CFML code to either of these platforms and then either a) let the code just run as is, b) start to increase integration with the native services of the platform, c) start integrating with native web applications, or d) decide (now without a gun to your head) whether some apps may be best rewritten as a native web application. Again, we're about giving people choices and helping them preserve their investment in CFML. It will take time for this message to become crystal clear to people. For those who need the solution, it's vitally important that they hear and understand it. For everyone else, it should give comfort knowing that another company (and such a strong and experienced one) is bringing force to bear on the problem. It's the whole reason I joined the company, and I love getting the chance to help people solve those problems. Those who know me know that this is the sort of stuff I just love to do. /charlie > -----Original Message----- > From: Jim Davis [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 14, 2003 4:20 PM > To: CF-Talk > Subject: RE: CF Compatability > > > [Just to get out of work for a minute; not as a direct response to > anybody.] > > Personally at this point I'm not sure I care about (small) > incompatibilities between CF5 and BD. > > I've been working with CF since version 1.5. Due to circumstances (my > location and the fact my company was an early adopter) I've been able to > watch ColdFusion/CFML (and its people) grow with some intimacy. > > CFML began as a handful of tags (six or seven) and with each major > version added new functionality - extending, but in some cases changing, > the language. > > Flash forward six years and we're here today discussing > incompatibilities between two CFML products. However any practical > discussion really should consider four (at least) products: > > 1) CF 4.5 is still is widespread use among larger shops. In general > enterprises are looking for a 2-5 year life cycle for products. I > honestly have yet to see a large company use anything but 4.5 > (unfortunately for use the move to .NET and "Pure" Java has killed that > for most - I personally will not be using CF at the office within a year > the new "enterprise standard" being pure WebSphere development). > > 2) CF 5.0 is, for many, the stopping point and they have no plans to > upgrade (or worse have attempted to upgrade and been forced to > downgrade). It's fast, capable, and (most importantly for some) is > still C++ and some runs their COM infrastructure components like MX > can't. > > 3) Blue Dragon is a tempting solution for many reasons. It's "almost > there" in terms of what most people do most of the time and although > still a bit rough on the edges it's cost and deployment flexibility are > very attractive. For my part it's also done more to popularize the idea > of CFML as a language-not-a-platform than anything else. > > 4) CFMX is the future, the new baby, and 400-pound gorilla all rolled > into one. The switch in platform (C++ to Java) was rough (and continues > to be rough) for many, but its development and deployment benefits are > obvious. MM is being (rightfully so) aggressive with its pricing (as > small shops are the bread and butter of CF). > > So, from my vantage, we're seeing a clear fragmentation of our support > and development market. We have large sections of our community being > left behind and a growing section taking off in a new direction. > > This can be a good or a bad thing, but the short-term results are most > likely going to be confusion and further enterprise apathy to the > product. I fear that these issues will, in that they draw lines in the > sand within the ColdFusion community, serve more to marginalize CFML > than promote it. > > > My opinion only, of course, but I feel it's an educated one. > > > Macromedia should, I feel, finally spend the time to publish an actual > specification for CFML (I think that CF has some great docs, but no > specs that I've ever seen). I feel that this will not only allow others > (like NA) to produce more compatible products but also improve the > quality of CF itself. > > A centralized, well-maintained repository of how things should work can > only be good for all involved. I'm not saying that they have to submit > it as a standard (or, like Sun, declare themselves a standards body) but > they should at least publish the geek bible. (They probably already > have this in one form or another). > > (The "extras" can be seen as vendor specific additions: CFSEARCH, > CFCHART, etc. The core language will be just that - with additional > services taking center stage.) > > I feel very strongly that they should (with this specification) version > CFML differently than CF. We should be able to understand that CFMX > supports CFML 6.0 but that RedSky supports CFML 6.1. ColdFusion 4.5sp2 > introduced new features: perhaps CF 4.5sp2 supports CFML 4.7. > > This will allow people to produce to very specific targets with > supporting products, CFML applications and alternative language engines. > I will not longer have to say "my app works in CF 5.0, CFMX and > Bluedragon." I could say "My app conforms to CFML 5.1" which implies > that. > > (And yes, I realize that the real world doesn't work quite that nicely. > But, as for more languages, it's a goal worth aiming for.) > > We should be able to track bugs as they relate to the CFML > specification. We can make definitive "should" (should act like this, > should work like this, etc) statements for HTML, CSS, JavaScript, Java, > etc. But with CF we're left with ambiguous claims of "compatibility" > simply because we can only compare implementations, not specifications. > > CF is great - I think the best web tool ever, but it's continually seen > as a marginal, proprietary product. In fact it's very often seen as a > toy. > > I think that a formalization of CFML in the shape of a true, managed > specification could help to change that image. > > > Okay... that wasted an hour. > > Jim Davis > President, http://www.depressedpress.com > Webmaster, http://www.firstnight.org > Webmaster, http://www.cfAdvocacy.org > Senior Consultant, http://www.metlife.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
