Archive

Archive for July, 2009

use MooTools in TYPO3 with MPR

July 31st, 2009

Finally I can present you the combination of my two favorite Open Source Worlds. Meaning MooTools and TYPO3.

MPM comes with a nice TYPO3 Mod where you can look through all the currently installed MooTools Packages with Demos, Doku, Search… all you need to get it working quite fast :)
MPRinTYPO3

So let’s talk about the reason… I mean I’m a pretty lazy guy. I don’t like to do stuff manually if there is any possibility to do it with some sort of automatism. And working on a big TYPO3 site with multiple MooTools Plugins can be quite a pain in the ass. Every Plugins has it’s own MooTools version and tries to include it. They (usually) don’t share a common library or don’t want to require other extensions. I can understand that but it makes my life sometimes harder… and that’s something I don’t like.

So here we come MPR as an TYPO3 extension. Using MooTools whenever you want to – no need to think about dependencies or graphics and that stuff.

First I wanna say I don’t want to offend the authors of rgsmoothscroll – back then it was the best/only way to include MooTools stuff, but now with good use of MPR it could be much easier.

Let’s see a simple example. Maybe you know the extension rgsmoothscroll it gives you the smooth scrolling experience for anchor links within one page. It uses the Plugin SmoothScroll (now Fx.SmoothScroll) from MooTools More. You can seen an example of it at the MPR demo page or in your TYPO3 BE Mod (see Screenshot above). Now let’s take a small look at some of the files in this extension
ext_localconf.php [1 KB] – register plugin
ext_tables.php [1 KB] – register statics
res/mootools-1.11.js [21 KB] – compressed MooTools 1.11
static/constants.txt [1 KB] – statics for transition, mode, duration, fps
static/setup.txt [1 KB] – set options from constants and insert plugin on page.91
pi1/class.tx_rgsmoothscroll_pi1.php [4 KB]

// [...] could use EXT:t3mootools to build a costum core
// include necessary js
$header .=  '<script type="text/javascript" src="'.$this->getPath($this->conf['pathToMootools']).'"></script>';

$header .= '<script type="text/javascript">
	var Page = {
		initialize: function() {
			new SmoothScroll({
				transition: Fx.Transitions.'.$transition.',
				fps: '.intval($conf['fps']).',
				duration: '.intval($conf['duration']).'
			});
		}
	}
	window.addEvent("domready", Page.initialize);</script>';

// include the js in the header
$GLOBALS['TSFE']->additionalHeaderData['rgsmoothscroll'] = $header;

So let’s explain this a little. First we need to get all the need JS this is a MooTools 1.11 so if I want to use the MooTools 1.2 features then I have a little problem as I would need to build my own MooTools version and I would need to check out what’s needed… it’s not real a problem but it’s rather cumbersome. I believe the extension itself should not need to care about the core or MooTools plugin. It should just say I need Smoothscroll and then use it. If the code get’s included on page render or loaded dynamically shouldn’t be it conserns. OK let’s go on – then we have the script block where it starts the SmoothScroll with all options. Again it work but it’s probably not the best way. I mean why give all options – they are already well set in the class itself and if there is another option added in the class you have to mirror it in your extension. Or let’s say an default value get’s changed because the funtion of the class is a little modified you would have to update the extension default also… doubling data isn’t good because you will always have to update at two places… So I believe options should only be set if you want it expliciply. By default it should use the class defaults and not it own default.

So now let’s give the “same” functionality but with the use of MPR.
ext_localconf.php [1 KB]

t3lib_extMgm::addTypoScript($_EXTKEY,'setup','
page.headerData.989 = TEXT
page.headerData.989.value (
	<script type="text/javascript">
		$require(\'Core/Utilities/DomReady.js\');
		$require(\'More/Fx/Fx.SmoothScroll.js\');

		window.addEvent(\'domready\', function() {
			new Fx.SmoothScroll();
		});
	</script>
)
',43);

now what’s that just one file? yeah it’s all you need and in fact I wouldn’t create an extension for that but just for the sake of explaination. All we do is to add a script block somewhere on the page. In this block we say that we want to use the DomReady stuff and the SmoothScroll stuff. The we just start SmoothScroll with the default options. No need to care about any other js stuff. No need to include any core or any other css all the info is inside the “MooTools Packages” itself.
One problem we have with this solution is that if you want to change some options for SmoothScroll you will have to rewrite the whole block… so I guess we need a different solution to the “map MooTools option into TS” problem… but more on this will follow….

So now we see that with MPR it’s pretty simple to use plugins without even using any extension. Just write the script block prepare some html (if needed) and you are done.

daKmoR MooTools, TYPO3

MPR has been split into MPR and MPM

July 1st, 2009

It’s been quite a while. Honestly I didn’t had as much time for MooTools as I wanted. Nevertheless there has been some changes. The most important one is surely that MPR has been split into 2 separate Projects. It consists now of:

  • MPR (MooTools Package Repository)
  • MPM (MooTools Package Manager)

The reason for this change lies in the nature of a Package Repository. First you have the actual data (MPR), secondly you need some local Application to organize these data (MPM) and finally you need an online server (to be build) to store and order these files globally.

To reflect those changes the url got changed to: http://mpm.mooforum.net/Mpm.php

One other important reason for this change is that if you want to use MPR in an existing system like a CMS or a Blog System you most likely just want to write individual Manager for them (maybe based on MPM, but what if your CMS uses something else than PHP?) but MPR can always stay the same as it’s just the data. And by using a generic Package System you easily can distribute your Packages even between different Managers… (ok that’s a future dream but whatever who knows what the future brings.)

And what I’m currently doing is writing demos for MPR Mootools More as there are so many nice functions. I mean every time I look through the documentation or the code I find some nice new stuff. The only problem with that is by just looking at the text – it’s most of the time pretty hard to see what this code is really capable of. Without a good demo even the best code is nothing but just text to lazy people like me *hehe* I need some place to click around or see some stuff moving.

I mean a demo should show the most common usage of a function. I will try to do some blogging about my ongoing work…

daKmoR MooTools