Groovlets, though a refreshing way to not have to risk getting any Java on your clothes, don't at all provide the features of Rails. They are synonymous with Java servlets, which is pretty much the bare metal request/response paradigm, accessible as an API.
The Ruby equivalent to Groovlets is WEBRick's Servlets. Rails can run on top of this, but it provides a much higher level of abstraction.
Change aversion compounds on itself. People avoid new things that replace their old things, because they fear change. The more they do this, the more risky and costly it is to change. The fear grows. Why else would such a large percentage of desktops be running Windows when MacOS, BeOS, Linux, *BSD, etc. have been around to provide something that is in many cases much better?
You should be able to set the color depth on your display driver as an arg to your X server. I can't remember the syntax, but it should be available on the web somewhere. I discovered this (not sure why it's not easier to find) last year.
If the flamewar's boring...
on
Qt Going GPL
·
· Score: 1
Why do you always a) mention it and b) report on it.
You are right that a DOM tree must still be instantiated at runtime. The point I was making (as you have gathered) is that you don't have to parse and create the DOM from scratch at runtime. When talking about how expensive a procedure is, you need to consider both the runtime performance/resource utilization as well as the cost of maintenance. You say that JSP/PHP give you the same content/design separation as XMLC, but that just isn't true. I have done a fair share of JSP in which the presentation has changed rapidly on top of static business logic. The bottom line is that these technologies just aren't good for that. Somewhere/somehow somebody who knows about programming has to get in the mix. Code (albeit small chunks) *are* embedded into the middle of the presentation. XMLC, on the other hand, allows for the kind of separation in which a static HTML (or WML) mockup can be uploaded to a server by a designer and changes will automatically take effect. The cost to maintain XMLC based projects vs. JSP based projects is significantly different. On the topic of expensive operations, just how expensive is DOM manipulation? When you already have the document parsed and the DOM created, where do you pay the performance prices? I haven't done a lot of benchmarking (have you?), but it would seem to me that the only real price you would pay is that of memory consumption. Otherwise, you're talking about loading an existing class into memory and executing lightweight methods on it. With the right sort of caching, I don't seem this as being much of an issue.
Actually, you generally generate the DOM tree before hand. It's true that loading a DOM tree can be taxing, but I wouldn't guess that your average WML document (meant to be displayed on a cell phone) is going to be of the magnitude that would put much of a strain on even the lamest of app server boxes. Even with a bit of performance hit, the design clarity that something like XMLC provides (as opposed to embedded code-presentation mixes like JSP, PHP, etc.) is worth it.
http://www.enhydra.org Has a servlet engine (built around tomcat) with an Apache/ISS/Netscape based load balancer. Built-in support for WML via an extension to their GPL'd XMLC technology.
What exactly do you mean by "lack of a good *procedural* database API"? I'm not flaming, I just don't understand the terminology. My experiences with Enhydra's database API have been nothing but positive. They've got a robust Object-relational database layer that does connection pooling, etc. Using the Data Object Design Studio, I've been able to dynamically generate java objects from an existing database schema that I pulled in via JDBC from a live database. Personally, I don't see how the database API could get much better. As far as the mail capabilities go, I'm using Sun's freely available JavaMail API. The beautiful thing about server side java (and perl, python, etc.) is that there are so many freely available language extensions and APIs. I've done my share of Perl for server side applications, and my experience with Java (although I'm a big Perl fan) has been quite a bit more productive...especially since I stopped trying to DYI all my servers and started using Enhydra. There's my 6 cents:)
Actually, you can use Apache JServ as the servlet runner to operate Enhydra under. If used in this configuration, Enhydra offers extensions and additions to what you would normally have with plain servlets. You might want to look at this for some info on why a few people have chosen to stick with Enhydra. BTW, if you don't have JServ (or a web server for that matter) you can run Enhydra apps directly with the built in web server functionality.
I've been using Enhydra for every work project I've done since they Open Sourced it in January. I have had nothing but pleasant experiences with both Enhydra and the Enhydra list. I've learned a lot about good programming from looking at the source. A couple of things to note about Enhydra:
You don't have to use the whole app server. There are many different parts (jddi, xmlc, standarddatabasemanager, data object design studio) that can be used separately with any Java project you are working on.
Data access couldn't be much easier. A graphical tool is provided for doing object/relational mapping on existing databases, as well as constructing new databases from an Object design standpoint.
EJB support is on its way. The Enhydra team is working on a demo of EJB support in Enhydra. This will most likely tie into EJBOSS
I've been very pleased with Enhydra, and I feel that the Enhydra community is only in the beginning phases. With a little more involvement, it is set to take off in a big way. It's certainly worth a download, just to check out the various components and determine their usefulness to you.
Linux -- Legacy System
on
Generations
·
· Score: 1
According to Tannenbaum, Linux is ALREADY a legacy system.
Slashdot Mirror
Groovlets, though a refreshing way to not have to risk getting any Java on your clothes, don't at all provide the features of Rails. They are synonymous with Java servlets, which is pretty much the bare metal request/response paradigm, accessible as an API.
The Ruby equivalent to Groovlets is WEBRick's Servlets. Rails can run on top of this, but it provides a much higher level of abstraction.
Right...it's silly colloquial American English translated directly to Hindi (which means most Indians wouldn't understand it at all ;)
But, if you're doing Ruby, it's not work ;)
Thanks Tom. It's actually http://rubycentral.org.
In my own defense, I was backing it up...to a USB drive that also got stolen ;)
Change aversion compounds on itself. People avoid new things that replace their old things, because they fear change. The more they do this, the more risky and costly it is to change. The fear grows. Why else would such a large percentage of desktops be running Windows when MacOS, BeOS, Linux, *BSD, etc. have been around to provide something that is in many cases much better?
If you would only drink the koolaid and start using Ruby, none of these language wars would affect you. :)
You should be able to set the color depth on your display driver as an arg to your X server. I can't remember the syntax, but it should be available on the web somewhere. I discovered this (not sure why it's not easier to find) last year.
Why do you always a) mention it and b) report on it.
You are right that a DOM tree must still be instantiated at runtime. The point I was making (as you have gathered) is that you don't have to parse and create the DOM from scratch at runtime.
When talking about how expensive a procedure is, you need to consider both the runtime performance/resource utilization as well as the cost of maintenance. You say that JSP/PHP give you the same content/design separation as XMLC, but that just isn't true. I have done a fair share of JSP in which the presentation has changed rapidly on top of static business logic. The bottom line is that these technologies just aren't good for that. Somewhere/somehow somebody who knows about programming has to get in the mix. Code (albeit small chunks) *are* embedded into the middle of the presentation.
XMLC, on the other hand, allows for the kind of separation in which a static HTML (or WML) mockup can be uploaded to a server by a designer and changes will automatically take effect. The cost to maintain XMLC based projects vs. JSP based projects is significantly different.
On the topic of expensive operations, just how expensive is DOM manipulation? When you already have the document parsed and the DOM created, where do you pay the performance prices? I haven't done a lot of benchmarking (have you?), but it would seem to me that the only real price you would pay is that of memory consumption. Otherwise, you're talking about loading an existing class into memory and executing lightweight methods on it. With the right sort of caching, I don't seem this as being much of an issue.
Actually, you generally generate the DOM tree before hand. It's true that loading a DOM tree can be taxing, but I wouldn't guess that your average WML document (meant to be displayed on a cell phone) is going to be of the magnitude that would put much of a strain on even the lamest of app server boxes. Even with a bit of performance hit, the design clarity that something like XMLC provides (as opposed to embedded code-presentation mixes like JSP, PHP, etc.) is worth it.
BTW, Enhydra *is* open source. It supports session via cookie/URL rewriting. Session is not tied to IP address.
http://www.enhydra.org Has a servlet engine (built around tomcat) with an Apache/ISS/Netscape based load balancer. Built-in support for WML via an extension to their GPL'd XMLC technology.
Now, THERE's a good idea.
What exactly do you mean by "lack of a good *procedural* database API"? I'm not flaming, I just don't understand the terminology. My experiences with Enhydra's database API have been nothing but positive. They've got a robust Object-relational database layer that does connection pooling, etc. Using the Data Object Design Studio, I've been able to dynamically generate java objects from an existing database schema that I pulled in via JDBC from a live database. Personally, I don't see how the database API could get much better. As far as the mail capabilities go, I'm using Sun's freely available JavaMail API. The beautiful thing about server side java (and perl, python, etc.) is that there are so many freely available language extensions and APIs. I've done my share of Perl for server side applications, and my experience with Java (although I'm a big Perl fan) has been quite a bit more productive...especially since I stopped trying to DYI all my servers and started using Enhydra. There's my 6 cents :)
Actually, you can use Apache JServ as the servlet runner to operate Enhydra under. If used in this configuration, Enhydra offers extensions and additions to what you would normally have with plain servlets. You might want to look at this for some info on why a few people have chosen to stick with Enhydra. BTW, if you don't have JServ (or a web server for that matter) you can run Enhydra apps directly with the built in web server functionality.
- You don't have to use the whole app server. There are many different parts (jddi, xmlc, standarddatabasemanager, data object design studio) that can be used separately with any Java project you are working on.
- Data access couldn't be much easier. A graphical tool is provided for doing object/relational mapping on existing databases, as well as constructing new databases from an Object design standpoint.
- EJB support is on its way. The Enhydra team is working on a demo of EJB support in Enhydra. This will most likely tie into EJBOSS
I've been very pleased with Enhydra, and I feel that the Enhydra community is only in the beginning phases. With a little more involvement, it is set to take off in a big way. It's certainly worth a download, just to check out the various components and determine their usefulness to you.According to Tannenbaum, Linux is ALREADY a legacy system.