http://www.ripcord.co.nz/behaviour/ has anyone played with using this in rails... and is anyone working on integrating it? Would be nice if the ajax helpers used this :)
> Would be nice if the ajax helpers used this :)+1 I would like to hear the argument against this. If their is one.
I haven''t used it, but it looks great. I can''t help feeling that a lot of the JS stuff around at the moment is just awful - when I go to the scri.ptac.ulous site and I see big glowing boxes announcing new versions it just about burns my eyes. It''s like the blink tag, but bigger and less compatible :) OTOH, I love the stuff that really makes apps better - the asynchronous calls, the drag''n''drop. They are cool. But there''s not a lot of graceful degradation going on at the moment, libs like Behaviour can help this a lot if used well. C On 7/21/05, Jerrett Taylor <jerrett-7g3wz9A/6AxWk0Htik3J/w@public.gmane.org> wrote:> http://www.ripcord.co.nz/behaviour/ > > > has anyone played with using this in rails... and is anyone working on > integrating it? > > Would be nice if the ajax helpers used this :) > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Please see http://wrath.rubyonrails.org/pipermail/rails-spinoffs/2005- June/000025.html for some discussion on this. As it sounds nice at first look, there are some issues with this (to cite myself): -> Besides packing any addtional functions you might need in your app in it''s own js file (or files), the built-in functions just generate comparably small calls to prototype.js and the script.aculo.us libs. -> Also, with the upload-progress patch that is now in trunk, it''s possible to use <script> tags inside Ajax returns that are then executed. -> A complete seperation of client-side page structure (XHTML), design (CSS) and behaviour/logic (inside .js files) is achievable but comes at the cost of additional effort that IMHO isn''t justifyable. -> I''d vote for a strict seperation of HTML and CSS, throw in most stuff of "bigger chunks" of client side behavior into .js files, and let the Rails framework do it''s job by inserting events and little "scriptlets" inside the structure to call upon the external funtionality in the .js files. There are further problems, like onload kicking in only after all images have loaded and more difficult debugging; but i do heavy duty javascript stuff in my apps so behaviour.js, while not something for me, might be good for other apps. Thomas Am 21.07.2005 um 19:57 schrieb Jerrett Taylor:> http://www.ripcord.co.nz/behaviour/ > > > has anyone played with using this in rails... and is anyone working on > integrating it? > > Would be nice if the ajax helpers used this :) > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
At least you noticed it, this is proof that it works. ;) Thomas Am 21.07.2005 um 20:01 schrieb Colin Fleming:> ... when I go to the scri.ptac.ulous site and I see big glowing > boxes announcing new versions it just about burns my eyes. It''s > like the blink tag, but bigger and less compatible :)
Hi !
Jerrett Taylor said the following on 2005-07-21 13:57:
> http://www.ripcord.co.nz/behaviour/
>
>
> has anyone played with using this in rails... and is anyone working on
> integrating it?
Yup, been using it for the past few weeks. Works very fine. In fact, I
used behaviour to add the following:
Behaviour.register({
''a.hide'': function(el) {
el.onclick = function(e) {
new Effect2.Fade(''reference'');
}
}
});
I also use Behaviour.addOnLoad() quite a bit.
Bye !
François
On Thursday 21 July 2005 19:58, Caleb Buxton wrote:> > Would be nice if the ajax helpers used this :) > > +1 > > I would like to hear the argument against this. If their is one.It adds complexity in exchange for ... well, what? Michael -- Michael Schuerig Nothing is as brilliantly adaptive mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org as selective stupidity. http://www.schuerig.de/michael/ --A.O. Rorty, The Deceptive Self
Clean separation of behaviour from presentation? Encouraging people to think of scripts as the applications that client side pages are now becoming, rather than just little bits tacked on? Well, worth it, IMO. On 7/21/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote:> On Thursday 21 July 2005 19:58, Caleb Buxton wrote: > > > Would be nice if the ajax helpers used this :) > > > > +1 > > > > I would like to hear the argument against this. If their is one. > > It adds complexity in exchange for ... well, what? > > Michael > > -- > Michael Schuerig Nothing is as brilliantly adaptive > mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org as selective stupidity. > http://www.schuerig.de/michael/ --A.O. Rorty, The Deceptive Self > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
> On 7/21/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote: > > On Thursday 21 July 2005 19:58, Caleb Buxton wrote: > > > > Would be nice if the ajax helpers used this :) > > > > > > +1 > > > > > > I would like to hear the argument against this. If their is one. > > > > It adds complexity in exchange for ... well, what?On Thursday 21 July 2005 20:27, Colin Fleming wrote:> Clean separation of behaviour from presentation?Presentation is not necessarily static, often it essentially involves behavior.> Encouraging people > to think of scripts as the applications that client side pages are > now becoming, rather than just little bits tacked on?To me that''s a strawman as no one in Rails-land advocates or practices pouring large amounts of implementation scripts into pages. What the javascript helpers currently do, and what I do in my own pages/scripts, is wiring together JavaScript functionality implemented in external files. Particularly when these "wiring" scripts are dynamic, which they always are when arguments need to be passed from Rails to JavaScript, putting the JavaScript right there in the page avoids considerable complexity. Doing the same with completely unobtrusive JavaScript, where *all* JavaScript code is kept in external files, may not be impossible. It''s definitely more complex and more work.> Well, worth it, IMO.With the options somewhat clarified -- how do you evaluate the issue now? Michael -- Michael Schuerig Face reality and stare it down mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org --Jethro Tull, Silver River Turning http://www.schuerig.de/michael/
I''m with Michael here... I look at this and fail to see what I gain other than headaches... Give me some serious details of how on a practical level this helps me... _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
I use it. But, I know it well never be widespread, too many programmers have the mentality that "it''s just HTML." Kind of a lost argument TBH. There are no realistic objections to this, I''ve heard them all and every single one comes from ignorance of HTML/CSS/JavaScript capabilities. I say, just use it on your own - who needs the helpers anyway? You can just as easily write your own helpers if you please. For me, it saves me hours of work in the long haul to use libraries like this, because I know how to use them. Once I get one of my sites that uses this heavily live, I''ll be sure to show it to the mailing list and show them how to do things right. On 7/21/05, Sean T Allen <sean-5W9FBhQXBOtBDgjK7y7TUQ@public.gmane.org> wrote:> I''m with Michael here... > > I look at this and fail to see what I gain other than headaches... > > Give me some serious details of how on a practical level this > helps me... > > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > >-- Kyle Neath kneath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org http://www.neathdesign.com
The big difference between the tag soup days and what we are doing with Rails today is most of the javascript in a Rails application is generated at run time. It isn''t hardcoded in the files so designers need not worry themselves with trying to poor over it. I like Behaviour and think it has its place, but it doesn''t involve replacing the ''generated javascript'' Rails spits out. -Justin On 7/21/05, Sean T Allen <sean-5W9FBhQXBOtBDgjK7y7TUQ@public.gmane.org> wrote:> > I''m with Michael here... > > I look at this and fail to see what I gain other than headaches... > > Give me some serious details of how on a practical level this > helps me... > > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 7/21/05, Sean T Allen <sean-5W9FBhQXBOtBDgjK7y7TUQ@public.gmane.org> wrote:> I''m with Michael here... > > I look at this and fail to see what I gain other than headaches...Inline scripting negates a lot of the organizational benefits that come from using structural xhtml and css layouts. If you''re going to embed javascript, why not embed tables and other presentation elements, too? Tyler
On Thursday 21 July 2005 21:42, Kyle Neath wrote:> I use it. But, I know it well never be widespread, too many > programmers have the mentality that "it''s just HTML." > > Kind of a lost argument TBH. There are no realistic objections to > this, I''ve heard them all and every single one comes from ignorance > of HTML/CSS/JavaScript capabilities.Well, then please make a Kantian move here and help us emerge from our self-incurred immaturity. Michael -- Michael Schuerig Life is just as deadly mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org As it looks http://www.schuerig.de/michael/ --Richard Thompson, Sibella
Tyler Kiley wrote:>On 7/21/05, Sean T Allen <sean-5W9FBhQXBOtBDgjK7y7TUQ@public.gmane.org> wrote: > > >>I''m with Michael here... >> >>I look at this and fail to see what I gain other than headaches... >> >> > >Inline scripting negates a lot of the organizational benefits that >come from using structural xhtml and css layouts. If you''re going to >embed javascript, why not embed tables and other presentation >elements, too? > >Again... how in a **dynamic rails served application** are these ''organizational benefits'' going to save me time? Because if organizing something and it doesnt save me time now or in the future... I don''t see the point. I''m not saying that I think this is a bad idea... I just see more work for rewards that no one can show me a practical application of.. ( although I have seen a few snotty little comments... ) I can see the reasons for the css selector based for non-transient pages... otherwise from what i read i see that i either have to 1. create a file with all my actions why on earth would i be using rails if I wanted to do this? 2. have a file that is dynamically generated now you go this direction and i might start to get interested. but there is a decent amount of work to get started on something like this... which leads me back to... what benefit do i really get for dynamically generated pages? _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Rails could spit out generated code that ties into Behaviour stuff which would also be generated by Rails. If done like this there would be no difference for developers, only the output would be different, and it would have backwards compatibility, would degrade gracefully, and the output would be cleaner. I''m not sure what headaches it would cause, since the end result in functionality would not change, nor would the helpers that developers use to implement the functionality have to change. I think it''s a mistake to sweep accessibility, structure, degradation, etc. under the carpet for no apparent reason. It would save some headaches to have it implemented, because then we would no longer have to worry about accessibility and backwards compatibility - which, by default, you do now. There are a lot of benefits to having an accessible website. For one, it''s accessible! As it is, it''s kind of dangerous to use AJAX. Sure, for most people it''ll work fine... But when you have core functionality using it, there should be a fallback.
On Thursday 21 July 2005 23:02, Jerrett Taylor wrote:> Rails could spit out generated code that ties into Behaviour stuff > which would also be generated by Rails.If I''m not mistaken, rendering would have to be changed considerably. Basically, there would have to be two output channels, one for the page proper, another for a page-specific script file.> I think it''s a > mistake to sweep accessibility, structure, degradation, etc. under > the carpet for no apparent reason. It would save some headaches to > have it implemented, because then we would no longer have to worry > about accessibility and backwards compatibility - which, by default, > you do now.I''m unable to follow this argument. Most likely because I don''t share the unstated assumptions. Let''s see. I take it that all participants in the discussion agree that accessibility, well-structuredness of artifacts programmers have to work with, and graceful degradation on less-capable browsers are all worthy goals. Where we disagree, apparently, is what means are useful and or necessary to attain these goals. Some claim that the goals can only be achieved by a strict separation of (X)HTML, CSS, and JavaScript in their own files. Others, including myself, are skeptical regarding the necessity and practical value of completely detaching the JavaScript code. Bear in mind that the (X)HTML we''re talking about that might get intermixed with JavaScript code is not one of the primary artifacts any developer is working on. Of course, it better be generated from cleanly structured code with all concerns nicely separated. There are several constraints that can usefully be imposed on the generated (X)HTML: It has to be valid. It should not be unnecessarily large; i.e., common assets ought to be factored out. Layout and initial script execution should be fast. The separation of (X)HTML and JavaScript doesn''t figure here, as far as I can tell. Also, don''t ignore the fact that, even with everything neatly separated, it is quite possible to create pages that are a completely unusable mess, are ill-structured, and don''t degrade nicely at all, but just fail. Michael -- Michael Schuerig They tell you that the darkness mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org Is a blessing in disguise http://www.schuerig.de/michael/ --Janis Ian, From Me To You
Behavior is a neat idea, but the trade-offs for Rails doesn''t appear worth it: * It doesn''t work with caching becuase content_for :script doesn''t. * Even if it did, it would only move the scripts to the head, and not to an external file, so there''s no savings in file size * It would require all templates to have a @content_for_script or similar or any js functions wouldn''t work So. Neat idea. Potentially cool if you''re writing all your js by hand. Not worth it for Rails, though. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
> Presentation is not necessarily static, often it essentially involves > behavior.I don''t understand what you mean by this.> To me that''s a strawman as no one in Rails-land advocates or practices > pouring large amounts of implementation scripts into pages.But I think they do. I''ve been reading on here that people are planning to put <script> elements inline in their HTML code (inside the <body>), and I have *never* seen a situation when that is a) necessary or b) a good idea.> What the javascript helpers currently do, and what I do in my own > pages/scripts, is wiring together JavaScript functionality implemented > in external files.This I am totally in favour of, but I''m in favour of keeping the JS in the pages to an absolute minimum.> Particularly when these "wiring" scripts are dynamic, which they > always are when arguments need to be passed from Rails to JavaScript, > putting the JavaScript right there in the page avoids considerable > complexity.This is what I just don''t see.> With the options somewhat clarified -- how do you evaluate the issue > now?I guess I don''t quite understand to what extent you''re talking about generating JS based on dynamic page concerns. At the end of the day, you have to write JS to handle each use case for each dynamic element in your page. There''s just no way around that. I don''t see that it''s that much harder to place small hooks in your pages to JS code that you have properly structured in external files. It''s just good programming practice. As an example, here''s a simple JS application I wrote a couple of years ago while I was learning spanish. You can download the source right from the site. It''s fairly old and I wouldn''t implement it like this now (I''d use less JS ;-)) but it gives you an idea of what I''m talking about. The verb drills page is the most interesting from a DHTML point of view. It''s a very dynamic site (although it''s small), all on one DHTML page, but there''s a sum total of less than 10 event handler hooks, and no inline JS at all. It wasn''t hard to write like that, and when I eventually rewrite it, I''ll feed the conjugation and vocabulary data from Rail but keep the JS separated. http://cavesvr.caverock.com/~colin/spanish/spanish.html Warning: it looks horrible and may make your eyes bleed. I guess at the end of the day I''m not trying to convince anyone that my way is the right way, just trying to give some insight into how and why I make my design decisions. Programming is an art, after all, and after a while you get a ''feel'' for what is good design, as the rules become automatic. Putting heaps of JS in the pages just screams "bad code smell" to me (plus the fact that my current day job project is a nightmare for this very reason). Colin
While I don''t have an informed enough opinion on accessibility concerns
to comment on that aspect of it, I can say from our projects here that
Behaviour has completely changed the way I think about the DOM tree and
its manipulation through javascript.
Take a simple example like a nav menu with rollover and selected divs.
You click on one element, and your script goes through all of the divs
in that menu and sets them to unselected, then sets the clicked one to
selected.
Whereas I used to do this by catching the event and traversing the DOM
to find the parent, then all of its child items, now I can do the
following (simplified and ugly but gets the point across):
$("item1").onclick = function(event) {
var rules = {
"div.menuitem": function(element) {
element.className = "menuitem normal";
}
}
Behaviour.register(rules);
Behaviour.apply();
Behaviour.list = new Array() // clear the behaviour list to avoid
duplicate calls
event.target.className = "menuitem selected";
}
Now, if I change around the HTML structure of the menu, I won''t break
my JS as long as the class names stay the same. This decoupling has
saved me many headaches.
Anyone else doing this as well?
Ben
___________________
Ben Jackson
Diretor de Desenvolvimento
ben-p14LI7ZcAE/pVLaUnt/cCQC/G2K4zDHf@public.gmane.org
http://www.incomumdesign.com
On Friday 22 July 2005 01:45, Colin Fleming wrote:> > Presentation is not necessarily static, often it essentially > > involves behavior. > > I don''t understand what you mean by this.That presentation is not just look, but feel and behavior, too. The presentation layer of an application consists of way more things than a designer could create in PhotoShop.> > To me that''s a strawman as no one in Rails-land advocates or > > practices pouring large amounts of implementation scripts into > > pages. > > But I think they do. I''ve been reading on here that people are > planning to put <script> elements inline in their HTML code (inside > the <body>), and I have *never* seen a situation when that is a) > necessary or b) a good idea.Two things. Firstly, people don''t put the script elements in the HTML. They''re put there by Rails helper methods. The important difference is that the logical separation of concerns is still upheld. Also, it''s not as if there''s a lot of code in the script elements. Mostly it is concerned with wiring things together. Second, what''s the moral difference between <input type="button" onclick="doSomething(); return false" /> and <input type="button" id="mybutton" /> <script type="text/javascript"> //<![CDATA[ Event.observe(''mybutton'', doSomething); //]]> </script>> > With the options somewhat clarified -- how do you evaluate the > > issue now? > > I guess I don''t quite understand to what extent you''re talking about > generating JS based on dynamic page concerns. At the end of the day, > you have to write JS to handle each use case for each dynamic element > in your page. There''s just no way around that. I don''t see that it''s > that much harder to place small hooks in your pages to JS code that > you have properly structured in external files. It''s just good > programming practice.So it boils down to that we disagree about the size and kind of the hooks. Here''s some code from Thomas''s demo page for autocomplete text fields (formatted for slighly easier readability) <input autocomplete="off" id="message_to" name="message[to]" size="30" type="text" value="" /> <div class="auto_complete" id="message_to_auto_complete"></div> <script type="text/javascript"> new Ajax.Autocompleter(''message_to'', ''message_to_auto_complete'', ''/demos/ajax/auto_complete_for_message_to'', {}) </script> How would you improve on this?> As an example, here''s a simple JS application I wrote a couple of > years ago while I was learning spanish. You can download the source > right from the site. It''s fairly old and I wouldn''t implement it like > this now (I''d use less JS ;-)) but it gives you an idea of what I''m > talking about. The verb drills page is the most interesting from a > DHTML point of view. It''s a very dynamic site (although it''s small), > all on one DHTML page, but there''s a sum total of less than 10 event > handler hooks, and no inline JS at all. It wasn''t hard to write like > that, and when I eventually rewrite it, I''ll feed the conjugation and > vocabulary data from Rail but keep the JS separated. > > http://cavesvr.caverock.com/~colin/spanish/spanish.htmlIf that''s the kind of application you''re thinking of when discussing this issue, then I agree with you -- and claim that it is not relevant. In my classification your app is fully static. For me a dynamic application is one where pages are created based on database content, computations, and templates. In an application like yours, you can hand-tune everything; in principle the JavaScript code can be written assuming complete knowledge of the DOM-tree of the page. Put to the extreme, the result would be strictly separated, but very brittle code, where the JavaScript is sprinkled with assumptions about the HTML. Let a web designer loose on the HTML to make over the looks and afterwards none of the scripts would work anymore. Note that I don''t claim that''s the case with your code.> I guess at the end of the day I''m not trying to convince anyone that > my way is the right way, just trying to give some insight into how > and why I make my design decisions. Programming is an art, after all, > and after a while you get a ''feel'' for what is good design, as the > rules become automatic. Putting heaps of JS in the pages just screams > "bad code smell" to me (plus the fact that my current day job project > is a nightmare for this very reason).Well, you may not be trying to convince anyone, but in effect you''re telling me and others that we don''t have the right ''feel'' for good design and are producing smelly code. I don''t agree, obviously. Regarding the code smell, I''d like to know what exactly the problems are with JavaScript in the page. When you treat generated HTML appropriately, namely just like binary code, bytecode, and other products of generators, then I don''t see a problem as long as the product is valid (cf. my previous message for other constraints). Presumably, the problem with JS-in-page you''re experiencing in your day job project is only a symptom of another problem. Michael -- Michael Schuerig You can twist perceptions mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org Reality won''t budge http://www.schuerig.de/michael/ --Rush, Show Don''t Tell
And I''m not sure STILL... why this isnt possible not using Behavior... I keep seeing these Behavior changed my life post on this thread... but no concrete examples that I havent done equally well in some other fashion ( or at least think I have done equally well ). Either its a lot of smoke ( which I doubt ) or I''m just missing something... and it frustrating the hell out of me... Or perhaps, to paraphrase Michael from a different post.. the basic axioms we are operating under, definitely dont agree... Benjamin Jackson wrote:> While I don''t have an informed enough opinion on accessibility > concerns to comment on that aspect of it, I can say from our projects > here that Behaviour has completely changed the way I think about the > DOM tree and its manipulation through javascript. > > Take a simple example like a nav menu with rollover and selected divs. > You click on one element, and your script goes through all of the divs > in that menu and sets them to unselected, then sets the clicked one to > selected. > > Whereas I used to do this by catching the event and traversing the DOM > to find the parent, then all of its child items, now I can do the > following (simplified and ugly but gets the point across): > > $("item1").onclick = function(event) { > var rules = { > "div.menuitem": function(element) { > element.className = "menuitem normal"; > } > } > Behaviour.register(rules); > Behaviour.apply(); > Behaviour.list = new Array() // clear the behaviour list to avoid > duplicate calls > event.target.className = "menuitem selected"; > } > > Now, if I change around the HTML structure of the menu, I won''t break > my JS as long as the class names stay the same. This decoupling has > saved me many headaches. > > Anyone else doing this as well? > > Ben > ___________________ > Ben Jackson > Diretor de Desenvolvimento > > ben-p14LI7ZcAE/pVLaUnt/cCQC/G2K4zDHf@public.gmane.org > http://www.incomumdesign.com > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Michael, The simple fact of the matter is that it''s the same idea as CSS. Exact same. If you can see the benefits in CSS, you should see the benefits in using external javascript files. And, no, rendering would not have to change drastically. It would be relatively simple, in fact - just grab all the neccecary stuff, and spit it into something like @content_for_script. It would require a little bit of effort, but not a lot. The benefits? Drastic, if you are one to see not only what works today, but what will work tomrrow, and enahcing upon that. Imagine, for instance, a remote form tag that worked this way: <form action = "/ajaxcontroller/ajaxaction" method="post" update="myid"> Using behaviour, that''s all you''d need with some simple modifications. Sure it wouldn''t be "validated" code, but that could easily be solved with a new DTD if you were so inclined. Using a consolidated ajax function, reading from custom attributes this would cut down on code dramatically. Only one remote form function per page, with unlimited remote forms per page. Think about it in terms of being able to specify the behaviour of an expandable list by simply adding <ul class="expand"> to it. (Something I do). Think about it in terms of simplifying remote calls. <a href="/action/to/grab" update="updateid">Update another element</a>. Think about code portability. Think about flexibility. Like I said previously, a lot of the "can''t be dones" or "no need to do it" stem from ignorance of HTML/CSS/JavaScript. Don''t take it in offense. I don''t claim to be a Rails expert - but I will say I know my stuff front-end. I don''t get offended when someone shows me a better way to do something - however programmers tend to, and it''s a shame. Let''s break it down really simply. Say you want to apply a puff effect on a link to something you delete. Say your structure is like this: <div class="item"> <a href="#">Item goes here</a> <a href="/item/delete/15">Delete</a> </div> That''s *all the markup you would need* when applying behaviour to give that effect on it. Say later you decided you wanted all items that are deleted - site wide - to change to a scale effect. Change one line of code in behaviour, or 20 view files. That''s the power right there. On 7/21/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote:> On Friday 22 July 2005 01:45, Colin Fleming wrote: > > > Presentation is not necessarily static, often it essentially > > > involves behavior. > > > > I don''t understand what you mean by this. > > That presentation is not just look, but feel and behavior, too. The > presentation layer of an application consists of way more things than a > designer could create in PhotoShop. > > > > > To me that''s a strawman as no one in Rails-land advocates or > > > practices pouring large amounts of implementation scripts into > > > pages. > > > > But I think they do. I''ve been reading on here that people are > > planning to put <script> elements inline in their HTML code (inside > > the <body>), and I have *never* seen a situation when that is a) > > necessary or b) a good idea. > > Two things. Firstly, people don''t put the script elements in the HTML. > They''re put there by Rails helper methods. The important difference is > that the logical separation of concerns is still upheld. Also, it''s not > as if there''s a lot of code in the script elements. Mostly it is > concerned with wiring things together. > > Second, what''s the moral difference between > > <input type="button" onclick="doSomething(); return false" /> > > and > > <input type="button" id="mybutton" /> > <script type="text/javascript"> > //<![CDATA[ > Event.observe(''mybutton'', doSomething); > //]]> > </script> > > > > > With the options somewhat clarified -- how do you evaluate the > > > issue now? > > > > I guess I don''t quite understand to what extent you''re talking about > > generating JS based on dynamic page concerns. At the end of the day, > > you have to write JS to handle each use case for each dynamic element > > in your page. There''s just no way around that. I don''t see that it''s > > that much harder to place small hooks in your pages to JS code that > > you have properly structured in external files. It''s just good > > programming practice. > > So it boils down to that we disagree about the size and kind of the > hooks. Here''s some code from Thomas''s demo page for autocomplete text > fields (formatted for slighly easier readability) > > <input autocomplete="off" > id="message_to" name="message[to]" > size="30" type="text" value="" /> > <div class="auto_complete" id="message_to_auto_complete"></div> > <script type="text/javascript"> > new Ajax.Autocompleter(''message_to'', ''message_to_auto_complete'', > ''/demos/ajax/auto_complete_for_message_to'', {}) > </script> > > How would you improve on this? > > > > As an example, here''s a simple JS application I wrote a couple of > > years ago while I was learning spanish. You can download the source > > right from the site. It''s fairly old and I wouldn''t implement it like > > this now (I''d use less JS ;-)) but it gives you an idea of what I''m > > talking about. The verb drills page is the most interesting from a > > DHTML point of view. It''s a very dynamic site (although it''s small), > > all on one DHTML page, but there''s a sum total of less than 10 event > > handler hooks, and no inline JS at all. It wasn''t hard to write like > > that, and when I eventually rewrite it, I''ll feed the conjugation and > > vocabulary data from Rail but keep the JS separated. > > > > http://cavesvr.caverock.com/~colin/spanish/spanish.html > > If that''s the kind of application you''re thinking of when discussing > this issue, then I agree with you -- and claim that it is not relevant. > In my classification your app is fully static. For me a dynamic > application is one where pages are created based on database content, > computations, and templates. In an application like yours, you can > hand-tune everything; in principle the JavaScript code can be written > assuming complete knowledge of the DOM-tree of the page. > > Put to the extreme, the result would be strictly separated, but very > brittle code, where the JavaScript is sprinkled with assumptions about > the HTML. Let a web designer loose on the HTML to make over the looks > and afterwards none of the scripts would work anymore. Note that I > don''t claim that''s the case with your code. > > > > I guess at the end of the day I''m not trying to convince anyone that > > my way is the right way, just trying to give some insight into how > > and why I make my design decisions. Programming is an art, after all, > > and after a while you get a ''feel'' for what is good design, as the > > rules become automatic. Putting heaps of JS in the pages just screams > > "bad code smell" to me (plus the fact that my current day job project > > is a nightmare for this very reason). > > Well, you may not be trying to convince anyone, but in effect you''re > telling me and others that we don''t have the right ''feel'' for good > design and are producing smelly code. I don''t agree, obviously. > > Regarding the code smell, I''d like to know what exactly the problems are > with JavaScript in the page. When you treat generated HTML > appropriately, namely just like binary code, bytecode, and other > products of generators, then I don''t see a problem as long as the > product is valid (cf. my previous message for other constraints). > Presumably, the problem with JS-in-page you''re experiencing in your day > job project is only a symptom of another problem. > > > Michael > > -- > Michael Schuerig You can twist perceptions > mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org Reality won''t budge > http://www.schuerig.de/michael/ --Rush, Show Don''t Tell > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Kyle Neath kneath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org http://www.neathdesign.com
On Jul 21, 2005, at 7:38 PM, Kyle Neath wrote:> Michael, > > The simple fact of the matter is that it''s the same idea as CSS. Exact > same. If you can see the benefits in CSS, you should see the benefits > in using external javascript files. > > And, no, rendering would not have to change drastically. It would be > relatively simple, in fact - just grab all the neccecary stuff, and > spit it into something like @content_for_script. It would require a > little bit of effort, but not a lot.I''ve just been lurking in this discussion, siding mostly with DHH and Michael, but I had to pop in at this statement. "It would require a little bit of effort, but not a lot." Such an easy thing to say. I''m sure every programmer alive has been guilty of saying that at some point in their careers. Probably multiple times. But the proof, as they say, is in the pudding. Rather than talking and talking and talking (and talking around each other mostly), what I''d like to see is an actual, living-and-breathing implementation of Behavior-based Ajax helpers for Rails, in patch form, for application to the Rails code-base. Once I see this, I think it will be easier for myself (and others) to understand the approach you are advocating. As it is, I don''t think either side is doing a very good job of expressing their hidden assumptions, or understanding the hidden assumptions of the other side''s argument. - Jamis
On 22/07/2005, at 11:36 AM, Sean T Allen wrote:> I keep seeing these Behavior changed my life post on this thread... > but no concrete examples that I havent done equally well in some other > fashion ( or at least think I have done equally well ). > > Either its a lot of smoke ( which I doubt ) or I''m just missing > something... > and it frustrating the hell out of me...I think it''s just that some people are starting to grasp the benefits of higher order programming techniques, and the Behaviour library makes it really accessible to people who are new to this stuff. You could rewrite the old code: $("item1").onclick = function(event) { var rules = { "div.menuitem": function(element) { element.className = "menuitem normal"; } } Behaviour.register(rules); Behaviour.apply(); Behaviour.list = new Array() // clear the behaviour list to avoid duplicate calls event.target.className = "menuitem selected"; } w/o the Behaviour library, like this: $("item1").onclick = function(event) { $$("div.menuitem").map(function(_) { _.className = "menuitem normal"; // could also use _.addClassName('''') and _.removeClassName('''') here instead } event.target.className = "menuitem selected"; } And if instead of just "item1" you wanted to apply the onclick for all elements matching ''div.menuitem'' you could do the following: $$("div.menuitem").map(function(menuitem) { menuitem.onclick = function(event) { $$("div.menuitem").map(function(_) { _.className = "menuitem normal"; } event.target.className = "menuitem selected"; } } ''map'' would need to be added to the Array object''s prototype, and ''$$'' would be a global convenience function just like prototype''s $ function, but instead of taking an element ID it would take a CSS selector. I think the Behaviour library deserves full cred because: 1) It helps to break down the perceived barrier of entry to JS programming for those who know CSS. 2) Its allowing people to write cleaner JS w/o having to know about using higher order functions (such as the proposed ''map'') 3) Its notation is immediately understandable for webdesigner types 3) Its an original and funky idea When a person becomes more comfortable with JS then I''d imagine them moving away from using the Behaviour library, if only for conciseness. - tim lucas
Jamis, I think what people are missing here is that extra writing to external javascript files would not be required by the page rendering. The idea is to add to the semantic nature of the HTML - NOT add to the javascript pieces. That''s why it wouldn''t be that much work. The only work required would be to gradually rewrite the form helpers to write HTML and not inline javascript handlers. No back / forth, etc. I''ve had some time to think about this and I''ve got some (what I think) are good ideas. If you rewrite behaviour to add an onsubmit handler to a form tag with a class of "remote" that reads from custom attributes - you would have one form remote function that would live in some library file somewhere. It doesn''t mean writing an onsubmit handler for each specific remote form. Perhaps if I have a bit of time, I can demonstrate what I mean because I think people are still thinking backwardsly, and not forwards. It''s not an easy concept to grasp :)
For those still interested, I''ve expanded upon the topic on my blog here: http://warpspire.com/blog/the-web/cleaning-up-rails-tag-soup Maybe next week I''ll have some extra time to throw together a working prototype as words only go so far. -Kyle
On Friday 22 July 2005 05:14, Tim Lucas wrote:> I think the Behaviour library deserves full cred because: > 1) It helps to break down the perceived barrier of entry to JS > programming for those who know CSS. > 2) Its allowing people to write cleaner JS w/o having to know > about using higher order functions (such as the proposed ''map'') > 3) Its notation is immediately understandable for webdesigner > types 3) Its an original and funky ideaI agree on all counts. I contest that this means that behaviour way is the best way for Rails to implement its JavaScript-related functionality under the hood. What dampens my enthusiasm is that when I look at the Behaviour home page at <http://www.ripcord.co.nz/behaviour/> I get JavaScript errors in both Firefox (1.0.4) and Konqueror (3.4.1). Michael -- Michael Schuerig Not only does lightning not strike mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org twice, it usually doesn''t strike once. http://www.schuerig.de/michael/ --Salman Rushdie, Fury
On Friday 22 July 2005 03:38, Kyle Neath wrote:> The benefits? Drastic, if you are one to see not only what works > today, but what will work tomrrow, and enahcing upon that.You know, this is the kind of roundabout statement that piques me.> Like I said previously, a lot of the "can''t be dones" or "no need to > do it" stem from ignorance of HTML/CSS/JavaScript. Don''t take it in > offense. I don''t claim to be a Rails expert - but I will say I know > my stuff front-end. I don''t get offended when someone shows me a > better way to do something - however programmers tend to, and it''s a > shame.Let''s be very specific. How would the behaviour approach improve on the current state of pages generated by Rails? Mind you, we''re talking about *generated* HTML. Yes, it may have some similarity to HTML written by hand, but technically it is equivalent to executable code or postscript data. Michael -- Michael Schuerig There is no matrix, mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org only reality. http://www.schuerig.de/michael/ --Lawrence Fishburn
> Well, you may not be trying to convince anyone, but in effect you''re > telling me and others that we don''t have the right ''feel'' for good > design and are producing smelly code. I don''t agree, obviously.It''s not my intention to tell you you don''t know how to design code. We all make design choices all the time, and generally there''s no right or wrong answer.> Regarding the code smell, I''d like to know what exactly the problems are > with JavaScript in the page. When you treat generated HTML > appropriately, namely just like binary code, bytecode, and other > products of generators, then I don''t see a problem as long as the > product is valid (cf. my previous message for other constraints).I guess the fundamental difference in our arguments is that I don''t consider the generated HTML as something to be treated as invisible like binary code. Whether that''s appropriate or not is a matter of taste.> Presumably, the problem with JS-in-page you''re experiencing in your day > job project is only a symptom of another problem.That''s a pretty big presumption :) Sorry, I wish I had more time to comment on this, but I''m about to go on holiday and I''m tied up at work. Plus I agree with Jamis - I think we''re mostly talking round each other when at the end of the day it''s a preference for one technique or the other. People seem to be asking for an example of using Rails with Behaviour - I''ll try to roll something up in the app I''m working on at home but it won''t be too soon since I''m learning Rails and don''t know Behaviour yet, and I''ll be on holiday for a week. Colin
On 22/07/2005, at 5:46 PM, Michael Schuerig wrote:> On Friday 22 July 2005 05:14, Tim Lucas wrote: >> I think the Behaviour library deserves full cred because: >> 1) It helps to break down the perceived barrier of entry to JS >> programming for those who know CSS. >> 2) Its allowing people to write cleaner JS w/o having to know >> about using higher order functions (such as the proposed ''map'') >> 3) Its notation is immediately understandable for webdesigner >> types 3) Its an original and funky idea > > I agree on all counts. I contest that this means that behaviour way is > the best way for Rails to implement its JavaScript-related > functionality under the hood.I also agree that Behaviour shouldn''t be used by the javascript helpers (its not really even possible). I''d like to see another set of JS helpers (which would need a slightly different API) for use on public facing websites (as opposed to webapplications) where accessibility is paramount. Of course things like IDs and CSS selectors become a requirement once you go this route, hence making things a bit more difficult to maintain. When I need them I''ll write them and submit as a patch, but at the moment it''s not a priority. - tim lucas
On 7/21/05, Jerrett Taylor <jerrett-7g3wz9A/6AxWk0Htik3J/w@public.gmane.org> wrote:> http://www.ripcord.co.nz/behaviour/ > > has anyone played with using this in rails... and is anyone working on > integrating it? > > Would be nice if the ajax helpers used this :)Hello Jerrett, the ajax infrastructure in Nitro transparently uses behaviour.js along with prototype/script.aculo.us to fully separate javascript and xhtml code. Have a look at www.nitrohq.com and the included ajax (preview) example. Even though this feature is considered a preview at the moment, it shows that the integration can be done. Moreover, expect to see some interesting side-effects of this integration in a forthcoming release. regards, George. -- http://www.nitrohq.com
On Friday 22 July 2005 09:36, Kyle Neath wrote:> For those still interested, I''ve expanded upon the topic on my blog > here: http://warpspire.com/blog/the-web/cleaning-up-rails-tag-soupI think you''re confusing two things: On the one hand, JavaScript code put into to generated pages by Rails helpers methods, on the other hand, JavaScript code written explicitly by developers. The code you''re complaining about in your blog entry is in the first category. Code like that is not for human beings to interact with, it''s generated after all. Also, there''s a good chance that a future version of Rails will generate entirely different code -- which is fine as the code is meant to be a black box. For code in the second category, I''m very much in favor of declaratively connecting JavaScript and HTML. See my mostly-declarative client-side validator for an example <http://www.schuerig.de/michael/javascript/#id2477426>. With it you can write HTML like this <input type="text" class="mandatory" /> <input type="text" class="numeric" /> <input type="text" class="date" /> <input type="text" class="validate_different_1" /> <input type="text" class="validate_different_1" /> (These two fields are in the same group -- 1 -- and must have different values.) There still has to be some minuscule bit of JavaScript and I really don''t see what''s bad about that: <script type="text/javascript"> //<![CDATA[ Event.observe(window, ''load'', function() { Form.Validator.installForAllForms({''validators'':Validators}); return true; }); //]]> </script> On a less serious note, isn''t it ironic that your blog page exemplifies all the bad practices? Not your fault, of course. The first thing I see in Konqueror is a JavaScript error caused by the function below (formatted for better readability) function liveSearchInit() { if (navigator.userAgent.indexOf("Safari") > 0) { document.getElementById(''livesearch''). addEventListener("keydown",liveSearchKeyPress,false); } else if (navigator.product == "Gecko") { document.getElementById(''livesearch''). addEventListener("keypress",liveSearchKeyPress,false); } else { document.getElementById(''livesearch''). attachEvent(''onkeydown'',liveSearchKeyPress); isIE = true; } } DOM-based capability detection -- "if (element.addEventListener) { ... }" -- would have saved the day. Even better, Prototype.js already takes care of this as well as of the special case for Safari and other khtml-based browsers. Michael -- Michael Schuerig I am the sum total of the parts mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org I control directly. http://www.schuerig.de/michael/ --Daniel C. Dennett, Elbow Room
So after reading the blog I ask this question... tag soup... not good... but... if I am programatically creating said tag soup... and I have already take everything on the backend and moved creation of said soup into helpers where i can easily change the tags across the board... what do i get from your approach? and yes i am defiantly looking forward to someone having time to mock up a real practical example... a few quotes... ** Now, what''s so great about this? That javascript can stay in the browsers cache and work for /any/ remote form tag. i''ll call that a minor point ** Just adding the class "remote" makes it a remote form - adding "highlight" highlights the updated element. i already use this - for example, tables that rule themselves based on css class name because i think that the client end is place to deal with ruling ( as it also allows me to do rule along with client side sorting... ) but... i still dont see how this approach is a ''best practice'' for rails ( see below ) ** Let''s say some day down the road, there comes along a better AJAX library than prototype. Using the methods above, we can easily swap out libraries painlessly, without editing any HTML or view files. or I could have not put everything in my html and views to begin with... isnt that the point of the helpers? ** Let''s say you wanted to pop up a notice whenever an AJAX action happened - instead of editing potentially dozens of view files - you can edit one or two lines in your behavior rules again why would i have this in dozens of view files? that just bad across the board... ** Adding onloading, oncomplete, etc actions to each form tag. This should be in a separate associative array I believe, and clearly in an external JavaScript file (just as you would style a form with an external CSS file, you should style the behaviour of a form with an external JS file) the clearly in an external Javascript file part bothers me... why do i want to maintain another file for all these? when i can just add an onload event from my partials et al as needed... Kyle Neath wrote:>For those still interested, I''ve expanded upon the topic on my blog here: >http://warpspire.com/blog/the-web/cleaning-up-rails-tag-soup > >Maybe next week I''ll have some extra time to throw together a working >prototype as words only go so far. > >-Kyle >_______________________________________________ >Rails mailing list >Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >http://lists.rubyonrails.org/mailman/listinfo/rails > > > >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Hey guys. Let''s tone down the intensity a notch or two. I agree that I have a hard time seeing how Behavior can fit in smoothly with Rails right now, but I certainly don''t want to hold back Kevin or others from presenting a persuative argument in form of code. So let''s hold the hounds until a patch is ready. As we would say at 37signals, we''re not yet talking about something real. So let''s Get Real and take it from there. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
> So after reading the blog I ask this question...So after reading your response, I ask this question... If you guys are treating the generated HTML like write-only bytecode, you''d be happy using helper functions that style the page using <font> tags and non-semantic mark-up, and get rid of CSS as well, right? After all, people did it for years and it worked, and it''s relatively easy. If you want to change the look of the site, just change the helpers. If you don''t do this for the visual aspects of presentation, I don''t understand why you would do it for the behavioural aspects. IMO it brings the same class of benefits to the same class of problems. Colin
Colin Fleming wrote:>>So after reading the blog I ask this question... >> >> > >So after reading your response, I ask this question... > >If you guys are treating the generated HTML like write-only bytecode, >you''d be happy using helper functions that style the page using <font> >tags and non-semantic mark-up, and get rid of CSS as well, right? >After all, people did it for years and it worked, and it''s relatively >easy. If you want to change the look of the site, just change the >helpers. > > >If you are talking about small bits of dynamically generated html, I would say yes... If it works across browsers and is isolated to one place where it needs to be changed... I already have encapsulation so.. I don''t see what the issue would be... show me a benefit and why I should change it... If I was doing static content... I would be all over using behavious because it would give a great method of encapsulation. As I am dynamically generating content tho, I have a number of other means of encapsulation already available.>If you don''t do this for the visual aspects of presentation, I don''t >understand why you would do it for the behavioural aspects. IMO it >brings the same class of benefits to the same class of problems. > > >Well maybe that is because I do throw css out the window for small bits of dynamically generated html... I''m perfectly happy having a helper put a <font> tag in if it serves the end functionality.. and having an isolated font tag here or there is better than another css rule if that means that the css rules are smaller and easier to understand for the part where they matter... So far, all I''ve seen from this conversation are ''organizational benefits'' that for me aren''t benefits as I handle them in a different fashion. Can someone show me the benefits that are beyond organization? I''m quite willing to believe they exist, I just don''t see them and I don''t think anyone during this thread has pointed any out. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Because no one answered on that: -> window.onload will fire only after all page assets (read: images) are loaded. -> inline <script> tags will be executed when parsed. thus, in many apps, you just can''t use behaviour (as it is implemented right now). think about a blog. the first page holds X articles, and say there are Y pictures loaded with these. things like live search won''t work until after all images are loaded. thus, it''s often _not a good thing_ even if you get "cleaner" HTML output. it will break things. it''s not as easy and clean as it seems. No one talks about <font> tags. Thomas Am 22.07.2005 um 13:56 schrieb Colin Fleming:>> So after reading the blog I ask this question... >> > > So after reading your response, I ask this question... > > If you guys are treating the generated HTML like write-only bytecode, > you''d be happy using helper functions that style the page using <font> > tags and non-semantic mark-up, and get rid of CSS as well, right? > After all, people did it for years and it worked, and it''s relatively > easy. If you want to change the look of the site, just change the > helpers. > > If you don''t do this for the visual aspects of presentation, I don''t > understand why you would do it for the behavioural aspects. IMO it > brings the same class of benefits to the same class of problems. > > Colin > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On 7/22/05, Colin Fleming <colin.mailinglist-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > So after reading the blog I ask this question... > > So after reading your response, I ask this question... > > If you guys are treating the generated HTML like write-only bytecode, > you''d be happy using helper functions that style the page using <font> > tags and non-semantic mark-up, and get rid of CSS as well, right? > After all, people did it for years and it worked, and it''s relatively > easy. If you want to change the look of the site, just change the > helpers. > > If you don''t do this for the visual aspects of presentation, I don''t > understand why you would do it for the behavioural aspects. IMO it > brings the same class of benefits to the same class of problems.That demo is fine and dandy for the simplest of AJAX actions, but some of us use some more complex ones. One idea I had that might help, is the ability to pass in a callback object. Instead of setting the loading/complete/failure event handles, just pass in one object with the events you want to handle defined. var PageCallback = { loading: function(request) {}, complete: function(request) {} } I pretty much do this anyway, so all my ajax tweaking is done in external JS files. At any rate, why is there even any argument about this? I would think all you''d have to do is write your own BehaviorHelper module and some js extension to prototype, and submit a patch. If it works well and doesn''t break current behavior, I don''t see why it wouldn''t be accepted. -- rick http://techno-weenie.net
Well, I can see from the attitutde of others my previous stereotypes were exactly dead on. Most programmers think "it''s just HTML." If you''re not willing to open up your eyes and see the real world, I don''t see a point in presenting any well-structured arguments. No matter what anyone says, the bottom line is - most programmers don''t care. Then, their problems get passed on to people who actually know what they''re doing with HTML/JS/CSS and have to clean up their mess. I''ve seen it a hundred times over and over. Rick, did you care to actually read my entry, just out of curiosity :) I addressed any amount of complicated AJAX queries. But there''s no real problem here, other than some people are stuck in narrow minded habits, which is dissapointing to hear from a community so prided in using best principles and practices. Not having dozens of view files? Now, that''s ignorant right there. I would strive to bet that the great majority of Rails apps have at least a dozen view files. I''d have hoped this community would take up a better attitude towards this, and I suppose that''s why I keep arguing my point :) Somewhere there was the hope that programmers can change, but I guess not. The bottom line is: using behaviour rules and semantic HTML furthers the idea of DRY and extensibility of your application.
Wow. Could you please take a step back and not take this personally...? Heh, we''re just trying to code here. I''m sorry to say, but i can''t use the behavior library, because it will break my app. End of story. And i don''t want it forced on me by the framework. If anyone comes up with extensions so _I_ end up choosing if I want this stuff or not, that''s fine with me. Thanks, Thomas Am 22.07.2005 um 17:12 schrieb Kyle Neath:> If you''re not willing to open up your eyes and see the real world, I > don''t see a point in presenting any well-structured arguments. > But there''s no real problem here, other than some people are stuck in > narrow minded habits, which is dissapointing to hear from a community > so prided in using best principles and practices. >
Kyle Neath wrote:>Well, I can see from the attitutde of others my previous stereotypes >were exactly dead on. Most programmers think "it''s just HTML." > > >Who said that exactly? I don''t think anyone said that.>If you''re not willing to open up your eyes and see the real world, I >don''t see a point in presenting any well-structured arguments. No >matter what anyone says, the bottom line is - most programmers don''t >care. Then, their problems get passed on to people who actually know >what they''re doing with HTML/JS/CSS and have to clean up their mess. >I''ve seen it a hundred times over and over. > > >Constantly insulting people who want to see some ''proof'' isnt going to help convince anyone. You don''t convince skeptics by telling them they are backwards, wrong, stupid, lazy or any of the other insinuations that have been dropped during this thread.>Rick, did you care to actually read my entry, just out of curiosity :) >I addressed any amount of complicated AJAX queries. > >But there''s no real problem here, other than some people are stuck in >narrow minded habits, which is dissapointing to hear from a community >so prided in using best principles and practices. Not having dozens >of view files? Now, that''s ignorant right there. I would strive to >bet that the great majority of Rails apps have at least a dozen view >files. I''d have hoped this community would take up a better attitude >towards this, and I suppose that''s why I keep arguing my point :) >Somewhere there was the hope that programmers can change, but I guess >not. > > >You are talking about an organizational tool basically right? I personally said that I can get the same encapsulation using helpers AND already do... so I don''t find your arguments about easily making changes to carry much weight as I can already do that. I have already encapsulated the logic in one place... why my choice of how to organize makes me ''not willing to open up your eyes and see the real world'' is beyond me.>The bottom line is: using behaviour rules and semantic HTML furthers >the idea of DRY and extensibility of your application. >_______________________________________________ > >Saying it is one thing. Showing it is another. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Sean, and others - I apologize for any abusive tone I have taken previously in this thread... I just get really frustrated when others don''t read my responses, and argue against points I''ve already countered in previous writing :) I guess you guys need to take back and realize what the "average" programmers (I would hardly say any programmer who uses rails is average) so I continually battle arguments that it''s _my_ fault that when I gave them: <label>Test</label> and they gave me <td class="column15532"><div />Test</td> it displayed incorrectly. And why, it''s so easy to get angry at people for just assuming they can''t use it because it''ll break their current functionality, or create hours and hours of headaches. The vast majority of programmers are completely ignorant of HTML/JS/CSS. To me, it''s my job - so I take it seriously. It would be akin to some front-end designer talking to you and saying "Ruby on Rails won''t work for my project because it lacks feature x (when it does in fact exist) - use PHP instead." Would you not be angry at their lack of knowledge? That''s exactly my position currently :) That being said, seeing is believing. I''ve previously stated I plan on getting a working example going sometime soon. All I ask now is that you guys do the same. Don''t say something''s impossible without trying it out :) -- Kyle Neath kneath-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org http://www.neathdesign.com
Kyle Neath wrote:>Sean, and others - I apologize for any abusive tone I have taken >previously in this thread... I just get really frustrated when others >don''t read my responses, and argue against points I''ve already >countered in previous writing :) > >I guess you guys need to take back and realize what the "average" >programmers (I would hardly say any programmer who uses rails is >average) so I continually battle arguments that it''s _my_ fault that >when I gave them: <label>Test</label> and they gave me <td >class="column15532"><div />Test</td> it displayed incorrectly. And >why, it''s so easy to get angry at people for just assuming they can''t >use it because it''ll break their current functionality, or create >hours and hours of headaches. The vast majority of programmers are >completely ignorant of HTML/JS/CSS. To me, it''s my job - so I take it >seriously. It would be akin to some front-end designer talking to you >and saying "Ruby on Rails won''t work for my project because it lacks >feature x (when it does in fact exist) - use PHP instead." Would you >not be angry at their lack of knowledge? That''s exactly my position >currently :) > >That being said, seeing is believing. I''ve previously stated I plan on >getting a working example going sometime soon. All I ask now is that >you guys do the same. Don''t say something''s impossible without trying >it out :) > >Excellent I look forward to it... Areas that really interest me... 1. How you think the different organizational approach that this engenders... i.e. moving more logic to an external javascript file and encapsulating there vs. enscapsulation in helpers has an impact from a design end. I know css, html, and js but definately consider myself a programmer not a designer.. so another perspective is good. I''m particularly interested in this vis-a-vis dynamic database driven applications ( as more ''static'' type sites the advantage is quite obvious- to me at least ) 2. What additional functionality is made easier using behaviour that I would have to work using helpers for encapsulation. This is the ''what do I get''... question... _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
> I would like to hear the argument against this. If their is one. >So their is... I can see both sides of the argument. I''ll be looking forward to the results of the "show me don''t tell me" phase.
Only a fool would jump in at this point in the debate - but I''ve been called worse .... It seems to me that there is some serious talking past each other going on here. In particular, many of the people working with rails at this point are comfortable (and proficient?) at all levels of web application development - all the way from the database design to the css. And perhaps for those people, the Behaviour approach doesn''t really offer much. However, what I believe Kyle and others are talking about are situations where the roles are much more segregated: Alice does the database, Bob writes the web app proper, Jim handles the layout and interface. In this situation, Jim may not and really should not have to understand the intricate details of either the db or the web app, although he obviously needs to communicate with Alice and Bob over what kind of data is available and how it can be served, etc. In this kind of setup then, the more "pure" the HTML in rhtml (or whatever) templates can be, the better. And the Behaviour setup would seem you allow one to further segregate the presentation people into the HTML/CSS master and the JS wizard. Furthermore, for maintenance purposes, the greater the logical segregation, the better. It''s always going to be easier to replace a db OR rails OR presentation wizard than it will be to find a new db AND rails AND presentation master. Anyhoo, Flame On! --ryan
On Friday 22 July 2005 20:19, Ryan Raaum wrote:> However, what I believe Kyle and others are talking about are > situations where the roles are much more segregated: Alice does the > database, Bob writes the web app proper, Jim handles the layout and > interface. In this situation, Jim may not and really should not have > to understand the intricate details of either the db or the web app, > although he obviously needs to communicate with Alice and Bob over > what kind of data is available and how it can be served, etc. In > this kind of setup then, the more "pure" the HTML in rhtml (or > whatever) templates can be, the better. And the Behaviour setup > would seem you allow one to further segregate the presentation people > into the HTML/CSS master and the JS wizard.Ryan, you''re arguing for a worthy goal, but keep in mind the current realities of Rails. As it is, the web UI is constructed from ERb templates and helper methods. With these means, there is no way (no apparent one at least) to have a pure HTML/CSS designer create the view templates in their favorite web editor. Put bluntly, if anyone wants to *construct* a UI for a Rails app, they have to know a considerable amount about Rails. Now, a designer may create the HTML and CSS that determines how the application is meant to look. But the HTML markup needs to be translated into an rhtml template by someone with knowledge of Rails. If the web app has to contain JavaScript code apart from what Rails generates anyway, then the HTML/CSS expert and the JavaScript expert can each do their part of the job and use all the best techniques for separating their respective domain. Afterwards, though, the Rails expert will have to take the various pieces and arrange them in a way that makes sense for a dynamic, Rails-based web app. Yes, yes, it would be nice if this translation step wasn''t necessary. In Tapestry (Java), for instance, it is not. But have a look at the earlier discussion of Tapestry (somewhere around "Please no, not Railsestry"), to appreciate that excitement about a Tapestry-clone is not unanimous. Anyway, we''re not working in Tapestry, we''re using what Rails offers. Within these confines, it is hardly cut and dried that expelling every bit of JavaScript from *generated* pages would be any advantage. Michael -- Michael Schuerig All good people read good books mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org Now your conscience is clear http://www.schuerig.de/michael/ --Tanita Tikaram, Twist In My Sobriety
Very cool. This is similar to what I had in mind when i posted to the list... I still think it can be done in Rails. I agree with the "show don''t tell" side of things - I''m going away for a month though, so my main goal was to spark some discussion to get people thinking about it, see if anyone is already working on something like this for rails (which it seems somebody is), and draw some attention to it. In that, it seems I''ve been successful. I''m looking forward to seeing if anyone submits a patch. If not, maybe I''ll take a whack at it when I get back in September, but it seems Kyle is already poking at it. Thanks for the insight George! On Fri, 2005-07-22 at 12:35 +0300, George Moschovitis wrote:> On 7/21/05, Jerrett Taylor <jerrett-7g3wz9A/6AxWk0Htik3J/w@public.gmane.org> wrote: > > http://www.ripcord.co.nz/behaviour/ > > > > has anyone played with using this in rails... and is anyone working on > > integrating it? > > > > Would be nice if the ajax helpers used this :) > > Hello Jerrett, > > the ajax infrastructure in Nitro transparently uses behaviour.js along > with prototype/script.aculo.us to fully separate javascript and xhtml > code. Have a look at www.nitrohq.com and the included ajax (preview) > example. > > Even though this feature is considered a preview at the moment, it > shows that the integration can be done. Moreover, expect to see some > interesting side-effects of this integration in a forthcoming release. > > regards, > George. >
> > Ryan, you''re arguing for a worthy goal, but keep in mind the current > realities of Rails. As it is, the web UI is constructed from ERb > templates and helper methods. With these means, there is no way (no > apparent one at least) to have a pure HTML/CSS designer create the view > templates in their favorite web editor. Put bluntly, if anyone wants to > *construct* a UI for a Rails app, they have to know a considerable > amount about Rails.Yes, that is an accurate description of the current state of affairs. And I can use it, and the advantages and disadvantages have been argued several times over. Nonetheless, as I use more ajax/javascript, the views and partials become more and more php-like (in the way I didn''t like php - the logic and the data and the presentation all horribly mixed together). I assume at least half of this results from my ineptitude - but some part of it is inherent in the current setup. There may be no perfect system, but that doesn''t mean it''s not worth tweaking the current system here and there to try to improve it.> > Now, a designer may create the HTML and CSS that determines how the > application is meant to look. But the HTML markup needs to be > translated into an rhtml template by someone with knowledge of Rails. > If the web app has to contain JavaScript code apart from what Rails > generates anyway, then the HTML/CSS expert and the JavaScript expert > can each do their part of the job and use all the best techniques for > separating their respective domain. Afterwards, though, the Rails > expert will have to take the various pieces and arrange them in a way > that makes sense for a dynamic, Rails-based web app.And that may always be the case. Nonetheless, if the *generated* html is reasonably clean, then it will be much easier for an HTML/CSS expert to help me with presentation. I''m partially color-blind and design-impaired to boot - I do my best, but if I were going to launch a major site or try to sell something, I would need to consult with an expert. It would be nice if it was as painless as possible for both of us. Even if I do have to re-engineer the design back into the framework. Whatever the end result, I like the rails framework as a whole very much and will continue to work with it - but I''m certainly not vehemently against trying to make the current setup better.> > Yes, yes, it would be nice if this translation step wasn''t necessary. In > Tapestry (Java), for instance, it is not. But have a look at the > earlier discussion of Tapestry (somewhere around "Please no, not > Railsestry"), to appreciate that excitement about a Tapestry-clone is > not unanimous. > > Anyway, we''re not working in Tapestry, we''re using what Rails offers. > Within these confines, it is hardly cut and dried that expelling every > bit of JavaScript from *generated* pages would be any advantage. > > Michael > > -- > Michael Schuerig All good people read good books > mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org Now your conscience is clear > http://www.schuerig.de/michael/ --Tanita Tikaram, Twist In My Sobriety > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >