Friday, November 9th, 2007
Category: Prototype
<
>p
>With all of the
news about Prototype this week, it’s time to do a quick check to see if you, the Prototype developer, actually know your stuff.
Juiry Zaytsev takes us through a comparison of the right & wrong ways of doing certain tasks in Prototype:
I’ve been developing with prototype for almost a year now and have been spending a lot of time on the IRC channel. It’s hard to explain what kind of nonsense people are asking sometimes. It seems to me that most of the time prototype is used at 15%, not more. I’m not surprised anymore to see Ajax.Request used with document.getElementById on one line
Juriy created two posts that offer insight into how to properly right Prototype code to handle various scenarios. For example:
The wrong way:
$(‘footer’).style.height = ’100px’;
$(‘footer’).style.background = ‘#ffc’;
The right way:
$(‘footer’).setStyle({
height: ’100px’,
background: ‘#ffc’
})
The two posts can be found below:
How well do you know prototype Part 1
How well do you know prototype Part 2
- Why You Need Interactive and Clickable UI Prototypes for Your Next Project
Tiggr is a Web-based rapid prototyping tool. With Tiggr you can create, share, collaborate, and preview Web and mobile user interface prototypes. The...
- Ajax Cheat Sheets
We've gathered cheat sheets for fast reference to Ajax-related information. You'll find information about Prototype, code packages, scriptaculous and...
- Effective prototyping for quality software
The authors of "Effective Prototyping for Software Makers" discuss the benefits of prototyping, how anyone can create a helpful prototype, and how the...
- Software requirements gathering techniques
Requirements gathering can be a difficult, exhaustive process. We've assembled information on the best methods for requirements engineering --...
- Effective Prototyping for Software Makers -- Chapter 3, Verify Prototype Assumptions and Requirement
To effectively prototype, argue the authors of this book, you must first establish prototype requirements. This book excerpt explains how to transform...
It overrides/extends internal Javascript objects, that’s about all I need to know.
damn, I was expecting a quiz :(
@Mark : If you’re speaking about that stuff, extending the hashmaps, it’s no longer the case. Otherwise, I can’t see what is wrong with extending prototypes, beside the fact that some of methods implemented sucks, like Array.getFirst();
The problem is that there is no ‘unified’ documentation AFAIK. When using Prototype (or any other JS library) this will more or less deprecate parts of the regular API. But no one will tell you which parts should not be used anymore. So how could be developer possibly now that document.getElementById should not be used anymore, but Math is still ok? Especially if one only adds Prototype for a particular reason (like a nice API for XmlHttpRequest).
extending base objects bad, because we used prototype some time ago, and now it’s really hard to get rid of it because those .bind() and few array and string extensions are used sometimes across the code.
I would love to see a similar wrong way/right way list for dojo (0.9/1.0). If anyone knows of something like that be sure to share, but I’m sure chances are slim.
@Mark, Tim: Just to clarify, Prototype doesn’t override native properties, it extends them. There’s nothing wrong with using
document.getElementById, for example, it’s just not using the full power of Prototype, that’s all.Nice post, I found a couple idioms I need to start using. …(@Mark ..Prototype (the JS library) hasn’t extended the Object.prototype since version 1.4, many moons ago. )
This actually goes the same as jQuery except jQuery’s selector doesn’t really return a raw DOM object.
I’ve seen ppl doing this
$("#some_node").css("background", "red");
$("#some_node").css("color", "#FFFFFF");
Which the actual better and more efficient way is
$("#some_node").css({background: "red", color, "#FFFFFF"});
Oh, and one more thing to mention, if you need to set “background-color”, the syntax should be “backgroundColor”.
Pretty sure most of u guys know this already.
Nice checklist and some interesting stuff on the blog as well.
@Simon: Why are you posting that jQuery code here? Want some Mootools and YUI code too? Maybe it’s a good idea if you made your own checklist?
I can understand (in some cases) wanting your code to be portable, but given the different philosophies of the various popular JS libraries, you’d have the same problem with any one of them. I fail to see how this is prototype’s fault any more than any other library. I mean, if you’re advocating against using a library at all, that’s fine too, but I can’t really imagine a good argument for that.
Come on. Until you’re ready to rewrite an application, it’s okay to use a single library’s API as part of your application. And you can always use a different library on a different application. You wouldn’t expect changing your house’s foundation to be a quick and easy task, not especially if you’re moving your house to a different locale with different geological demands. Why would you expect that of the foundation of your UI logic?
How well you know prototype also has to be tempered with how well you now your browser. Case in point, I had a long list of checkboxes in a tree that had to be set and cleared depending on what the user selected. I had used the “prototype way” of doing things which worked fine in Firefox (it finished in just under 1 second), but when tested in IE, the function ran over 6 seconds long. Only by taking out some of the prototype syntax sugar, was I able to get the times below 1 second on IE.
prototype is tha shit. there is a better lib
@Marlon: there was a bug somewhere between versions of prototype that made various selectors (like getElementsByClassName, which is now deprecated) to be very slow in IE. However, this was fixed a long time ago. Though it might not be as fast as firefox (IE doesn’t support xforms), it’s not ’6 seconds’ slow either.
I couldn’t post a comment on Part I. But the author might want to note that $F doesn’t work for radio buttons. As a newbie, that tripped me up.
It would be nice if that gets fixed.
People should really read the docs!
Those things are there!