delusionworld blog

So now we have this local part of MPR to help us using MooTools Plugins. But howto create such Plugins and what should you use…

(bad) Examples

At first let me show you some examples why it’s not so easy currently to work with MooTools. I think the main reason is that it’s pretty hard to use multiple files (js, css, img…) so people try to do everything in ONE file.

Example Milkbox:

Whenever you add it you will automatically add an Event to domready to create a milkbox with the default params… But what if I don’t want to use it on a page, I can’t easily disable it as I would need to edit the file.
[don't get me wrong - milkbox is cool, I'm just saying it might be even better this way...]
It would be nicer if separate in more files:

• Milkbox.js // class Milkbox – with the milkbox effect
• Milkboxes.js // class Milkboxes – create multiple Milkboxes and has the logic for “galleries”
• AutoMilkboxes.js // will require Milkboxes and will add it’s creation to the domready event

With that now we can decide what we want to include. For the “basic” user its just $require( AutoMilkbox ); and people who know can decide if they either want one or multiple milkboxes. However as I said above using 3 files for one plugin without MPR is pretty inconvenient so people don’t do it. [and by inconvenient I mean it's freaking crazy to use 3 script tags for one little plugin - no no no; and yeah we all don't want to build our own script.json for each plugin... (little side kick to the devs..) :p]
Now you can, just use MPR

Example clientcide Waiter:

[again, the waiter is cool, but it might be better this way]
As you can see in it’s docs there if you have this ” baseHref: ‘…’ ” which means that if you use the class the image will be by default loaded from this location: http://www.cnet.com/html/rb/assets/global/waiter/waiter.gif I think this is another “hack” around the MooTools policy “don’t use more than one file in your Plugin” *hehe offending people here…*.
I mean what happens if this file gets forgotten? server upgrade – do we still need this waiter.gif? no, just delete it… :p ok that might be not the actual process but there is surely the possibility that this file will just vanish without a notice… why not deliver the file with the Plugin?
It would gives me again a few benefits

• I can easily replace the image to my own (no need to change any js/css; just replace the file)
• I can define/override the url in my css (if uses as background image) so again no need to change any javascript
• What if I have multiple image files? I mean if I have a Plugin that uses some images from the cnet server; some from the plugin server; and some from my own server.. pretty hard to maintain right?

use of MPR within the Plugin MultiOverlays

So now let’s take a closer look at a Plugin and a way I think it should be done.

File MultiOverlay.js

$require(MPR.path + 'Core/Fx.Tween/Fx.Tween.js');
$require(MPR.path + 'More/Class.Occlude/Class.Occlude.js');
var MultiOverlay = new Class({
  ...
});

ok, here we define the requirements and the logic for one MultiOverlay. now if you want to use it I need to use it with an id and create the Class instance myself. If you know how it’s easy…

var myMultiOverlay = new MultiOverlay( $('imageWithId') );

File MultiOverlays.js

this file is so short I will post it’s full code here…

$require(MPR.path + 'Visual/MultiOverlays/MultiOverlay.js');
var MultiOverlays = new Class({
	multiOverlays: [],
	initialize: function(elements, options) {
		$$(elements).each( function(el) {
			this.multiOverlays.include( new MultiOverlay(el, options) );
		}, this);
	},
	getMultiOverlays: function() {
		return this.multiOverlays;
	}
});

So what do we get here, it just gives you the possibility to create Multiple MultiOverlay(s)… So now you can give the image(s) a class and for each image it will create a MultiOverlay instance which get’s saved in an array (if you may need it any time later…)

File AutoMultiOverlays.js

again such a short file… here is it’s code…

$require(MPR.path + 'Visual/MultiOverlays/MultiOverlays.js');
var Auto = Auto || {};
window.addEvent('domready', function() {
	Auto.MultiOverlays = new MultiOverlays( '.MultiOverlay' );
});

basically it just creates a new MultiOverlays with a hard coded “default” value… so if you require this file you don’t need to write any javascript code at all, just give the CSS-class to your images and your done! It’s the easiest way you can do it… [here the value get's saved in the Auto variable as I might still want to use it later... the Auto variable is globally here]

So why all this files?

As I said above I think it’s vital to separate logic to where it belongs. And for me that means if I want to have a single MultiOverlay I should be able to. So the logic for Multiple MultiOverlays shouldn’t be in it, as it’s just more stuff I don’t need… :p
And while we are at it, now that we need a Folder for it let’s add the Docu. So now we got demos, docu, Resources(css, images) all in a single Plugin Zip file.
It’s just easy to send it to someone and he get’s everything – I don’t need to explain what css image files he has to manually include… If you have a local MPR you can just install it in the admin area…. (talking about easy… )

What do you want to hear next? more MPR best Pratice?