I realise that Barry has asked me to respond to a "different" question (and I was having trouble starting a reply realising that it is really for a different thread - and possibly even a different list).
But I can definitely respond on topic to Robin's reply. Firstly, I will clarify that I don't think Coldfusion is "dead" - the topic just seems to be a good place to tell our story briefly. Coldufusion continues to be a rock-solid enterprise product. 1. Good Devs - definitely - hard to find everywhere (including Java). You will even see simple Senior Java Devs getting over $150K per year for perm positions. But there are still more Java developers than there are good CFMX (I am talking those with solid OO and CFC experience). 2. A quality developer will be able to pick up most languages if they have a good grounding in development. This is something that I have always ensured existed in our developers. Some may even remember a number of years ago several heated discussions on CFAUSSIE in this regard. I stick by my previous views on this because it has born out to show the approach valid in our current transition. 3. This is my bit and may help to address some of Barry's questions...... CF for us has been "middleware" for a while. And the RAD aspect of it has not been important. In fact, it probably never was important. Prior to my joining the company, the website and all development was outsourced. So AAM were not tinkering - even though the development company may have been. While we still use HTML for our website - our internal applications are running AJAX-based front ends (CF is not generating HTML). Data and Business Layer access is via a remote call to a single request broker which translates the request directly into a method call on a Coldfusion component. All backend logic is written in CFC's and, within those CFC's, the methods are (mostly) all written using CFSCRIPT (not tag based). All data access is localised to specific DAO CFC's. It is a true n-tier architecture. I needed to set the stage (as we know it) before I could start to respond to Barry. So, in regard to Barry's question about a comparison.... We have realised that we just dont need Coldfusion in the middle layer because it not as rigorous as we could implement in Java and it is only a layer over the top of Java. In essence, it is getting in the way of us leveraging the benefits of the underlying platform it is built on. In other words, it is redundant. Of course, we still have a website - but see that moving to Java directly internal requires us to move that way on the website. Our website (as many would know) is built on the FarCry CMS (which for some time AAM had a strong role in helping develop). FarCry is a good CFMX CMS system. However, we wish to move away from a database-driven CMS and move to a more traditional website design (where the static pages are really static - which is the case for our website - and we only use dynamic pages for true data-based access - i.e. not for "content"). We will still be using templates on our website. We intend to use FreeMarker for that (instead of JSP). We may even also mix in Velocity templates. The Spring Framework (compare to the CF port/work-alike - ColdSpring) allows us to mix and match any MVC components within the same website. And we can use JSP if we want (even inside/with FreeMarker). You get the picture - greater flexibility. All of these products have similar variable replacement to CF - just a different syntax - and FreeMarker has a more extensible model than CFMX's templating. However, in variance to Robin's statement, we have LOTS of new development. More projects than we have ever had in the past. In addressing that, we are looking more at large component pieces (like Document Composition, Reporting, Portfolio Modelling) and developing integration pieces to hook these together. A lot of the tools we want to use are Java-based and/or will benefit from high-performance integration. As Robin would be aware - we have been "framework" focussed for quite a while and our developer base is quite disciplined. So we are well covered in this regard. As far as Scorpio is concerned. We were invited to take part in the beta program but I declined (given our direction change). So, I can't comment if the "interfaces" in their would meet our expectation. But I can say "a little too late". I have been asking for this (and other optional features) for many years only be told "not planned, use Java instead". Hearing the message. 4. [NOTE: I know this was not aimed at AAM - just adding to our story] Again, as Robin would be aware, our company has spent a great deal of our development dollars paying for CF licenses (in fact, I seem to remember that I bought my own personal CFMX license from Rocketboots and may have been the first license sale for them - or close to it). Robin is right. If you are spending lots of money (and we do) on development $1600 for CF is good. It does get expensive, though, when you are pushing out 10 servers all on full Enterprise (which we DID pay for with CFMX 7 - but have never used). And, with those dollars, there are LOTS of very cool development sub-systems you can buy in the Java world - which comes back to my TCO response earlier. Bottom line, I can spend the money I would need to maintain my CFMX Enterprise licenses on really good Java tools, libraries, extensions - and still have plenty of change for some lunches for the team. Or better still, better staff bonuses!! So - to echo Robin - Java development is not for everyone but it is really where we should have been all along. Regards, Gary [Barry - if this still left you wondering - I am happy to go into greater detail off list - just not sure all the elements of our direction would be CFAUSSIE relevant - things like minimalisation, performance, scalability, much richer set of development tools, the language of the Eclipse platform, much wider community developments, rigor - a bit aspect, better philosophical match, etc. all play a big part] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
