Follow me: @D_mitar

Most read posts recently



Jun 20th 2009 × mootools 1.2.3 released, bug fixes and compatibility with other frameworks

Nathan White announced the mootools 1.2.3 release today. This is to be the last version prior to bumping everything into mootools 2.0.

Although mootools 1.2.3 is mostly about bug fixing, it does introduce an important feature: “Element: MooTools compatibility mode: the $ function is only defined if no pre-existing $ function is found. If an existing $ function is found, you can use document.id()”

In reality this means that mootools will be able to co-exist with frameworks such as jQuery (or others). It will still not work alongside Prototype, for example – extending prototypes just cannot be namespaced. Also, even though you now CAN use more than one framework at a time, you probably shouldn’t do so on the same page, its a wasteful and needless practice.


Jun 8th 2009 × jquery vs mootools: a look at what each framework represents and how to choose wisely

Aaron Newton has written up what appears to be one of the most comprehensive and unbiased answers to the eternal question: jquery or mootools. I cannot recommend it enough to anyone that’s just starting with javascript or is looking at both frameworks from the “which is better for me and my project’s needs” angle. It’s worth mentioning before you begin, this is a comparison of the core functionality, provided by each framework – not what is possible should you decide to build on it.

The short summary: both frameworks are great but serve a different purpose, with jquery is more user and beginner-friendly, focused / optimised around DOM access and mootools, building and extending the javascript native prototypes and methods (not at the expense of the things that jquery can do).

Another way to look at it: mootools takes things further than jquery and makes javascript fun, introduces features that are coming in javascript 1.8 and provides a great layer for object orientated programming whereas jquery is staying where it’s at its best: shortcuts, chaining and styling, leaving anything else you may need to plugins and vanilla javascript.

http://jqueryvsmootools.com/

The comments are also well worth the read, some good points on the pro’s and con’s of each framework and a bit on why mootools does not try to be unobtrusive / conflict free with other frameworks.


Apr 24th 2009 × mootools 1.2.2 released

Just a quick update, in case you missed it: mootools 1.2.2 is out, mostly a bug fixing release. Also, the new mootools-more is out. So… check them out.


Oct 21st 2008 × An interesting concept: CSS frameworks and SEO source ordered content shuffling

It makes sense to standardise your CSS layout and styles development just as you come to rely upon frameworks for javascript and PHP, I guess. I came upon Elements V2, a nice and tight CSS framework that does not try to do too much but does it well.

I you are in a hurry to produce a new site, it can help you get started on the right path by literally laying down the framework for your content. There is always the danger of such projects to try and be too-helpful at times–the included Lightbox/prototype is overkill. But the mass CSS reset seems to standardise and level the playing field for all browsers so it’s worth grabbing just for that feature alone. Naturally, not a first: css reset.

And of course, from a SEO standpoint – you can then take Elements V2′s layout, move main content div to the top of the source code and the header div to end of the file. You then reposition via CSS and some nested layers… The end result? First bit of text that Google sees on the page is the specific body content – H1/2, titles and so forth. Bits that are repetitive like header and side menus simply do not need to be there at all. This technique is also known as Source Ordered Content or content before navigation. Here is an example SEO content shuffle on a search engine optimisation project I am tinkering with.

A snippet of this non-linear approach to source ordered content content shuffling (takes a while to get your head around the idea):

...
</head>
<body>
    <!--Main Container - Centers Everything-->
    <div id="mainContainer">
        <!--Main Content-->
        <div id="mainContent">
            <div class="content" id="main">
                <h1>Welcome to <strong>ASAP Cleaners</strong>...
                ...
                ...
            </div>
            <!--Footer-->
            <div id="footer">
                ...
                ...
            </div>

        </div>
        <!--Header-->
        <div id="header">
            ... links here
            ... more links
        </div>
...

and here is what it looks like in reality:

after SEO shuffle: reversed layer order

I am not going to go into details and bore you with tedious explanations on how to float elements. Just visit the source ordered content example and view the source.

To an extent, I already do this on the http://fragged.org blog itself – what you see as left side menu actually follows behind all the posts in the source code. I cannot really measure how this works in comparison to a normal linear source. I guess some experimentation will be required but that’s for another post :)

Word to the wise: if your pages’ source code gets to be quite big in size, you may consider not using the “content before navigation” method as your page links may be disregarded by some crawlers (with a 100k or so limit for source size on each page). Also, there is an accessibility consideration–some say source ordered content is being harsh on people with disabilities (er, blind) who use reader software (it cannot find the menus, allegedly) so be careful.


Oct 3rd 2008 × On javascript frameworks: unbiased throughts by two of the legends…

I have always dreamt about going to events like The Ajax Experience in Boston because I am a sad person; but also because you get to mee^H^H^Hsee people like John Resig of Mozilla (and er, author of a little thing called jQuery) and Aaron Newton, the CNET coder that brought mootools out of oblivion and mediocrity and continues to strive to take that great framework further (I own just the one hardcopy ‘pc-related/computer’ book and it happens to be MooTools Essentials by Aaron Newton – draw your own conclusions).

Anyway, as Aaron Newton once replied to a question of mine on the mootools google group, I guess I can now busk in his spotlight. So… A great and post cleverly and succinctly entitled jQuery, MooTools, the Ajax Experience, Programming to the Pattern, and What Really Makes One Framework Different From Another comes in the same breath as John Resig’s presentation on Javascript Libraries:

Nice read for a Friday night, huh? I live in a box… But you have to hate the duplicity and the political correctness here: say what you want but you are both champions to two of the biggest frameworks out there. It may be that mootools do not have aspirations for commercial success and recognition through the framework itself (yet), but they need to wake up and look at the big picture here: the more it is being used, the more popular it becomes, the more shared knowledge and improvements will come out of it through the incrased userbase. For Pete’s (who??) sake, jQuery is now in the Microsoft SDK and may even feature on Nokia’s phones… So, BE assertive. Don’t be afraid to point out exactly why framework xxx is better than framework yyy for achieving zzz. Because we (the users) don’t expect you to be nice to each other. After all, mootools is all about elitist attitudes, isn’t it? Lest we forget…

p.s. I blatently saw these two links on the ajaxian. So what?


Oct 3rd 2008 × A worthy PHP framework? Probably not but it is as close as anything else I have seen: codeIgniter

I have always regarded PHP frameworks that adhered to MVC standards and templating engines with inherent mistrust… No, that’s putting it too mildly. In fact, I really really really hated the idea. Let’s face it, somebody coming up with a legitimate way / reason to turn a simple page update on a site into a process that involves editing 4-5 files within the framework must have been paid by the hour… And the rest of the world must have been sleeping to accept this as the norm. I know in my production environment, where a quick reaction and turnaround is often critical, any delay is going to be considered a disaster (never-you-mind financial repercussions).

A typical example of a good idea gone horribly horribly wrong is eZ Publish – an award winning open source CMS system based on PHP, with it’s own framework and templating language. What-the-hell? Having actually worked in a company that dealt exclusively in producing eZ Publish websites and becoming a ‘certified eZ Now professional’, I can’t say I have ever seen anything so clumsy and awkward to develop for.
Hi, Tony Wood / VisionWT – I miss you guys!

Anyway, got sidetracked there… Was looking through some potential contract jobs today when I saw an ad for a PHP / AJAX coder using CodeIgniter. Since it pays 450 pounds a day, I actually made an effort and looked it up–and it turned out to be a WINNAR (anybody remember Jeff K?). I just finished watching the two excellent getting started video tutorials and it left me almost wanting to download CodeIgniter.

What set it apart? The ability to actually use inline PHP inside the view controllers and not have to learn some crappy inferior templating language. It means, if in a hurry, I can quickly code a hack and get it to work without too much messing around in a number of files (well, perhaps 2). Once happy with it and with the pressure off, I can move the change and optimise it in a ‘semantic’ fashion to my heart’s contempt…

It deserves a mention and here is a plug of their own features:

  • You want a framework with a small footprint.

  • You need exceptional performance.
  • You need broad compatibility with standard hosting accounts that run a variety of PHP versions and configurations.
  • You want a framework that requires nearly zero configuration.
  • You want a framework that does not require you to use the command line.
  • You want a framework that does not require you to adhere to restrictive coding rules.
  • You are not interested in large-scale monolithic libraries like PEAR.
  • You do not want to be forced to learn a templating language (although a template parser is optionally available if you desire one).
  • You eschew complexity, favoring simple solutions.
  • You need clear, thorough documentation.

If even half that list is true, we still have a PHP framework that’s worth remembering – just on the off-chance you ever need one.

no

Sep 29th 2008 × What is a javascript framework and why do I need one, part I

This ‘article’ is aimed at helping webmasters, programmers and designers who already have a rudimentary understanding of javascript and DOM programming in cementing their knowledge and getting a solid base for building browser apps in the future. For illustration purposes, I shall be using the MooTools framework but this does not mean it’s the only sensible choice.

I have been posting a fair bit on DigitalPoint’s javascript forums recently and was amazed to discover (well, not really) the huge amounts of people that struggle to get basic javascript bits and bobs working. Adding a javascript framework won’t necessarily fix that all of these problems but a good half of them (at least) will get ‘nearly there’. It also proven to improve manhood tenfold…

So, what is a javascript framework anyway?
In a nutshell: a library of pre-written javascript controls, functions and methods that make it easier for the developer to quickly and accurately produce cross browser compliant code. Example popular frameworks are: YUI, ExtJS, Prototype, MooTools and of course, jQuery. There are also several smaller frameworks around – have a look on ajaxian for a recent rundown of the relative unknowns (like Capuccino)

Yeah, and? What do I need all these libraries for?

Selectors

making sure you can access any and all of your DOM elements at your fingertips

Typically, frameworks provide all sorts of shortcuts for accessing elements within the DOM. These are called selectors and are similar to CSS selectors. Example:

<div id="mydiv" class="myclass" rel="89">click me</div>
<div id="mydiv2" class="myclass" rel="90"><a href="#">null link #0</a></div>
<span id="myspan" class="myclass" rel="89">hello world 3</span>

<a href="#">null link #1</a>
<a href="#">null link #2</a>
<a href="/index.php">normal link</a>
<input id="name" type="text" class="textfield" />
<input id="surname" type="text" class="textfield required" />*
<textarea id="message" class="required"></textarea>*

… and mootools selectors on the above

var div = $("mydiv"); // just reference by id, same as document.getElementById("mydiv"); 

// get an array of all elements that are 'myclass' (mydiv, mydiv2, myspan)
var elsArray = document.getElements(".myclass"); 

// get an array of div elements that are 'myclass' (mydiv, mydiv2)
var elsArray = document.getElements("div.myclass"); 

// get an array of elements that are myclass and rel == 89 (mydiv, myspan)
var elsArray = document.getElements(".myclass[rel=89]");

// get an array of elements that are myclass and rel is not 89 (mydiv2)
var elsArray = document.getElements(".myclass[rel!=89]"); 

// get the first element that has class myclass and rel=89 (mydiv)
var elObject = document.getElement("myclass[rel=89]");

// get an array of null links (to anchors) - (null links #0,1,2)
var links = document.getElements("a[href=#]");

// all links within the mydiv2 layer only
var localLinksArray = $("mydiv2").getElements("a"); 

// get all required fields (surname, message)
var requiredFields = document.getElements("input.required textarea.required");

The examples for selectors are potentially endless as are the possiblities for use. There is nothing to prevent you from using the old document.getElementById() function, or even document.getElementsByTagName(). There is even a new function coming out now to a browser near you (perhaps) – getElementsByClassName(). But that’s just the point – by using a framework, you are guaranteed compatibility NOW and with future releases. If a new browser ‘Steel’ comes on the market that provides access to its DOM elements by way of a function document.ById(), you would not have to go and update every single bit of javascript that on your sites to provide support for it – all you’d do is update your framework and grab a coffee – the major frameworks will always pickup on browser changes and new versions. In fact, I expect most are readying updates to cover the new Google Chrome browser and webkit changes.

Compatibility and performance

Different browsers and different versions have always had their old ideas about what’s the best way to ‘do things’. One can’t help but apploud the peioneering spirit of the Internet Explorer engineers, who pretty much just made stuff up as they went along and ignored many a WC3 standard in the process… The thing that frameworks give you that you will learn to appreciate the most is a bridge between all the browsers. You no longer need to worry if IE6 will fire an onload event when other browsers fire oncomplete. You also won’t have to worry about mistakes in misfiring of onmouseout events when hovering over child elements (IE bug, of course). Frameworks do the worrying for you and fix those common errors that are deemed fixable.

As for performance, it really, really can’t get much better than relying on a bunch of crazed javascript coders and programmers, many of whom are involved in the development of Mozilla, to write, refactor and improve all your functions for you! You get what you want from the DOM, in the fastest possible way. Yes, I am talking ‘selectors’ again and there are lots of test suites / javascript framework benchmarking results of all the major frameworks. More or that will come in part 2 – for now, suffice to say: doing a for() loop through your elements just won’t cut it.

AJAX out of the box

Enough selecting, it’s time to use some keywords that spell ‘magic’ to any marketing pro out there: ajax. web 2.0. ooooh….

Most of today’s modern frameworks will have a way of dealing with XHR requests, more commonly referred to as AJAX. Whereas it does not take much to get going with a simple AJAX request, frameworks have it polished into perfection. You can easily set things like:

  • method (GET / POST)
  • target url
  • setting up events (start, sucess, failure)
  • parameters to url as GET or POST data
  • displaying desponse into a layer/table element
  • evaluating response as javascript in a safe way
  • processing response AND evaluating <script> tags

    Say, you have an element with some summary text and you’d like to attach a click event to it to show the full article text. Here is how that AJAX request can look in mootools:

    $("mydiv").addEvent("click", function() {
        // make a click on mydiv2 to callup an ajax function that gets
        // the full contents of the layer replaced and runs through some scripts
        new Request({
            url: "/index.php",
            method: "get",
            evalResponse: false,
            evalScripts: true,
            update: $("mydiv"), // replaces the text there at the moment
            onComplete: function() {
                // already updated to full text, no need for the event to remain
                $("mydiv").removeEvents();
            }
        }).send("action=getFullText&id="+this.get("rel"));
    });

    Same functionality (just the AJAX call) in jQuery would go like so:

    $.ajax({
      url: "index.php",
      cache: false,
      success: function(response){
        $("#mydiv").append(response);
      }
    });

    In part 2, we will review how to code a few practical snippets that can build you a core library for your site – things like, tooltips, bubbles, form checkers, expanding and collapsing menus and more. And of course, my advice on choosing the right framework for you (always a subject of debate and controversy)