Slashdot Mirror
Going beyond JSP with Ruby and Seaside
An anonymous reader writes "The Java community has used JavaServer Pages (JSP) technology through most of the last decade, but signs of rust are starting to show. Longstanding conventions inhibit Java programmers from using Java code within Web pages now. Other languages handle Web development much better than Java. This article discuss how code generation works in Ruby, and it delve into a more radical component-based approach in Seaside."
...that seems to be up and coming in the Ruby world is RJS templates. We're using them for the new indi site and they seem pretty handy. The Javascript to Ruby translation is not perfect, of course, but they make some AJAX-ish things nicer: page.visual_effect :highlight, 'sidebar_heading', :duration =>3.
If you're in the northern Virginia area you might be interested in the next NovaRUG meeting; there'll be a presentation on RJS there. Good times...
The Army reading list
I think there's a bit of confusion on your part about the purpose of templating languages. You seem to believe that they exist to allow crippled logic to prevent programmers from doing things they should know not to do anyways. But this is only a side-effect of their true purpose. Templating languages evolved from people writing web pages in real programming languages. Code like:
print "<html>\n";
print "<head>\n";
print "<title>My Webpage</title>\n";
...
print "</html>";
Stuff like the above snippet gets ugly and un-maintainable in a hurry, no matter what language you use (Ruby included). Templating languages were the solution to this problem. Instead of defaulting to being Java/Perl/Whatever code, they made you use an escape sequence to wrap code in that language and the default behavior was to pass their content straight through to the output stream. The crippled logic you speak of only came about because code like:
<% if (mycondition) { %>
condition is true
<% } else { %>
condition is false
<% } %> is awkward and ugly. However most templating languages still allow you to do logic in this manner.
Yes, presentation requires logic. No, presentation does not require business logic. Yes, fully-fledged languages like Ruby, Java, Perl, etc are better environments to write complex logic. However those environments are rarely the easiest to maintain large amounts of presentation code. Good templating languages will give you a way to write the complex logic in a real language and invoke that from the templating language. Not that JSP is a good templating language (no one in their right mind would say that...), but it does give you the ability to write custom tags in Java and call them from the JSP. And it also give you the &;lt;%...%> syntax to hack your way to what you want.
I was with you right up until you implied that COBOL was good at anything.
Search RapidShare and MegaUpload!
I live and work in Switzerland and our sites have to handle 4 or more languages. When Ruby has unicode support built in, I'll take another look at it. Until then, it's Java, python and php for me.
I've never used either JSP or Ruby on Rails, so I can't make any kind of informed comparision. I have, however, done some stuff with Seaside and the article focusses on the HTML generation aspect of it and completely misses what makes Seaside great.
Seaside's HTML generator is (IMHO) kind of clunky, actually. Something like PHP, where you embed the code in an HTML file, is cleaner and simpler. But, if you need Seaside, the HTML generation is going to be a small part of your application.
What makes Seaside so utterly cool is that the back button works.
Let me explain:
In Seaside, you generate your page programmatically and you specify what happens when a link is clicked or a button pressed via a callback.
For example:
html anchorWithAction: [self increase] text: '++'.creates a link. The stuff between the square brackets gets executed when the user clicks the link. In the above example, the current page just gets refreshed. If you want to go to another page, you'd use the "call:" method:
html anchorWithAction: [self call: OtherPage new] text: 'Some other page'.Called components can also return values, so you can call out to another page, get a result and use it in your action:
html anchorWithAction: [self setBackgroundColor: (self call: ColorPicker new)] text: 'Change background color'.So hopefully from this, you can see that Seaside works sort of like a boring GUI toolkit. You design the screens and add callbacks to the controls. When the user clicks on a link or presses a button, the associated callback gets invoked.
This would be pretty simple for all concerned were it not for that pesky back button. In the final example, the callback first takes the user to another page (a ColorPicker component) and then, when the user selects "Okay" in that, returns the result and passes it to "setBackgroundColor:".
But what if the user hits the back key while in the ColorPicker? This happens right in the middle of the callback. Can Seaside unwind the entire callback?
Yes, it can. Backing out Just Works.
But, I hear you say, what if there's information I don't want unwound? Say, a shopping cart?
Simple. You can tell Seaside which objects don't change after a backout.
Aside from the back button, you also get access to your entire programming system in the framework so you can do some pretty powerful things in between those square brackets.
Also, the web server is part of the system so you can bypass the framework and do lower-level stuff. For example, I once wrote an image generator. It analyzed its URL, generated the appropriate GIF and returned it.
Plus, of course, it's written in Smalltalk which is the greatest programming language ever ;-).
Geez - the "Trouble with JSP" article TFA references is over 6 years old(!). Java web development has come a long way since then! Just for starters, thinkg JSP with JSTL or Velocity templates plus your favorite MVC framework. Or how about Struts + Tiles? Saying that JSP is bad because of scriptlets is like saying...ASP.NET is bad because of VBScript.
I don't pretend to grok continuations (that's what Seaside does I hear), but an article I have found to be really illuminating explains this in quasi-Basic. The Basic-ish code in that example by the way, is written in what we call continuation passing scheme (CPS). That's basically the extra function tacked onto the argument list passed to functions [instead of f(arg1,arg2), we call f(arg1,arg2, c) where c is the continuation. f does not return as such, but calls c when it is ready to return. Instead of "return some_value;", we call "c(some_value)"].
Of course, continuations are not the solution to everything, but there's a lesson to learn from their usage.
CPS is often what functional programming languages compile into - no one writes code like that manually. You take a program, transform it into CPS, keep doing that, resubstituting variables names, expanding macros, and simplifying functions as necessary, until you are left with a couple of variables (-> registers), and a whole lot of assembler instructions - it has been compiled into assembly language. Now that's a nice compiler!