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 rubyonrails-spinoffs@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
