On Jun 10, 7:07 pm, "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.
>
[...]
> 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 $$()
This is called event delegation - you wait for an event to bubble, see
where it came from, then decide if you want to do something with it.
>
> 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)
There are well known strategies to deal effectively with memory leaks,
I don't think that should be an issue. Nor does this model
necessarily decrease the likelihood of leaks.
>
> 5. Question
>
> - Is there drawbacks with this solution ?
1. Not all events bubble, so you don't have the full range of event
listeners available.
2. Passing parameters from the event to the called function is more
complex - strategies like additional class names or custom attributes
are often employed.
> - Why Libraries (InPlaceEditor, Prototip, ... ) do not use this design
> pattern ?
Ask their authors. Don't forget that web 0.1 inline listeners don't
have any of the issues highlighted above and can be used in exactly
the same way (i.e. event bubbling) and you don't have to wait for
window.onload or DOM:ready.
Consider the difference between using logic at the sever to add class
names and custom attributes to be used by a listener added at the
client versus using exactly the same logic to add an inline listener
with parameters. I'm not suggesting that inline listeners are the
answer for everything, just that they have their place and shouldn't
be dismissed out of hand for not being hip.
--
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 [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
-~----------~----~----~----~------~----~------~--~---
