>>You seem to have answered your own question. It wasn't my question. :) Bob
>>> [EMAIL PROTECTED] 4/22/2005 12:55:35 PM >>> >Let me state upfront that my primary background is in java so I'll admit >to some bias... :) We all have our favorite tools. >I'm impressed with ColdFusion's ability to get sites up and running >quickly and the ease with which one can learn the language. However, I'm >not as convinced with its ability to perform complex business logic and >integrate with other systems. Complex business logic can be modelled in any language, it's just a matter of how much work it takes. >While I like the concept of CFCs and think >it's a great addition they lack of some OO capabilities (polymorphism, >overloading methods, etc) that limit what you can do with them. >ColdFusion, for all intensive purposes, is a procedural language. It is a procedural language, but I would differ with you in this respect. The lack of certain OO capabilities doesn't limit what you can do, it just affects how you do it. In some cases, it makes a CF-based solution more trouble than it's worth. >Bolting on some OO capabilities is nice, but I doubt it'll ever be a >true OO language, and many people, myself included, don't want it to be. >I think it'd add complexity to the point where CF becomes as complex to >write as java. Absolutely. It offers enough OO features to make OO-style frameworks like Mach-II possible while stilling offering the simplicity of pure procedural design for beginners. >Now, I won't say it makes sense for all applications for the business >logic to exist in java and the view to exist in CF. It adds additional >complexity that in many cases just won't be worth it. Java is a beast >that takes quite a bit of time to learn and truly understand, let alone >write decent code. In addition, the integration between java and CF >isn't perfect. Going from a non-typed language to a strongly typed >language will always lead to some compatibility issues. I personally >hate the fact that CF doesn't support the concept of "null". That alone >has caused considerable grief when integrating java apps. Basically we >have to implement ugly workarounds. You seem to have answered your own question. Personally, I don't want to drop down into Java just for the hell of it. I do it when I can't accomplish what I want in CF, or when the CF-based solution would be more painful than the Java-based solution. Your example of not supporting "null" is perfect. In that case, I would write wrapper class(es) in Java to provide the integration hook I needed, and I would access the wrapper class(es) from CF. If you have an application that makes very heavy use of such external integrations, it might make sense to write the entire model in Java, or maybe to build an integration component factory in Java that handles just the integrations. But I wouldn't do that unless there was some concrete benefit to it. Don't look at it as just a technical problem. Consider the business costs and and benefits as well. Tha may help point you in the right direction. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:204263 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
