To be sure I correctly understand your answer: Inline events are events declared in the HTML ? <a href=".." onclick="..." >Click Me</a> or <script>stuff</script>
Well I agree this code is fast because it is directly bind to function. But as you said there is pros and cons. I wasn't thinking about this Web 0.1 feature because: 1. You mix HTML and JavaScript 2. Designer must understand the "magic" to write in the page In the real world: - You will have performance issue asking you to put code at the bottom of the page - Open API issue, the XHTML must be readable, can be parsed - People makes mistakes it is more complicated to write a <script> tag than simply class names In a generic Portal/CMS it is too complicated. Users need magic like "Put CSS class tooltip you will have a tooltip" or "Add class editable the field will be editable". It is so true that the developer of Lightview (Prototype Lightbox) do not clearly answer on it's ofuscated code behavior) and answer "don't use the code use html declaration only" :-) So at this point : - You can look for all '.myclass' in the document to bind stuff but you parse the document and pay for the parsing cost. In a previous version we play with Draggable in a Tree and it was really painfull. - You can use the bubbling pattern. I was really surprised by the speed of document event dispatching. Playing with http://thinkweb2.com/projects/prototype/detect-idle-state-with-custom-events/ it is really fast and convenient. About MemoryLeaks: Well I agree in theory we know how to handle memory leaks. In the real world, - Someone build a CMS - An other one use/include library - An other one code custom library with holes - Some beginers works on a the without memory leak knowledges ... Well a big mess where the must be called only when needed :-) Thanks for your answer Jp Jean-Philippe Encausse - Veille / R&D Jalios SA Jp [at] encausse.net - http://www.encausse.com - http://www.jalias.com GTalk: jp.encausse [at] gmail.com - SMS: sms [at] jp.encausse.net Mob: +33 6 82 12 56 99 - Job: +33 1 39 23 92 83 - Tel: +33 1 39 18 90 15 Do it Once, Use it Twice ~ Do it Twice, Make It Once On Wed, Jun 11, 2008 at 5:58 AM, kangax <[EMAIL PROTECTED]> wrote: > > There are no silver bullets. > Both event delegation and inline event handlers have their pros and > cons. The benefits of delegation could be easily outweighed by the > time it takes to traverse a deep document (think frequent events like > mousemove/over/out, window's "resize", etc.) Inline event handlerts on > the other hand are notorious for the maintanence nightmares they > bring. > When used appropriately, these techniques could defnitely make a huge > difference in app performance. > > - kangax > > On Jun 10, 5:07 am, "Jean-Philippe Encausse" <[EMAIL PROTECTED]> > wrote: >> A little question about "Why designer of JavaScript library are >> designing that way ?" >> >> 1. Context >> >> I'm developper on a CMS using Prototype/Scriptaculous as first >> JavaScript layer. >> - The CMS is using many library to handle tooltips, in place editing, >> contextual menu, ... >> - The CMS must have good response time. >> >> 2. Library >> >> Usally, library (like InPlaceEditor): >> - Provides a Class that will be created like: new Ajax.InPlaceEditor( >> element, url, {options}); >> - Code will be called "onload" on a $$('css on the page') >> >> 3. Issue >> >> So each time a page is displayed there is >> - $$('') parsing the page >> - Object created, Draggable, DOM Manipulation ... >> >> So each time the page is modifed with an Ajax update of the DOM the >> initialisation must be reroll ... >> >> 4. Solution >> >> We have made the choice to be lazy: >> >> 4.1 On load we listen on clic on the window/document >> 4.2 On click we look for a css class on the clicked element or one of >> it's parent >> 4.3 Then we initialise the good component. >> >> So pages are no longer slow down by parsing the DOM on load because we >> work on the element onclick. >> So the visitor who navigate from page to page don't pay the cost of $$() >> >> For instance: >> - On document click >> => We find a Span with class editInPlace >> => We create EditInPlace Editor >> => We call editor.enterEditMode('click'); >> >> - On document click >> => We find a link with a class ctxmenu >> => We made an AJAX Call to retrieve the menu >> => We display it >> >> We have made performance test: >> - It's faster >> - Less memory leak (no object created => gc later) >> >> 5. Question >> >> - Is there drawbacks with this solution ? >> - Why Libraries (InPlaceEditor, Prototip, ... ) do not use this design >> pattern ? >> >> => One drawback: You can't display visual effect on the page like >> AjaxInPlaceEditor highlighting. But in fact you can use at least CSS >> declaration. >> >> Best Regards, >> Jp >> >> PS: 6. Sample Code >> >> Event.observe(window, 'load' , function() { JCMS.ajax.Edit.init(); }); >> >> 'JCMS.ajax.Edit'.namespace({ >> init: function(){ >> if (JcmsJsContext.isIE){ // Needs channel.js >> Event.observe(document, eventName , >> JCMS.ajax.Edit.edit.bindAsEventListener()); // InternetExplorer >> } else { >> Event.observe(window, eventName , >> JCMS.ajax.Edit.edit.bindAsEventListener()); // FireFox >> } >> }, >> >> edit: function(event){ >> var elt = Event.element(event); >> >> var tag = $(elt.fastUp('A', 'ajax-edit', true)); >> if (!tag || !tag.hasClassName('ajax-edit')) { >> return; >> } >> >> if (!tag.hasEditor){ >> Event.stop(event); >> tag.hasEditor = true; >> var editor = new Ajax.InPlaceEditor(tag, '/demoajaxreturn.html', >> {rows:15,cols:40}); >> editor.enterEditMode('click'); >> } >> } >> >> }); >> >> -- >> Jean-Philippe Encausse - Veille / R&D Jalios SA >> Jp [at] encausse.net -http://www.encausse.com-http://www.jalias.com >> GTalk: jp.encausse [at] gmail.com - SMS: sms [at] jp.encausse.net >> Mob: +33 6 82 12 56 99 - Job: +33 1 39 23 92 83 - Tel: +33 1 39 18 90 15 >> Do it Once, Use it Twice ~ Do it Twice, Make It Once > > > --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
