Thursday, November 21, 2002, 11:54:58 PM, you wrote: MT> Jon Hall wrote: >> The case for allowing inline Java is simple, CF developers can use >> Java without having to know everything about Java. Methods and classes >> are easy to get. Compiling, classpath's, and understanding the lengths >> Java goes to, to abstract everything, etc. is not.
MT> Knowing just a little about a language as deep/complex as Java can be MT> "dangerous" in a number of ways... MT> It's very easy to run into errors in java if you don't understand how it all MT> works (ex. trying to instantiate an interface). One of the overriding MT> strengths of CF is that it offers a great deal of power in an easy to MT> use/learn style. This sort of thing, IMO, goes against that strength. MT> Mixing CFML and Java can very quickly lead to code that is horribly MT> organized and difficult to follow/maintain. Obviously, anal coders will MT> keep things nice and neat, but others will be mashing CFML, CFScript, Java, MT> and SQL together haphazardly. MT> Then there's the compatibility thing... Java lists != CF lists. Java arrays MT> != CF arrays. Etc. Again, this can lead to confusion and cause all kinds MT> of errors. I say let the coders (and the pm's who have a clue <g>) who write the applications make the decision on what works in their application. I'm not trying to be facetious, but be brutally honest, I couldn't care less that anyone else thinks my hypothetical hybrid Java/CF code is unorganized or difficult to maintain, as long as those that it matters to, like my boss and clients don't care either. So I don't see how the fear of some overwhelming horde of organized code existing somewhere out there, just over the horizon, really is a valid argument against allowing inline Java within CF templates. >> CFQuery is the perfect example here. If CF gives developers the power >> to do whatever they want within cfquery tags, then why not java within >> cfjava tags? Seems's inconsistent to me. Especially since cfquery >> probably the biggest strength of the CF language. MT> SQL and CFML serve 2 different purposes, database manipulation and MT> application logic. Java and CFML serve the same purpose, application logic. That's not entirely true. TSQL and probably PLSQL work fine within cfquery tags. Terrible as it may sound, if I want to loop over a cfquery that manipulates a cursor I can. I'm not saying there are not valid reasons for disallowing inline Java, I'm just saying that limiting the flexibility of CF just because of the possibility that nasty code may come into existence is not a good enough reason in my opinion, but it's the only one that's been put forward by both you and Phil. I also don't want to start yet another debate about what's good and bad for CF, but as you said earlier, I am curious as well. Though I suspect it's similar reasoning behind not allowing cfscript to call tags in the past (not that I ever got the reasoning behind that either). -- jon mailto:[EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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
