Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming Software IT Technology

Ruby on Rails 0.13 Out Today with AJAX Superpowers 79

Posted by timothy from the buzzword-diesel dept.
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."
This discussion has been archived. No new comments can be posted.

Ruby on Rails 0.13 Out Today with AJAX Superpowers More

Ruby on Rails 0.13 Out Today with AJAX Superpowers

Comments Filter:

  • This is actually really damned good (Score:3, Interesting)

    by byolinux ( 535260 ) * on Wednesday July 06, 2005 @06:07PM (#12998752) Journal
    Those demos have really got me interested in seeing what I can do with this.

    Imagine a web enabled version of Delicious Library [delicious-monster.com] with this. Fuck, that's cool.

  • This is fantastic stuff! (Score:5, Interesting)

    by Per Wigren ( 5315 ) on Wednesday July 06, 2005 @06:27PM (#12998880) Homepage
    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.
    • For translators the site is inline editable. Just doubleclick on a textfield or alt+click on a string to edit it inline.

      I can't believe I didn't think of that before you just mentioned it...did you roll your own, or find a decent example? I did that once before for some old pages that had a lot of updates, but without the benefit of AJAX-type technology.

      Care to share some code with the rest of us?

      • Re:This is fantastic stuff! (Score:4, Interesting)

        by Per Wigren ( 5315 ) on Wednesday July 06, 2005 @09:56PM (#12999901) Homepage
        I'm in the middle of rewriting that part but here is the logic:

        Make sure textfields are inside a <div class="editable" id="text_id"> and wrap strings in <span class="editable" id="string_id"> where text_id/string_id is the id of the text/string in the database.

        Create a Javascript behaviour that finds all nodes that has class "editable". Prototype comes with the function getElementsByClassName().
        On each div, add a ondblclick event that:
        * creates a textarea node and put it inside the div.
        * hide the old content
        * set value of the textarea to the text content
        * add a submit button that has onclick = "new Ajax(foo);" where foo is the parameters for your ajax call and set it to update the current editable div (so the textarea will be overwritten)
        * the action for the Ajax call should return the output of the saved text.

        do the same for strings but use a input type="text" instead.
        • That's not degradable.

          A better solution would be to start with a page that has an "edit" button that works without Javascript. Then have your Javascript check to make sure the AJAX stuff is available, and makes the visibility of the edit button hidden (while keeping a rule that unhides it on :focus for keyboard users).

          Finding all the .editable elements in your onload handler or at the bottom of the page is bad practice as well. On a slow connection or when you have slow-loading ads, the user could be do

  • solaris/firefox 1.04 (Score:4, Insightful)

    by Endymion ( 12816 ) <slashdot DOT org AT thoughtnoise DOT net> on Wednesday July 06, 2005 @06:40PM (#12998944) Homepage Journal
    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?

    • 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?

      1. Google is doing it (eg. gmail, maps), and that's good enough for me!
      2. Browsers are following the javascript/DOM specs much more these days (except for MSIE, of course)

      As far as Firefox-on-Solaris goes... there's no reason it shouldn't work there, is there? I don't know Ruby-on-Rails specifically, but Firefox/Solaris shouldn't be any different from Firefox

      • The thing is, maps.google.com works great here, and the ruby-on-rails stuff didn't. badly.

        maybe google is only using a "safe subset" of features?

        Yah, firefox should be the same everywhere, I'd think, but it's not apparently.

        When I drag item in the shoping cart, I don't get a picture of the drag, just the basic mouse pointer. When I try the auto-complete, nothing happens at all.

        I'll have to try it on Firefox/Linux when I get home...

    • 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?

      I'm pretty much with you here. gmail doesn't rely on the client handling anything properly. They have a straight html version (which I keep meaning to check out through lynx. There just aren't enough hours in the day. Anyone played with that?)

      Anyway, this sort of thing's really exciting. In a lot of ways, I've never much liked writing GUI stuff. Develop

    • Re:solaris/firefox 1.04 (Score:4, Insightful)

      by thomas.galvin ( 551471 ) <slashdot AT thomas-galvin DOT com> on Thursday July 07, 2005 @09:37AM (#13003382) Homepage
      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.

      I'm running Firefox 1.0 on Solaris, and they all worked fine, albeit a bit slowly. I'm not sure what you're seeing. Perhaps one of your extensions is borking something? If your filtering .js files via adblock, for example, things would go very wrong, very quickly.
      • hmm... that's a good idea. I'm not filtering js, though. images and iframes from quite a few well known hosts, yes...

        I'm more and more confused about this the more I look at it. Perhaps it is something borked up with my solaris install? This would not exactly be a revalation.

        that just lends evidence to my theory that using heavyweight client side code is too fragile. if it breaks that easily, why trust it?
        • Just another person saying that it seems to work okay on Solaris. Methinks it's your install.

          And Mac OS X Safari/Firefox, Windows IE6 (although the transparency is glitchy, of course), and Linux Firefox & Mozilla.
  • 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.
    • anything involving lots of javascript will only be the future of the user Internet.

      The corporate Internet will wonder whether instant feedback when people have been used to non-instant feedback for years on the net already will be worth having to develop and test 2x the funcationality (with + without javascript) to avoid being the test case in 508/DDA discrimination lawsuits.
  • Damn, and just when I thought I'd switch to Opera due to its built-in Bittorrent client...
    • I don't know if this was supposed to be a joke, but why on earth would anyone use a bittorrent client embedded in their browser when their is Azureus?

      • Some people wonder why anyone would use Azureus.

        Either way, one of the goals of bittorrent was to make downloading as natural as possible to the user. You click a .torrent link, bittorrent reads the .torrent metafile and connects to the tracker and peers to start downloading. But to the user, it looks almost like a regular download dialog.

        Opera goes one step further by integrating a bittorrent into the browser, eliminating the need for a client, and simply bringing bittorrent one step closer to being a

  • Demos (Score:3, Insightful)

    by mattwarden ( 699984 ) on Wednesday July 06, 2005 @09:33PM (#12999766)

    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.

    • 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.

      What are you talking about? You can use AJAX for a product catalogue and shopping cart easily without breaking things.

      What matters is that important entry points should be addressable by URI. When somebody adds something to their shopping cart, it doesn't matter that immediately following the action, the resulting view isn't

      • What are you talking about? You can use AJAX for a product catalogue and shopping cart easily without breaking things.

        Show me an implementation of an AJAX product catalog that doesn't suffer from severe usability problems. Backbase is a perfect example of why this is not a good idea: http://projects.backbase.com/RUI/shop.html [backbase.com]

        • Show me an implementation of an AJAX product catalog that doesn't suffer from severe usability problems.

          Well AJAX is only recently gaining mindshare amongst developers, so there's not many examples of it out in the wild.

          In any case, I can't think of a single product catalogue, with or without AJAX, that doesn't have usability problems.

          Backbase is a perfect example of why this is not a good idea

          No, that's a perfect example of a terrible use of AJAX. It's also a perfect example of a terr

  • 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
    • In my opinion, AJAX has some compelling uses, but for most web application work, it adds a lot of extra complexity and points of failure with little end user return. Ruby on Rails on other hand, will probably be the next PHP. It greatly speeds prototype development on and into live production. It also has built in unit testing and lots of other compelling features. Run through the first Ruby Tutorial here [onlamp.com]. It will change your thinking on creating web apps forever.

    • 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...

  • Wow, these demos are really impressive indeed. Not that they are doing anything that couldn't have been done with Internet Explorer 4, but how little Ruby code is required to make it all work.

    That said, this technology is full of problems by its nature. Browser support is no longer the issue it once was (especially if the framework takes care of the remaining differences for you), but many browsers do DHTML very slowly, and more often than not it just doesn't have the right feel to it (as in, it still look
    • > 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, wh
        • 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.
        • 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
          • 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
            • 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.
            • > 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.

        • Re:Impressive, but... (Score:4, Interesting)

          by Fweeky ( 41046 ) on Thursday July 07, 2005 @07:42AM (#13001888) Homepage
          "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.

    • Sounds like you want either Java Web Start [sun.com] or wxWidgets [wxwidgets.org].

      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 d

      • I don't completely agree with you there. Native look and feel, IMO, is the combination of using the right (native) widgets, and following the conventions of the system (with respect to positioning and such).

        Using the native widgets is easy enough for a cross-platform framework like the one I proposed. Of course, you do have to write an implementation for each widget toolkit, but you can start by making a portable non-native one (a la wxUniversal) as a proof of concept first.

        Getting the positioning and nam
  • 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 [perl.com] 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
  • 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 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.
  • 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?

Slashdot Top Deals

Our policy is, when in doubt, do the right thing. -- Roy L. Ash, ex-president, Litton Industries

Close