Ruby on Rails 0.13 Out Today with AJAX Superpowers
Robert J. Berger writes "The Ruby on Rails team announced that "After the longest gap between releases since Rails was made public and after more than 225 fixes and new features, the final major release before the 1.0 milestone has arrived."
This is a major update to what is to many developers
consider the new tool for developing sophisticated interactive database driven web applications. It integrates
backend Model/View/Controller object-oriented model with
AJAX based clients so that the developer can focus on the app and not on the details of basic mechanisms. You really can do much more with much less coding.
The new release adds a completely rewritten visual effects engine, drag-and-drop capability including sortable lists, and autocompleting text fields to Rails. All building on top of an upgraded version of Prototype, the javascript foundation for Ajax in Rails ... Check out the very cool
demos at script.aculo.us."
Those demos have really got me interested in seeing what I can do with this.
Imagine a web enabled version of Delicious Library with this. Fuck, that's cool.
Join the Free Software Foundation
I've been playing with Rails since september and I've run edge rails (subversion trunk) for about a month while developing my soon-to-be-released rewrite of my site that uses a lot of this Ajax stuff in a user friendly way.
Users can sort the pictures in their galleries by dragging them to the position they want and doubleclick them to hide them (it then becomes 50% transparent). The user always get immediate feedback without reloading the page thanks to Ajax. For translators the site is inline editable. Just doubleclick on a textfield or alt+click on a string to edit it inline. Click "save" and it's changed. Admin stuff is always available but hidden by default in drawers that you can slide in when you need them so you can be logged in as an admin an change any setting, delete posts etc without needing to go to a separate admin page or have a cluttered interface. You don't even have to reload the page in most cases...
All this stuff is damn easy to implement thanks to the wonders of Ruby on Rails and the Prototype framework.
My other account has a 3-digit UID.
wow... I really want to try this... I love the idea of ruby on rails, but all of this client side code is nuts.
Of all the samples, only the shoping cart works at all on Firefox1.04 on solaris. Everything else just does nothing and renders horribly. Even the shoping cart demo fails to render things properly, even when it works.
sigh...
I really really really want to like this... but how is relying on the client to run code properly sane, with all the different clients out there?
Ce n'est pas une signature automatique.
Someone's going to rail on Ruby. Hey, it was me last time.
I forget what 8 was for.
Because Ruby on Rails is the "bleeding edge" half baked trendy geek masturbation language / platform de jour. Sort of like tapas and sushi, except sushi is now passé (unless you eat it off the belly of a super midel).
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
my personal opinion is that the future of the web is ruby on rails + JS + postgresql.
why? RoR is a framework (unlike php, for example). postgres has more features then the more common mysql. JS improves usability.
Damn, and just when I thought I'd switch to Opera due to its built-in Bittorrent client...
Great. AJAX shopping carts. Will no one learn from the usability problems people found using Flash for such things?
AJAX is great... for applications where the state is not particularly important (i.e., enough to be bookmarked). A product catalog and shopping cart is not one of this type.
I've been in software development for years. Until very recently, I only did desktop applications and didn't have to bother with web stuff, apart from fooling around a little with Delphi's [AToZed's] IntraWeb and writing the HTTP compression code for it. Now I'm back working for a company that does all sorts of webrelated stuff. I haven't been doing this since HTML 2.0! Ofcourse: we start with PHP and MySQL, sometimes replacing MySQL with MSSQL and very rarely writing CGI/ISAPI/DSO in my language of choice if a dedicated server is warranted. Since then, I've been looking for ways to improve. ActiveX's never even been alive, Flash is pure evil. XMLHTTP seemed like a revelation to me. But getting all your stuff to work together properly, is a real bitch (excuse me). By now I've written a decent framework using PHP, Smarty, XMLHTTP and JavaScript (doing things they're not meant to all the way) which is really very MVC . But it just isn't nearly desktop programming. So my question is, to you, the experienced (or well, it is fairly new) RoR/AJAX users: Is this what I'm waiting for? Will this drastically improve development time? Or is it just FuD like all the other 'promising' stuff we've seen? Because IMHO, investing lots of time in stuff like JavaScript validation (etc), simply wont beat the costs for just buying a big server with a fat pipe that'll give users fast responsiveness in a more brute way. I'm not interested in shopping carts and drag and drop. Our customers have specific needs usually not for the 'home user'. They don't really care about eye-candy or technology. The people using it know what they're doing. They want it to work, work properly and work fast.
It's still not quite my idea of autocompletion, and the code uses "text_field_with_auto_complete", seemingly a primitive.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
> And, one of my pet peeves, communicating with the server after the page has been loaded is clumsy and inefficient at best. I think this is what's being addressed. It really is pretty easy with Rails.
I'm pretty sure Rails can't address the issue of client-server communication. It just can't be done with current browser technology. The only way browsers communicate with servers is through HTTP requests. This means that, even if you only want to send a single word, you need a full HTTP request, and you will get a response, which the browser will try to display or otherwise process.
Sending data from the server to the client is completely impossible, unless you somehow keep your request from completing, which most browsers don't like.
Something as simple as an IRC client is impossible to write for web browsers, because of these limitations. Probably the closest you can get is a form for submitting new messages, and a reloading page that displays the last few messages. This means a new connection, HTTP request, and response (which will give you the same form you just submitted) for every message you send. For the refreshes, you have a trade-off between update speed and wasted resources. Everything about it is hopelessly inefficient.
Rails is not going to be able to fix these issues. It's just inherent in the way browsers work. All it can do is make the generation of content on the server sied easier. At that, it does a very good job. My only concern is performance; Ruby is pretty slow at the moment, and I'm not sure if I would develop a dynamic site with a great number of visitors with it. I'm guessing it wouldn't be a problem, but I'd measure it first.
Please correct me if I got my facts wrong.
Oh, I thought the original issue was that asynch XMLHttpRequest was hard. Yes the pull-only issue of http sucks for programming apps. But this kind of thing with timed javascript events can help alot until something better comes along.
Check it out, it's based on Maypole, but now forked off and is under heavy and fast development.
There's a short introductory article on perl.com. I quote one paragraph from this article, that gives a good overview on Catalyst:
Catalyst is a new MVC framework for Perl. It is currently under rapid development, but the core API is now stable, and a growing number of projects use it. Catalyst borrows from other frameworks, such as Ruby on Rails and Apache Struts, but its main goal is to be a flexible, powerful, and fast framework for developing any type of web project in Perl. [...]
It's semi-OT cause it supports AJAX and uses Prototype as its Javascript library.
Bye egghat.
-- "As a human being I claim the right to be widely inconsistent", John Peel
You are aware of XMLHTTPRequest yeah?
Whist it's not perfect and support does vary it solves the problem you mention. Javascript makes the request and handles the response so there is no need to do a full page refresh just to get one word back to stick in the middle of the page (or whatever).
You probably could write an IRC client using this technique (not saying you should, just could). It would need to poll the server every n seconds or something to check for updates and then grab the lastest comments if there are some and append them to the current list. It could do that behind the scenes without a full page refresh each time. Not ideal but not impossible either.
After you've drag and dropped into the cart, the image should disappear and reappear rather than sliding. The current sliding back animation makes it look like the computer has refused your instruction.
"Ruby is pretty slow at the moment"
Actually, Ruby's quite speedy. It's not the fastest of dynamic languages, but it's certainly on par with PHP/Python in most areas that count. Where it's not, well, that's where the incredibly easy C extension stuff comes in.
Ruby On Rails is to Web Development as Modular Homes are to Home Construction. Personally, I'd rather not live in a trailer park no matter how fast I can move in.
You're not understanding him. In fact, you're offering up as solutions the very problems he's pointing out. You may think that XMLHTTPRequest is some magical tech that can communicate with the server telepathically, but it's not.
Javascript makes the request and handles the response so there is no need to do a full page refresh just to get one word back to stick in the middle of the page (or whatever).
That's the problem. The Javascript is making full HTTP requests to fetch one word. Why do you think it's called XMLHTTPRequest.
--
Promoting critical thinking since 1994.
Sounds like you want either Java Web Start or wxWidgets.
As for your statement: "GTK could easily be replaced by Cocoa or Win32 here". It makes me think you have never used more than one GUI framework, or tried a Java, Qt, Python (using e.g. wxWidgets) application etc. on OS X.
Native look'n'feel is only achieved by writing the application for the actual platform (often using platform frameworks, or replicating 99% of their functionality), since there are so many differences, and you can't address it by designing a cross-platform framework, it has been tried again and again.
The browser (HTML/DOM/CSS) actually is the best cross-platform framework.
Will this drastically improve development time? Or is it just FuD like all the other 'promising' stuff we've seen?
FUD is spreading fear, uncertainty, and doubt about your competitors product.
Maybe RoR spreads FUD about J2EE, but a product itself cannot be FUD...
Fair enough, I (vastly) overstated it when I said that XMLHTTPRequest 'solved' it and I do understand the point he made.
I guess I was trying to point out that whilst stuff like XMLHTTPRequest isn't perfect it can be used to good effect in certain situations. All is not completely lost.
I don't see that the prototype javascript library has been released under any specific license - there's only a copyright to Sam Stephenson in there. Is it licensed differently based on if you use it in RoR apps or using standalone? While it seems that this library could provide a great cross-language platform to build javascript UI libraries with, without licensing info it's rather dead in the water, no?
creation science book
> You're not understanding him.
Are you sure? 'RAMMS+EIN' didn't mention anything to do with AJAX (as far as I can see) but said:
"Probably the closest you can get is a form for submitting new messages, and a reloading page that displays the last few messages"
Looks like 'goynang' is right to update 'RAMMS+EIN' about AJAX.