[thelist] javascript default event handlers, default events. [TIP]

[VOLKAN ÖZÇELİK]

It's being a nice discussion. An as in any discussion one should agree on terms.

By behavior what I understand is anything that happens on the script
side when the user interacts with the front face (or say GUI) of your
app. It can be something that happens when you click on a link other
than the default course of action which is the redirection of that
links HREF, or moving mouse over somewhere which triggers a fancy
image to slide down from top etc etc.

I may extend it furter, if you like, but I hope it is explanatory
enough. Just don't want to be too much technical/philosophical.

As a side note let me talk about a real-life scenario I've struggled recently:

We had a 100+ KB javascript file which is included in some page. The
file and some other supplementary files had made the page's overall
download time around 30+ seconds in 56K dialup connection (the project
is still alive and some of the clients still do use 56K dialup
connection)

The legibility of using a huge javascript file is another matter of
fact. Keeping that aside, the page was something like:

<button id="someid" onclick="dosomeaction()" />
<input id="someotherid" onfocus="dosomething()" onblur="doanotherthing()
onchange="doDozensOfValidationAndDBLookup()" />
<select id="someselect"
onchange="whyOnEarthDoesThisProjectRelyOnClientSideValidationThisMuch()"
... >

Anyways my career in my current company is only 10-months old and I
was not the lucky one who had made the decision of using this much js.
The project has its own reasons (specs) of course.

What was happening that people were starting to enter text, click on
buttons etc before the page fully loads which resulted in javascript
errors and even worse this was stopping the loading of the rest of the
javascript.

To solve it, we place all event handling to the onload event handler
of the page:

- The clients were happy because they were able to press buttons, fill
in textfields, click checboxes. As long as the page has not loaded
fully no js error shall arise, because the events had not been
attached to the input elements yet.
We just added a post-validation logic after the load event to reassure
that everything was consistent which was not that pain in the rear.

- We were happy because clients were happy. 

Moreover, we were putting some "the system is initialising, please
wait" div in front of the client and it was waiting there for a long
time. By taking event registration to onload we got rid of that as
well.

. . .

You may argue that you cannot apply MVC paradigm 100% in a web-based
application:
Your specs, your boss/client , even your mood that day may not allow a
100% usable/accessible design. However, regardless of the limitations,
any step taken through separation of model and view; any step taken
considering accessibility in mind is a step on the right direction.

Cheers,
Volkan.


On 8/31/05, Kowalkowski, Lee (ASPIRE) <lee.kowalkowski at hmrcaspire.com> wrote:
> > -----Original Message-----
> > From: VOLKAN ÖZÇELIK [mailto:volkan.ozcelik at gmail.com]
> > Sent: Wednesday, August 31, 2005 4:10 PM
> >
> > eh.addEventListener(document.getElementById("foo"),"click",foo_click);
> >
> > eh.addEventListener(document.getElementById("bar"),"click",bar_click);
> >
> > eh.addEventListener(document.getElementById("baz"),"click",baz_click);
> > }
> >
> > So it is neat, events are attached at a single place. Behavior is
> > separated from code. It is easy to maintain (imho) since you know what
> > code belongs to where.
> >
> > That is, as long as you follow some logic and some conventions, it is
> > even easier (imho) to add/ammend/remove event handling logic on the js
> > side.
> 
> Thanks Volkan,
> 
> Behaviour separated from code?  That I'd like to see!  ;-)  I know what you
> meant.
> 
> I'm uneasy about the opinion that all those getElementById calls are a true
> separation of presentation and behaviour though, that's what troubles me.
> 
> I'd agree that if you could achieve an enterprise-wide convention of that
> nature it would be acceptably maintainable.
> 
> - LK
> 
> 
> ===========================================================
> Our e-mail domain has now changed from iraspire.com to hmrcaspire.com. Please update your address books.
> ===========================================================
> 
> --
> 
> * * Please support the community that supports you.  * *
> http://evolt.org/help_support_evolt/
> 
> For unsubscribe and other options, including the Tip Harvester
> and archives of thelist go to: http://lists.evolt.org
> Workers of the Web, evolt !
>