[Rails-spinoffs] Re: Need help to learn Prototype Programming

[Colin Mollenhour]

>From what I've seen there is a great deal of code generation in Rails that is line for line in _javascript_..  page.visual_effect here, reset a form there, insert html here..  I'm sure it saves a lot of code in other cases, and you can write plugins (correct term?) yourself to let it do anything you need it to, but to me these things defeat some of the primary purposes of a high(er)-level code generator.. Some things have already been simplified as much as they can be and any further just makes things harder. If you achieve the correct separation of data and interface, then handling server code, client code, and the communication between is quite easy.  Practically all of my Ajax requests are for pure data, allowing me to code the GUI in one environment (html, css, _javascript_, etc..) to a very fine detail, and the backend in another (PHP, MySQL in my case). Not quite as nice as Rails, but spitting out data on the server is as simple as json_encode and parsing it on the client is as simple as json_decode (or easier if the Content-type: application/x-json feature is added). Someday I'll have to get my hands dirty with Rails, but at the moment I don't see that it'd be beneficial enough.  I write a lot of _javascript_ that has very specific purposes that couldn't be avoided by using Rails or any other code generator. To each his own! Colin Thomas Fuchs wrote: Am 19.02.2007 um 04:34 schrieb Colin Mollenhour: If you are going to do any *serious* Ajax work you are going to need to know _javascript_, unless you limit yourself to whatever frameworks out there provide to you, which currently isn't much. I disagree. With Rails RJS templates, you can code _very_ complex Ajax-powered apps, without having to know _javascript_. Personally, I use it a lot (note you can also mix-in your hand- written JS if you want to!). The best thing about on-demand _javascript_ generation on the server is that the control over the view is not split-up between client and server but rests firmly with the server, where your MVC (or other) framework sits. This equates to _much_ less cruft, by having to write no or less code that ties server and client together (think spitting out data on the server and parsing that in JS). Check out the cheatsheet: http://slash7.com/assets/2006/10/8/RJS-Demistified_Amy-Hoy-slash7_1.pdf Note that there is other stuff out there that relies on code generation, too (like the Google Web Toolkit, which I haven't used but I'm pretty sure you can do *serious* stuff with, like with RJS templates+Prototype). Mind that it doesn't save you from knowing what's going on in the DOM and what Ajax can and cannot do-- it just means you don't have to get into the innards of _javascript_ if you don't want to. :) Of course, code generation limits you, but that isn't automatically a bad thing. Many great real-world sites use it all the time. YMMV. Best, Thomas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---