[thelist] AJAX Tip

[Lee kowalkowski]

On 06/04/06, Matt Warden <mwarden at gmail.com> wrote:
> what about this:
>
> onclick="alert('hi');"
>
> or maybe this?
>
> onclick="return function() { return myFunc('foo'); };"
>
> what about this?
>
> onclick="return function() { if (this.value) return myFunc('foo');
> else return false; };"
>
> At what point is the definition no longer externalized?

Yes, they're all behaviour in markup, totally unrecommended.  You
should know better ;-).  Yes, it's difficult to draw the line, I can
see this is a difficult education exercise in most development
domains, and it's much simpler to ban inline events altogether.

> onclick is a way of defining a behavior in response to an event, just
> like defining myFunc() is defining behavior in response to that
> function call.

Agree, but using myFunc is delegation of behaviour.

> How is obtaining a reference to a dom element mixing structure and
> behavior? When I say "structure", I'm talking about markup structure,
> which is supposed to be a way of serializing a document tree.

It's about coupling and simplicity.  Explicitly referencing elements
that originated from a serialized origin is coupling.  Depends on your
slant, code/markup decoupling is acheivable, but in my experience, it
comes at a cost.

Markup/behaviour (or controller/view) decoupling in the user agent
tier is unavoidable in practice, but coupling is less with
(appropriately contrained!) inline events.  This is where I'm saying
there are possible support & maintenance gains to be made, yes
depending on the skillset of your team.

Chris demonstrated earlier that this is inappropriate for CMS
scenarios, which I hadn't appreciated before (cheers Chris, that's
*obvious* now!).

> When systems start getting much more
> complex is when separation like this becomes increasingly important
> and has an increasing impact on maintenance and knowledge transfer
> (e.g., during employee turnover) costs.

I agree (except I think you meant the opposite), spearation has an
increasing impact on maintenance and knowledge transfer.  That's why
I'm trying to emphasize decoupling, not separation without thought,
but I'm not doing very well am I?  Sigh.

> By the way, this is digressing into an argument we've had on this list
> at least 3 times. There's more info in the archives.

Please don't use the word argument, that's so negative.  You wouldn't
participate if you didn't enjoy it.

I'm just want to understand the reasoning & limits of the guidelines,
the archives don't help me do this, I can't discuss on the archives. 
I was miffed at the notion that DHTML is something to be distanced
from DOM Scripting, one is bad and the other good.  When in actual
fact, this thread has proved it's almost impossible to do much DHTML
without DOM Scripting.

It should be in our nature to challenge things, when one is
enlightened, they understand.  When one understands, they don't
forget.  It's a learning excercise, what this list is all about.  In
order to evangelise, one must believe!  Respect to Chris & yourself (&
the list), you make all this possible.

Even if Chris does get annoyed from time-to-time! ;-)

-- LK