Java Forum / General / February 2006
Potential new recruit to Java. Could I/Should I use Java?
petermichaux@yahoo.com - 16 Feb 2006 04:02 GMT Hi,
I'm writing a new ecommerce web application using Ruby on Rails. I'm working on the back end and am thinking about different ways to do it. So many choices. First, I prototyped the standard thing: HTML forms based backend/admin. Second, I tried a cool Rails based AJAX drag/drop interface. This is fun but then I realized that the more I moved in the AJAX direction the more I was was building a javascript application, just asking the server for some data and only infrequently asking for a page layout or complete refresh. Now I'm thinking of a third option
I haven't used Java before but I was just reading about JWS applications. Since there are very few people using the admin side of an ecommerce application, could I build a JWS app that interacts with the server in a way that is similar to AJAX? Sending and recieving data? Would this be a wise choice?
I suppose this could restrict the computer the store admin uses to admin their store. If they were on holidays they might not be able to check on their orders from an internet cafe. This is a potential drawback?
Thanks, Peter
David N. Welton - 16 Feb 2006 08:27 GMT > Hi, > > I'm writing a new ecommerce web application using Ruby on Rails. Rails is a pretty nice environment to be working with. In the spirit of "agile development" (whatever that is, exactly), I would build the app, and then iterate over improvements to it rather than worry about building some fancy admin interface with a GUI tool...
Worry about that when you know what your actual needs are for managing the thing.
At that point, Java is certainly an option for doing a GUI, as are things like Tcl/Tk, or stuff like VB if you're a microsoft kind of guy (I'm not!).
 Signature David N. Welton - http://www.dedasys.com/davidw/
Linux, Open Source Consulting - http://www.dedasys.com/
petermichaux@yahoo.com - 16 Feb 2006 16:10 GMT Hi David,
> I would build the app, and then iterate over improvements to it rather than worry about building some fancy admin interface with a GUI tool... That's what I started doing with the forms based admin interface. Then I realized that the admin side of things will be huge. Way more than 1000 times the code as the store front. So then I thought maybe it is a good idea to play with the first part of the admin using a few different tools to see what would be the best and most modern feeling. I don't want to write a huge admin program and then have to rewrite it immediately. I don't know that using Java would be better than using JavaScript. That's what I'm trying to learn about now. Accessability and limitations.
Any other thoughts? Other people probably incounter this same situation.
Thanks, Peter
Chris Uppal - 17 Feb 2006 13:28 GMT > [...] > I realized that the admin side of things will be huge. Way more than > 1000 times the code as the store front. Assuming your store front code is not totally trivial, it sounds to me as if you have a much bigger problem than can be solved by just your choice of implementation language. Even if language+technology X is ten times more expressive than language+technology Y, the choice of X over Y will not bring your application within the range of the feasible.
There is also the issue that the UI (however implemented) will be mammoth and may easily become unnavigable.
I should start by designing how the thing will work on the assumption that just about everything has to be generated automatically, and see what kind of user interface and application architecture you can come up with. /Then/ choose an implementation technology.
-- chris
John C. Bollinger - 17 Feb 2006 04:51 GMT > I haven't used Java before but I was just reading about JWS > applications. Since there are very few people using the admin side of > an ecommerce application, could I build a JWS app that interacts with > the server in a way that is similar to AJAX? Sending and recieving > data? Would this be a wise choice? A JWS client could certainly interact with the backend server according to much the same pattern that an AJAX application would use. Indeed, that's a natural paradigm for a Java application, whether launched via JWS or otherwise. Because with JWS you get to build a full-blown Java application, you have an enormous amount of power and flexibility in your client; one cost, as you already observed, is that a JWS application is not as broadly accessible as an AJAX application.
Would JWS be a wise choice? If I were in your place, I would be giving it serious consideration. You are not me, however. I think it's crazy for a Java neophyte to jump in at the beginning with an enormous application of any sort, and I think it's stark raving mad if that application is heavy on GUI. No amount of prior experience with other languages on your part affects my opinion significantly, especially if you have much in the way of time constraints on project completion.
I think Java's a great language. I like it enough to urge you to not set yourself up for frustration in your first experience with it.
 Signature John Bollinger jobollin@indiana.edu
Roedy Green - 17 Feb 2006 05:28 GMT On Thu, 16 Feb 2006 23:51:47 -0500, "John C. Bollinger" <jobollin@indiana.edu> wrote, quoted or indirectly quoted someone who said :
> as you already observed, is that a JWS >application is not as broadly accessible as an AJAX application. AJAX depends on a recent JavaScript being installed and working. JAWS depends on a recent Java being installed and working.
It is a matter of short term vs long term pain.
AJAX has the advantage that JavaScript comes pre-installed and pre-loaded. However, every browser has its own incompatible version with different bugs to dodge. You can't easily replace the JavaScript without replacing the whole browser.
Java on the other does not usually come preinstalled, thank you Mr. Gates for running interference.
However, you CAN through a fairly simple process upgrade the user to a standard, relatively bug free Java without changing his browser.
The other advantage of Java is it works on non-Windows platforms as well. JavaScript in practice limits you to Windows and the Internet Explorer dialect.
I think people who use Ajax will rue the day. IE is the most insecure browser and JavaScript the most insecure way of doing client side. It is only a matter of time until an big 9/11-impact security scare bans both from the corporate world PCs.
 Signature Canadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching.
Dag Sunde - 17 Feb 2006 07:36 GMT > On Thu, 16 Feb 2006 23:51:47 -0500, "John C. Bollinger" > <jobollin@indiana.edu> wrote, quoted or indirectly quoted someone who [quoted text clipped - 22 lines] > well. JavaScript in practice limits you to Windows and the Internet > Explorer dialect. Now you confuse me, Roedy!
Granted, it was MS that introduced the XMLHTTP object, but it has been implemented by *all* the other major browsers. FF, Opera & Netscape
In fact, on two of my largest web-apps that relies heavily on AJAX/ XMLHTTP, I do all my work and testing with Firefox 1.5.
> I think people who use Ajax will rue the day. IE is the most > insecure browser and JavaScript the most insecure way of doing client > side. It is only a matter of time until an big 9/11-impact security > scare bans both from the corporate world PCs. Lets hope ;-), but it won't influence AJAX/XMLHTTP, since that is now a solid cross-browser technology.
 Signature Dag.
Roedy Green - 17 Feb 2006 08:04 GMT >Granted, it was MS that introduced the XMLHTTP object, but it has been >implemented by *all* the other major browsers. FF, Opera & Netscape but it does not work. It as the stage Java 0.9 was.
 Signature Canadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching.
Dag Sunde - 17 Feb 2006 10:24 GMT >>Granted, it was MS that introduced the XMLHTTP object, but it has been >>implemented by *all* the other major browsers. FF, Opera & Netscape > > but it does not work. It as the stage Java 0.9 was. What do you mean "it does not work"?
My experience is that it works wery well... Cross browser, cross platform...
(Well, you can never trust a Mac user, though...) ;-)
 Signature Dag.
Roedy Green - 17 Feb 2006 10:48 GMT >What do you mean "it does not work"? I use Opera. Perhaps 25 % of sites that use JavaScript don't render it properly. Firefox throws up its hands and says "use IE rendering engine".
It is Mickey Mouse to the core. It is for porn sites and kiddie entertainments, not serious business sites.
drop in on comp.infosystems.www.authoring.stylesheets and listen to the screaming about how it almost impossible to make things work on all browsers with combinations of CSS and JavaScript.. You spend far more time on incompatibilities than you do on the code itself.
 Signature Canadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching.
Dag Sunde - 17 Feb 2006 11:17 GMT >>What do you mean "it does not work"? > > I use Opera. Perhaps 25 % of sites that use JavaScript don't render > it properly. Firefox throws up its hands and says "use IE rendering > engine". The difference between amateurs and professionals, I'm afraid.
> It is Mickey Mouse to the core. It is for porn sites and kiddie > entertainments, not serious business sites. (Ooops... Don't tell all the power grid operators and powerplants in Norway about that... I might get in trouble) ;-)
Wrong, disagree, not at all, nope, no way!
:-D
> drop in on comp.infosystems.www.authoring.stylesheets and listen to > the screaming about how it almost impossible to make things work on > all browsers with combinations of CSS and JavaScript.. You spend far > more time on incompatibilities than you do on the code itself. Oh I know! I combine CSS, Javascript, Java and serverside for a living.
There's only one way to go: Testing, testing and testing... ...and did I mention testing?
;-)
 Signature Dag.
Chris Smith - 17 Feb 2006 15:05 GMT > [JavaScript] is Mickey Mouse to the core. It is for porn sites and > kiddie entertainments, not serious business sites. Roedy, I think you've acquired a prejudice here that is not justified. The truth of the matter is that JavaScript is one of the most widely available general-purpose programming languages that is available on all PCs, and it works pretty reliably over nearly all of them. There are certainly improvements that can be made, but JavaScript is used in a wide variety of business environments. It works very well, and is in fact the only technology that can do some of the things it does. I certainly wouldn't use ANYTHING else for core uses, such as client-side validation of web forms. It's also very convenient to use "AJAX" (I hate that pretentious word, though) technologies when a web application needs the occasional more-interactive bit. The AJAX part is a bit newer, of course, but I find little challenge in being sure it works.
> drop in on comp.infosystems.www.authoring.stylesheets and listen to > the screaming about how it almost impossible to make things work on > all browsers with combinations of CSS and JavaScript.. Many complex uses of CSS and JavaScript do, indeed, break in many browsers. Of course, AJAX has absolutely nothing to do with CSS in JavaScript. AJAX is about server-side communication, and is more likely to result in changing the text of a node (which works reliably pretty much anywhere) than changing its font styles.
 Signature www.designacourse.com The Easiest Way To Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation
Roedy Green - 18 Feb 2006 22:17 GMT >Roedy, I think you've acquired a prejudice here that is not justified. Prejudice means deciding before you have used it.
Granted I have not used it extensively, but every time I have gone to use it for even the simplest things, it proved itself crap.
Javascript is building your foundations on sand.
But you are right, I also dislike it for the same reason many people hate HTML, because of how the tool is often used to deliberately annoy.
Until it gets a sandbox as serious as Java's, I will keep it turned off.
 Signature Canadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching.
David N. Welton - 17 Feb 2006 08:08 GMT >>as you already observed, is that a JWS >>application is not as broadly accessible as an AJAX application.
> AJAX depends on a recent JavaScript being installed and working. > JAWS depends on a recent Java being installed and working.
> It is a matter of short term vs long term pain.
> AJAX has the advantage that JavaScript comes pre-installed and > pre-loaded. However, every browser has its own incompatible version > with different bugs to dodge. You can't easily replace the JavaScript > without replacing the whole browser. The good Ajax systems are basically libraries that ship with code to deal with these incompatibilities, from what I understand. And well done sites also provide the same functionality for people who plain don't have Javascript enabled browsers.
> Java on the other does not usually come preinstalled, thank you Mr. > Gates for running interference. [quoted text clipped - 5 lines] > well. JavaScript in practice limits you to Windows and the Internet > Explorer dialect. Au contraire! Javascript ships with Firefox, which, being open source software, is available for more platforms than Sun's version of Java. (Think of the matrix between OS's like Linux and the BSD's and the hardware they run on, such as PowerPC, ARM, MIPS, and so on - certainly, we're talking about insignificant market share, but, still...)
> I think people who use Ajax will rue the day. IE is the most > insecure browser and JavaScript the most insecure way of doing client > side. It is only a matter of time until an big 9/11-impact security > scare bans both from the corporate world PCs. There are plenty of good reasons to not use Ajax, but I don't think you are being fair here.
 Signature David N. Welton - http://www.dedasys.com/davidw/
Linux, Open Source Consulting - http://www.dedasys.com/
petermichaux@yahoo.com - 17 Feb 2006 18:06 GMT > Javascript ships with Firefox, which, being open source > software, is available for more platforms than Sun's version of Java. > (Think of the matrix between OS's like Linux and the BSD's and the > hardware they run on, such as PowerPC, ARM, MIPS, and so on - certainly, > we're talking about insignificant market share, but, still...) For which platforms is Sun's Java available? (Probably all the ones I want but I'm curious. Maybe a Sun web link?)
What are the system requirements to use a JWS app? I imagine the user must have some disk write permissions.
If I make a JWS app will I or the user or anyone involved have to pay anything to Sun?
Thanks, Peter
Daniel Dyer - 17 Feb 2006 19:55 GMT >> Javascript ships with Firefox, which, being open source >> software, is available for more platforms than Sun's version of Java. [quoted text clipped - 4 lines] > For which platforms is Sun's Java available? (Probably all the ones I > want but I'm curious. Maybe a Sun web link?) All you have to do is go to the download page and find out for yourself.
Sun provides versions for Windows, x86 Linux, x86 Solaris and Sparc Solaris. All of these are available for both 32-bit and 64-bit hardware.
IBM and Apple also provide Java implementations for their platforms, based on technology licensed from Sun. That adds AIX, z/OS, PowerPC Linux and Mac OS X to the list. You can get Java for Sparc Linux from Blackdown.org. BEA have some decent VMs, but only for x86 platforms.
There are also clean-room Java implementations that are nothing to do with Sun, such as Kaffe for Linux and BSD.
Dan.
 Signature Daniel Dyer http://www.dandyer.co.uk
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|