I think someone at MM should look up BSF. Rob
http://treebeard.sourceforge.net http://ruinworld.sourceforge.net Scientia Est Potentia -----Original Message----- From: Jeffrey Polaski [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 26, 2002 10:50 AM To: CF-Talk Subject: RE: Java in CF (CFMX) Personally, I'd like to see CF Script expanded to deal with strongly typed code. It would be extremely cool to be able to run code from a different languages in a cfscript block (kinda' like MS's Scripting Host). I can see a couple of other benefits to having inline Java code: Stronger types for variables. (well, stronger types for /values/). Sometimes it's extremely useful to have strong types. For example, I worked on using native COM datasets in CF a few years back and we had a lot of problems converting the native COM dataset into a CF query. was a huge performance hit for a CF script to loop over each field, convert it, and stuff it in a CF query. If CF could (optionally) deal with different types I think it would have been a lot easier to do, and a cfscript block would be a great place for this. Also, it would be *great* to be able to pass functions around as values--that alone would certainly simplify my code in places. One of CF's great benefits is it's simplicity, but sometimes it's important to be able to get out of the simple tag-based techniques of CF and into more "advanced" techniques. When I'm developing, sometimes I want to be able to just dump some code on a page and thrash away. It gets in the way to have to develop separate components. After I'm done thrashing out some code, I want to make sure it's clean and maintainable, and put it into components, though. It's just nice to have the option. I know basically nothing about the actual behind-the-scenes architecture of CF, so take this with a grain of salt, but I don't see why CF couldn't just automatically compile a cfscript block as a separate class if you added a keyword to it, like: <cfscript language="java">. There is already a lot of code generation going on when CF creates the class files from a CF page. Well, just my $0.02... Jeff Polaski "The cow is of the bovine ilk; One end is moo, the other, milk." -- Ogden Nash -----Original Message----- From: Dick Applebaum [mailto:[EMAIL PROTECTED]] Sent: Saturday, November 23, 2002 9:30 PM To: CF-Talk Subject: Re: Java in CF (CFMX) 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 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
