What is your initialization technique?

[Thomas Aylott]

A pretty common pattern for writing javascript code is to have a
script with all your widgets and classes and plugins and stuff. EG:
lib.js and maybe also lib_extras.js
Then a separate script for each page or page type. EG: blog_home.js or
blog_archive.js

That page specific code has a domready event which actually hooks up
your widgets and classes and stuff to elements on the page and gets
everything running. EG:

@@@ javascript

window.addEvent('domready',function(){
new SomethingWidget('div.somethingwidget');
});

@@@

This is all fine and good. It's probly what you'll want most of the
time. This is MooTools version of "find some elements, do some stuff".

Is there a better way?

Now that event delegation is available (as a plugin, in core in the
next major release), have you found any better patterns?

—Thomas Aylott / subtleGradient

[Michal]

On Thu, Mar 12, 2009 at 2:26 PM, Thomas Aylott
<obli...@subtlegradient.com> wrote:
> Now that event delegation is available (as a plugin, in core in the next
> major release), have you found any better patterns?

I'm not really sure if this counts as a different pattern, but I
always try to pass just the "root" element of 'the elements' to the
constructor: say for a tab class it would be the container element.
All other required elements are defined as CSS selectors in the
options, "relative" to the root element (which can of course be
overridden when constructing the instance). Then in initialize I would
have something like:

var someRequiredElements = root.getElements(this.options.someRequiredSelector);

to find the elements.

I would imagine this would work well with event delegation, as events
can be then be delegated to the 'root' element.

[Thomas Aylott / subtleGradient]

Personally, I've toyed around with some self-initializing singleton
classes. I have a widget that can only appear once per page. If you
want to use that widget on a page, include the js for it on that page.
It has its own domready which fires its own init method.

EG:

@@@ javascript

var MySingletonClass = new new Class({

initialize: function(){
window.addEvent('domready', this.init.bind(this));
},

init: function(){
$$('div.my-selector')
},

// ...

});

@@@


[[Obviously it's bad to hard-code selectors like this. But I'm using
options to store all that stuff, just didn't want to complicate the
example.]]

This is obviously not ideal everywhere. I really wouldn't recommend
this pattern as general practice since it combines the class and the
instantiation and therefore isn't nearly as reusable.

On Mar 12, 10:26 am, Thomas Aylott <oblivi...@subtlegradient.com>
wrote:

[Thomas Aylott / subtleGradient]

great!
ya, I've used this technique too. It's nice and flexible, because then
it's up to the class how it wants to add events. You just have to give
it a selector and it figures out the best way to use it itself.

[Guillermo Rauch]

The problem with Michal approach is that it doesn't *always* make perfect semantic sense.

Take a look at Fx.Accordion for example. Do you really need a container element ? No. Just headings and content blocks.

Since I don't really like the 'new new' syntax, I defined a new native called 'Single'. This way I take advantage of all the advantages of a class (events, options, etc), and I keep my initialization neat.

mySection = new Single({

  init: function(){

    // initialize widgets

  }

});

Then on domready I just call mySection.init();

--
Guillermo Rauch
http://devthought.com

[Thomas Aylott / subtleGradient]

I've also played with a delegation lazy loading pattern.

I have a widget that could potentially be instantiated thousands of
times on a single page. That obviously doesn't work. Too much code to
run on domready. Also, the content changes all the time and is beyond
my control. So, on domready I find the parent node of my stuff and add
some basic delegation code. If an element that matches the selector
for my widget is clicked, I instantiate a widget for that element at
that time. Since it's only happening once, it happens pretty quick.

On Mar 12, 10:26 am, Thomas Aylott <oblivi...@subtlegradient.com>
wrote:

[nwhite]

my control. So, on domready I find the parent node of my stuff and add
some basic delegation code. If an element that matches the selector
for my widget is clicked, I instantiate a widget for that element at
that time. Since it's only happening once, it happens pretty quick.

slick. I have been playing with some of these models too. Nothing I'm completely happy with, yet. I'll try and get something up soon.

[nutron]

I have two methods that I use.

For the main page stuff - things that always happen when a document loads - I put them all in a hash. I have a has plugin called "run" that just executes all the methods in a Hash (this method is now in m-more). So I can define all my startup methods kind of like a class and then just call startup.run() on dom ready. If I ever need to initialize the page again, I can just call it again.

I'll note that almost EVERYTHING I do is classes, so all my hash methods do are initialize classes.

The second thing I do is more for ajax apps. I've gone back and forth on this a lot, but the way I do things now is that if I have a portion of html that is meant to be ajaxed into pages (and sometimes also loaded on page load), I include the initialization code in the snippet in a script tag. This way my code will work if it's pulled in via Request.HTML or if it's just loaded in the page on its own. It also makes it clear to me that this snippet of html needs this snippet of code to work.

On Mar 12, 10:26 am, Thomas Aylott <oblivi...@...>
wrote:

> Is there a better way?

The MooTools Tutorial: www.mootorial.com Clientcide: www.clientcide.com

---

View this message in context: Re: [Moo] Re: What is your initialization technique?
Sent from the MooTools Users mailing list archive at Nabble.com.

[daKmoR]

I use a $require(path) function to load files if they are needed...
(or use a php script to combine them all to one single javascript
file)

for layouts I'm starting to use a separate UI Class, so I don't need
to care about it...
for example (from my blog entry) I have an window and it gets resize
and controls and so on....
and now I want it to have rounded corners - so I can create one ui
class that uses 4 divs - one on each corner to insert images...
and I can create a ui-class that creates the background with canvas..
or I can even create this little make 1000 divs rounded corner
thing.... all different UIs I never have to touch my functional
windows class...

the right UI classes get automatically instantiated once you call UI
(<theme>)...

for more info see:
http://www.delusionworld.com/mootools/general-mootools-ui/

[ibolmo]

I've lost the point but if we had Class.create then we could do:

var myClass = new Class({ ... });

window.addEvent('domready', myClass.create.pass(['id',
{options:''}]));

@anutron, not sure why you have that Hash. You're reimplementing the
purpose of addEvent, I think.

[nutron]

I have that hash pattern because I want to have a collection of methods that get fired when I want to init the page and I don't want this:

var startup = {

  init: function(){

    startup.foo();

    startup.bar();

    startup.whatchajigger();

    etc;

  },

  foo: function(){ ... },

  bar: function(){ ... },

  etc

};

window.addEvent('domready', startup.init);

Instead, I just make startup a hash, leave out the init method and call startup.run() on domready.

I could have it all inside a single, giant domready statement, but that has two issues for me: 1) I hate giant methods and 2) I can't add things to the init method laster (just add more domready statements). This way I can assign new methods to startup at any point and, when the dom is ready, they all run.

Like I said, I've gone back and forth on this stuff a dozen times. I've also done the "new new PageStarter()" class pattern, but it seems like overkill most of the time. <shrug> There's no right way here, I think. This is where we all do whatever makes the most sense to us.

-Aaron

On Thu, Mar 12, 2009 at 10:45 AM, ibolmo (via Nabble) <ml-user%2B64531-746315738@...> wrote:

I've lost the point but if we had Class.create then we could do:

var myClass = new Class({ ... });

window.addEvent('domready', myClass.create.pass(['id',
{options:''}]));

@anutron, not sure why you have that Hash. You're reimplementing the
purpose of addEvent, I think.

On Mar 12, 9:03 am, daKmoR <daK...@...> wrote:

> I use a $require(path) function to load files if they are needed...
> (or use a php script to combine them all to one single javascript
> file)
>
> for layouts I'm starting to use a separate UI Class, so I don't need
> to care about it...
> for example (from my blog entry) I have an window and it gets resize
> and controls and so on....
> and now I want it to have rounded corners - so I can create one ui
> class that uses 4 divs - one on each corner to insert images...
> and I can create a ui-class that creates the background with canvas..
> or I can even create this little make 1000 divs rounded corner
> thing.... all different UIs I never have to touch my functional
> windows class...
>
> the right UI classes get automatically instantiated once you call UI
> (<theme>)...
>
> for more info see:http://www.delusionworld.com/mootools/general-mootools-ui/

[Thomas Aylott / subtleGradient]

Is there any reason why people should not use multiple domready events? EG:

window.addEvent('domready',function(){ new Foo('[foo=bar]'); });
// other code
window.addEvent('domready',function(){ new Bar('#bar'); });
// other code
window.addEvent('domready',function(){ new
Whatchajigger('.whatchajigger'); });

VS

window.addEvent('domready',function(){

new Foo('[foo=bar]');
new Bar('#bar');
new Whatchajigger('.whatchajigger');

});

nutron wrote:
> I could have it all inside a single, giant domready statement, but
> that has two issues for me: 1) I hate giant methods and 2) I can't add

> things to the init method later (just add more domready statements).

[nutron]

nope. for my page initialization, I prefer to use one and keep my initialization methods tidy. But as I pointed out, I like to keep my ajax partials with their own domready statements for their own initialization.

[Thomas Aylott / subtleGradient]

Ya, must agree that that is probly the cleanest most maintainable way to do things.
If I came into a new project where they had init functions strewn all over the place I would be annoyed.

nutron wrote:

nope. for my page initialization, I prefer to use one and keep my initialization methods tidy. But as I pointed out, I like to keep my ajax partials with their own domready statements for their own initialization.

On Thu, Mar 12, 2009 at 12:01 PM, subtleGradient (via Nabble) <ml-user%2B55783-747403698@...> wrote:

Is there any reason why people should not use multiple domready events? EG:

— Thomas Aylott / SubtleGradient.com