I am really late to this thread -- been doin' other interesting stuff. There are one (or two, or forty) reasons that have not been mentioned, that make inline Java code a benefit.
1) Where needed in an app, you can get strong typing and nulls -- say you want to communicate with a JDBC driver and retrieve Table/Column attributes from a db -- most JDBC drivers provide this info, but you can't get at it directly form CMFX. 2) Where CFMX can act as a gentle introduction to Java -- certainly this hybrid code would not be the best, but it would allow Java neophytes, like myself, to learn Java gracefully, without having to learn all the rules first. -- There is something about the fact that we can learn our native language, better, by the age of 5, than a person with 4 years of college courses on that language -- simple introduction, constant use, familiarity-- a lot of us "Learn by Doing!" 3) This would put /keep CF at the head of the pack -- one more significant reason to choose CF over the competition -- EasyJava -- choose the language/implementation that makes the most sense for an application and/or a tier. Dick P.S. while I am asking for things, I'd like to see a <cfo>...</cfo> tag -- does the same thing (and does not deprecate the <cfoutput> tag-- just a lot easier to type (and pretty self-documenting, and makes a lot more sense than that <%= crap!) On Friday, November 22, 2002, at 08:56 AM, Rob Rohan wrote: > I understand your decision but I have a couple more things to add, > then I'll > shut up. > > 1) To me CFSCRIPT is to Cold Fusion 5 what CFJAVA would've been to > CFMX. > > 2) I also don't think people would just use a cfjava block to just use > it. > There would have to be a need. (I.E. a custom java tag that doesn't > need to > be installed) > > 3) I would like to play with inner classes / threads on a page and > casting > to thing (like a CF list to a hashtable - don't even know if that would > work, but you get the idea). > > 4) There could be performance gains beyond code execution. For > example, when > you make a cfm page into a class it adds a bunch of \r\t which is > necessary > in almost all cases (but certain blocks could be controlled) > > Thanks for listening Phil and all you wacky MM guys > > Rob > > Certified Organic > "When you put things in quotes, people think someone actually said it." > http://treebeard.sourceforge.net > http://ruinworld.sourceforge.net > Scientia Est Potentia > > -----Original Message----- > From: Phil Costa [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 22, 2002 6:09 AM > To: CF-Talk > Subject: RE: Java in CF (CFMX) > > > The decision to disallow inline java code was definitely not a cut and > dry > one. One reason was definitely to enforce a cleaner separation of > syntax; > the other, which I hadn't mentioned, was to remove some additional > complexity from the parsing/compiling process. Because of the > differences > between typing and syntax, parsing a page that had both Java and > CFML/CFScript would have been a bear. > > Phil > > -----Original Message----- > From: Jon Hall [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 22, 2002 2:37 AM > To: CF-Talk > Subject: Re: Java in CF (CFMX) > > > 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 > MT> be "dangerous" in a number of ways... > > MT> It's very easy to run into errors in java if you don't understand > MT> how it all works (ex. trying to instantiate an interface). One of > MT> the overriding strengths of CF is that it offers a great deal of > MT> power in an easy to use/learn style. This sort of thing, IMO, goes > MT> 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 > MT> will keep things nice and neat, but others will be mashing CFML, > MT> CFScript, Java, and SQL together haphazardly. > > MT> Then there's the compatibility thing... Java lists != CF lists. > MT> Java arrays != CF arrays. Etc. Again, this can lead to confusion > MT> and cause all kinds 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, > MT> 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 Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm
