Hi, I wish to ask one question that I also want to learn prototype and want to do Ajax programming (I already have enough knowledge of almost all the web related popular scripting and server side languages) but when I see some Ajax example created from prototype on the net and see the source code. It''s not identical to traditional javascript, can you please tell me is there any special requirement to be a master of prototype programming. Why it seems me too complicated although i already knew javascript. Can you please guide me in learning what should I do ? Jimmy --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Hey Jimmy, Jimmy a écrit :> I wish to ask one question that I also want to learn prototype and > want to do Ajax programming (I already have enough knowledge of almost > all the web related popular scripting and server side languages) but > when I see some Ajax example created from prototype on the net and see > the source code. It''s not identical to traditional javascript, can you > please tell me is there any special requirement to be a master of > prototype programming. Why it seems me too complicated although i > already knew javascript.Well, there''s "knowing JS" and "knowing JS". In-depth knowledge of JS is actually the attribute of a tiny minority of people (to which I don''t claim to belong)... There is, unfortunately, no good "learning"-oriented consistent set of material for Prototype yet, BUT there are multiple tutorial-style articles on the blogs of Prototype lovers, and the API reference is pretty good too (and it does have 2 nice "Learn" articles already, too!). Check out the following: - Blog articles: look at Justin, Tobie, Andrew and Dan for a start. - API ref and articles: look at the official site. http://encytemedia.com/ (Justin ; great stuff on Enumerable in Dec''06) http://tobielangel.com/ http://andrewdupont.net/ http://www.danwebb.net/ http://prototypejs.org/ -- Christophe Porteneuve a.k.a. TDD "[They] did not know it was impossible, so they did it." --Mark Twain Email: tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On Feb 13, 3:56 pm, "Jimmy" <jimmy.c...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi, > > I wish to ask one question that I also want to learn prototype and > want to do Ajax programming (I already have enough knowledge of almost > all the web related popular scripting and server side languages)If you just want AJAX functionality, there is no need to learn Prototype. AJAX itself is pretty straight forward - apparently you know javascript, so try a straight javascript library: Ajaxtoolbox: <URL: http://www.ajaxtoolbox.com/ > <URL: http://www.ajaxtoolbox.com/request/documentation.php > Yahoo!: <URL: http://developer.yahoo.com/javascript/howto-ajax.html#request > The Yahoo! link shows you how to make a request and do a callback from first principles in pure javascript (i.e. no 3rd party libraries) with about 20 lines of code. Ajaxtoolbox has a rich, well documented API with examples and support forum. -- Rob --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Jimmy wrote:> I wish to ask one question that I also want to learn prototype and > want to do Ajax programming (I already have enough knowledge of almost > all the web related popular scripting and server side languages) but > when I see some Ajax example created from prototype on the net and see > the source code. It''s not identical to traditional javascript, can you > please tell me is there any special requirement to be a master of > prototype programming. Why it seems me too complicated although i > already knew javascript. > > Can you please guide me in learning what should I do ?You seem to be missing "Rails" in that mix. One should never code JS directly if one can use a unified and flexible platform that runs it for you. Learn Rails, and your websites will be completely dynamic before you know it. And you can then view the generated source, and learn how Rails put the effects together, to learn Prototype. Ruby on Rails is the path of least resistance here... -- Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!! --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
> > One should never code JS > directly if one can use a unified and flexible platform that runs it > for you.Complete rubbish. That''s all I have to say about that. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Ryan Gahl wrote:> > One should never code JS > directly if one can use a unified and flexible platform that runs it > for you. > > > Complete rubbish. That''s all I have to say about that. >I find myself agreeing. If one depends on the framework to generate one''s Javascript, one doesn''t learn Javascript, which is sort of the point of this question. I''m using Prototype in CakePHP, but I like the fact that, while options are available to front-end my javascript, I can simply learn the stuff. Regards, -Tobias Parent --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
i recommend that you buy this book and turn to the appendix in the back and read all the stuff on the js language: http://www.amazon.com/Ajax-Action-Dave-Crane/dp/1932394613/sr=8-1/qid=1171405389/ref=pd_bbs_sr_1/105-3685209-2243613?ie=UTF8&s=books On 2/12/07, Jimmy <jimmy.code-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > Hi, > > I wish to ask one question that I also want to learn prototype and > want to do Ajax programming (I already have enough knowledge of almost > all the web related popular scripting and server side languages) but > when I see some Ajax example created from prototype on the net and see > the source code. It''s not identical to traditional javascript, can you > please tell me is there any special requirement to be a master of > prototype programming. Why it seems me too complicated although i > already knew javascript. > > Can you please guide me in learning what should I do ? > > Jimmy > > > > >--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
A bit harsh, but tentatively agree. It''s a really great way to get into it. Once you''ll see how easy it is to do dynamic/ajaxified pages with Rails, you''ll start to get more curious about what goes on "under the hood". Of course, the real power of Prototype will only then start to unfold... :) Best, Thomas Am 13.02.2007 um 19:29 schrieb Phlip:> You seem to be missing "Rails" in that mix. One should never code JS > directly if one can use a unified and flexible platform that runs it > for you. Learn Rails, and your websites will be completely dynamic > before you know it. And you can then view the generated source, and > learn how Rails put the effects together, to learn Prototype. > > Ruby on Rails is the path of least resistance here...--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Well, as much as my limited dabbling has permitted, rails looks very cool, but I find it unrealistic to switch all my development over to rails simply because its cool. When I take over a site for a new client, quite often they are reluctant to move to a new ISP, as that causes them to have to update all there mail settings and such.. I chose PHP/MySQL way back when because 95% of ISPs already offer it. as for " One should never code JS directly" I find this as silly as someone saying one should never code HTML when you can use an app like Dreamweaver... ______________________________________________________________________ Alex Duffield . Principal . InControl Solutions . http:// www.incontrolsolutions.com On 15-Feb-07, at 7:59 AM, Thomas Fuchs wrote:> > A bit harsh, but tentatively agree. It''s a really great way to get > into it. > > Once you''ll see how easy it is to do dynamic/ajaxified pages with > Rails, you''ll start to get more curious about what goes on "under the > hood". > Of course, the real power of Prototype will only then start to > unfold... :) > > Best, > Thomas > > Am 13.02.2007 um 19:29 schrieb Phlip: > >> You seem to be missing "Rails" in that mix. One should never code JS >> directly if one can use a unified and flexible platform that runs it >> for you. Learn Rails, and your websites will be completely dynamic >> before you know it. And you can then view the generated source, and >> learn how Rails put the effects together, to learn Prototype. >> >> Ruby on Rails is the path of least resistance here... > > > >--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
IMHO, you''ll be and stay happier if _you_ get to choose the tools you want to use instead of having them forced upon you... But yeah, real world and things. Maybe try sneaking it in for a new project... :) Best, Thomas Am 15.02.2007 um 18:08 schrieb Alex Duffield:> Well, as much as my limited dabbling has permitted, rails looks > very cool, but I find it unrealistic to switch all my development > over to rails simply because its cool.--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Alex Duffield wrote:> Well, as much as my limited dabbling has permitted, rails looks very > cool, but I find it unrealistic to switch all my development over to > rails simply because its cool. > > When I take over a site for a new client, quite often they are > reluctant to move to a new ISP, as that causes them to have to update > all there mail settings and such.. > > I chose PHP/MySQL way back when because 95% of ISPs already offer it. > > as for " One should never code JS directly" I find this as silly as > someone saying one should never code HTML when you can use an app > like Dreamweaver...I find it silly that you rejected my premise for irrelevant external reasons, then accused my conclusion of lacking a premise. Nobody told you to switch all your clients'' sites to Rails. You then extrapolated that to claim I told you to move all your clients to new ISPs. Etc. Write a scratch Rails project, put form_remote_tag in it, and get that to work. With the right tutorial (such as the Agile Rails Book), you could do all that in 15 minutes. Then hit View Source and look at the generated code. Install Firebug, run the site, and read its transactions. Next, never write specific code in a low-level language - HTML, SQL, JavaScript, etc. - if a high-level generator is available to integrate that code with your domain objects, and produce generic code. If such a generator is not available, for external reasons, then by all means write the code in the low-level language! -- Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!! --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Toby Parent wrote:> I find myself agreeing. If one depends on the framework to generate > one''s Javascript, one doesn''t learn Javascript, which is sort of the > point of this question. I''m using Prototype in CakePHP, but I like the > fact that, while options are available to front-end my javascript, I can > simply learn the stuff.Once we "learn JavaScript", then we need to write it as flexibly and platform-neutraly as possible. I would rather bottle all the cross-platform stuff up and call into it, than rewrite all the if(ie) stuff, all the time. That, in turn, requires obscenely complex object models in JavaScript. They deserve to be written once and called many times. This exact discussion was once held, 30 years ago, regarding Assembler and C. You had to know Assembler to code C, and you used C to avoid Assembler by any means necessary. C handled porting the machine code to other CPUs. Yet there were still people claiming that you should still write more Assembler, to learn it, to prove you can, when it''s convenient, when you know what to write, etc. Sure those reasons still exist. But your default choice, in that situation, should always be C-first. -- Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!! --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I couldn''t help but laugh when I read your comparison of writing
Javascript to Assembly! The fact of the matter is, there is a lot of
functionality out there that you can''t obtain without getting down and
dirty with Javascript, and libraries like Prototype are there to make
it easy and cross-browser compatible. There isn''t a nice abstracted way
to do everything I want so I''d just end up writing the Javascript
anyway, and my hand-written Javascript is going to be a lot better than
hacking up abstracted wrappers that I don''t really understand
what''s
happening. 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.<br>
<br>
Colin<br>
<br>
Phlip wrote:
<blockquote cite="mid:05d101c753b7$9f92ff40$6601a8c0@Marley"
type="cite">
<pre wrap="">Toby Parent wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I find myself agreeing. If one depends on the
framework to generate
one''s Javascript, one doesn''t learn Javascript, which is sort
of the
point of this question. I''m using Prototype in CakePHP, but I like the
fact that, while options are available to front-end my javascript, I can
simply learn the stuff.
</pre>
</blockquote>
<pre wrap=""><!---->
Once we "learn JavaScript", then we need to write it as flexibly and
platform-neutraly as possible. I would rather bottle all the cross-platform
stuff up and call into it, than rewrite all the if(ie) stuff, all the time.
That, in turn, requires obscenely complex object models in JavaScript. They
deserve to be written once and called many times.
This exact discussion was once held, 30 years ago, regarding Assembler and
C. You had to know Assembler to code C, and you used C to avoid Assembler by
any means necessary. C handled porting the machine code to other CPUs.
Yet there were still people claiming that you should still write more
Assembler, to learn it, to prove you can, when it''s convenient, when
you
know what to write, etc. Sure those reasons still exist. But your default
choice, in that situation, should always be C-first.
</pre>
</blockquote>
<br>
--~--~---------~--~----~------------~-------~--~----~<br>
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group. <br> To post to this
group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <br> To
unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
<br> For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en <br>
-~----------~----~----~----~------~----~------~--~---<br>
</body>
</html>
<br>
Colin Mollenhour wrote:>I couldn''t help but laugh when I read your comparison of writing Javascript >to Assembly! The fact of the matter is, there is a lot of functionality >out there that you can''t obtain without getting down and dirty with >JavascriptAnd there are places where you must use Assembly. When you do, the odds go up that your code is CPU-specific, just as writing your own JavaScript increases the odds it''s browser-specific. This is just a metaphor. Nobody is saying "never write JavaScript!" -- Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!! --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
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).<br>
<br>
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!<br>
<br>
Colin<br>
<br>
Thomas Fuchs wrote:
<blockquote
cite="mid:30411343-996F-48FF-AA3B-6E7E8B05C28D-moWQItti3gBl57MIdRCFDg@public.gmane.org"
type="cite">
<pre wrap="">
Am 19.02.2007 um 04:34 schrieb Colin Mollenhour:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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:
<a class="moz-txt-link-freetext"
href="http://slash7.com/assets/2006/10/8/RJS-Demistified_Amy-Hoy-slash7_1.pdf">http://slash7.com/assets/2006/10/8/RJS-Demistified_Amy-Hoy-slash7_1.pdf</a>
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
</pre>
</blockquote>
<br>
--~--~---------~--~----~------------~-------~--~----~<br>
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group. <br> To post to this
group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <br> To
unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
<br> For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en <br>
-~----------~----~----~----~------~----~------~--~---<br>
</body>
</html>
<br>
* Phlip wrote (18/02/07 02:15):> Alex Duffield wrote: >[...]> > Next, never write specific code in a low-level language - HTML, SQL, > JavaScript, etc. - if a high-level generator is available to integrate that > code with your domain objects, and produce generic code. If such a generator > is not available, for external reasons, then by all means write the code in > the low-level language!Wow - HTML, SQL and Javascript descibed as "low-level"! I can understand Assembly language being low-level, but SQL and Javascript are standards-based (normally interpreted) languages designed to shield programmers from implementation differences (though perhaps this doesn''t work perfectly in practice), and HTML is not a programming language at all, but another standard designed to overcome OS interoperability problems from the start. If these are now low-level, what''s high-level? Ruby? Does that run the same on every computer in the world without local implementation differences? If what you mean is "never write client-side code, when you can auto-generate it using server-side code (on a server of your choice)", then maybe you have a point. I don''t like it, but perhaps it''s the way the world is going. Time will tell. Chris --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Am 19.02.2007 um 11:53 schrieb Chris Lear:> If what you mean is "never write client-side code, when you can > auto-generate it using server-side code (on a server of your choice)", > then maybe you have a point. I don''t like it, but perhaps it''s the way > the world is going. Time will tell.I don''t think it really goes into an all-out generating stuff for the sake of it way, but judging by what Rails wants to achieve, it''s "taking the chores" out of development, and allowing everyday easy stuff to be encapsulized (not really hidden) by the framework; like Activerecord does for most DB queries/updates and RJS for most Ajax behavioural returns. You still get all the underlying interfaces (SQL for Activerecord, Javascript for RJS), so you can have the best of both worlds, as opposed to both having a strict layering that''s favoured by some of the "enterprisey" frameworks out there, or the other "extreme" of hand-coding everything. The best frameworks are those that don''t get in the way of what you want to do, but really help you out in most cases to allow you to concentrate on the more specialized things. 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Thomas Fuchs wrote:> You still get all the underlying interfaces (SQL for Activerecord, > Javascript for RJS), so you can have the best of both worlds, as > opposed to both having a strict layering that''s favoured by some of > the "enterprisey" frameworks out there, or the other "extreme" of > hand-coding everything.Thanks; now lets try saying it like this: - pick a core language for your app. For example, if you team has not yet bought the TCO for stored procedures, don''t be the one to start - write in the core language by default, without a defensible reason to use one of the peripheral languages - if the core language comes with generators for code in the peripheral language, use them to learn that language, and possibly to apply tweaks That rationale applies equally to Rails and JavaScript as to C and Assembler. Including disassembling your compiled code to learn what the compiler did... -- Phlip --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
> That rationale applies equally to Rails and JavaScript as to C and > Assembler.Uh, pre-pre-K&R C, the kind where * turned an int into a dereferenced pointer. The modern C languages give you fewer defensible reasons to use Assembler, and less comprehensible disassembly!! -- Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!! --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Thomas Fuchs wrote:> I don''t think it really goes into an all-out generating stuff for the > sake of it way, but judging by what Rails wants to achieve, it''s > "taking the chores" out of developmentToday I tried to write link_to_remote ''foo'', toggle(''my_id''), and couldn''t find the right wrapper for Element.Toggle. I didn''t want Effect.Toggle! So (guess, what, guys?!), I wrote the ''Effect.toggle("my_id")'' directly! -- Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!! --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Just for the record, I did not write that below.... ______________________________________________________________________ Alex Duffield . Principal . InControl Solutions . http:// www.incontrolsolutions.com On 19-Feb-07, at 2:53 AM, Chris Lear wrote:> > * Phlip wrote (18/02/07 02:15): >> Alex Duffield wrote: >> > [...] >> >> Next, never write specific code in a low-level language - HTML, SQL, >> JavaScript, etc. - if a high-level generator is available to >> integrate that >> code with your domain objects, and produce generic code. If such a >> generator >> is not available, for external reasons, then by all means write >> the code in >> the low-level language! > > Wow - HTML, SQL and Javascript descibed as "low-level"! I can > understand > Assembly language being low-level, but SQL and Javascript are > standards-based (normally interpreted) languages designed to shield > programmers from implementation differences (though perhaps this > doesn''t > work perfectly in practice), and HTML is not a programming language at > all, but another standard designed to overcome OS interoperability > problems from the start. If these are now low-level, what''s high- > level? > Ruby? Does that run the same on every computer in the world without > local implementation differences? > > If what you mean is "never write client-side code, when you can > auto-generate it using server-side code (on a server of your choice)", > then maybe you have a point. I don''t like it, but perhaps it''s the way > the world is going. Time will tell. > > Chris > > >--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---