On Jun 11, 5:05 pm, "Jean-Philippe Encausse" <[EMAIL PROTECTED]>
wrote:
> To be sure I correctly understand your answer: Inline events are
> events declared in the HTML ?
> <a href=".." onclick="..." >Click Me</a>
Yes.
> or <script>stuff</script>
No.
> 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
So what.
> 2. Designer must understand the "magic" to write in the page
No, they don't. For example, instead of:
<table class="... sortable ..." ...>
they write:
<table onclick="sort()" ... >
If your HTML programmers can't handle that, you have a serious skills
issue. If you have the logic on the server, then the HTML authors add
an attribute in the HTML that is stripped when processed by the server
and replaced by the inline listener (or whatever other scheme you
use). So the HTML author never needs to write any script, nor does
the listener get added at the client.
> In the real world:
>
> - You will have performance issue asking you to put code at the bottom
> of the page
Putting script elements at the bottom of the page *improves*
performance.
> - Open API issue, the XHTML must be readable, can be parsed
Inline listeners don't have any effect on the readability of the
markup, it's simply an attribute value that should usually be a simple
function call.
> - People makes mistakes it is more complicated to write a <script> tag
> than simply class names
How is writing a script tag any more complex than an img tag? If you
want script in your page, you've gotta put at least one element in
there somewhere.
> 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" :-)
Sure, all I'm saying is that the server can parse the HTML and add an
inline handler, you don't have to do it at the client.
> 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.
And if done at the server before serving the page... ?
> - You can use the bubbling pattern. I was really surprised by the
> speed of document event dispatching. Playing
> withhttp://thinkweb2.com/projects/prototype/detect-idle-state-with-custom...
> it is really fast and convenient.
Yes, bubbling is a useful technique - it is independent of how you add
listeners.
> 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 :-)
Inline listeners don't have *any* issues with memory leaks.
> Thanks for your answer
Just to clarify, I am not saying "never dynamically add event
listeners", I'm just saying to keep an open mind and consider adding
them at the server in some cases instead of at the client. And by
"add them at the server" I am not saying the HTML author needs to add
them, but that they can be added by the server using the same logic
that you are currently employing on the client.
--
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
-~----------~----~----~----~------~----~------~--~---
