Somewhere on the list of things to do for me is to seriously get more used to working with javascript (although I can still do everything I've ever needed to do with it so far). I was thumbing around and found an article about Prototype (note that I find Prototype to be alot of overkill but it's still something quite smart).

Anyways, this article provides some nice explanation regarding Prototype...and more generally about programming:

http://www.sergiopereira.com/articles/prototype.js.html

I still don't have plans to use Prototype though but I'm getting even more curious...

    I'm using Prototype quite extensively actually. I think it's brilliant, prehapse some of it's a little over done (Try.these springs to mind) and it's annoyingly geared towards the Ruby way but on the whole I think it's an excellent framework. The effects library script.aculo.us (which is built on top of Prototype) is also very cool. If you check out their source you'll see they've some very cool little conventions. Using Javascript's massively dynamic typing for a kind of namespacing (eg. new Effects.Fade) and options parsing using Prototypes Object.extend method. I've started using both of these conventions myself. The only thing that's holding me back from using Script.aculo.us more is the fact that cd-wow's markup is massively bloated at the moment, which seems to be making the effects really sluggish. I've used it on lightweight, test pages and it works very well.

    I'm really starting to like Javascript as a language and really do believe that investing a little time in learning it properly really pays off. For example, I've recenlty built a little app for loading up product previews in the page. It consists of an abstract super-class which is then extended by concrete implementations so that you can easily build different ways of previewing this products. So far I have one for inserting it as a row in a table, a floating div style popup positioned acording to the mouse position or a lightbox style overlay. The best bit is how simple it is to use.

    <span onclick="new QuickView.Lightbox('<?=$product_type?>', '<?=$product_code?>', event);">QuickView</span>
    

    or maybe

    <span onclick="new QuickView.Table('<?=$product_type?>', '<?=$product_code?>', event);">QuickView</span>
    

      I actually am really quite in love with Prototype. Mainly though I am in love with its class/object model and the $() function. I also use its AJAX library if I'm doing some AJAX... but quite a bit of the stuff I don't really use, but to me it is worth it just for the class/object model.

      I've also fallen in love with Behavior as well, which allows a cleaner separation of your javascript from html code (you setup javascript actions from css like selector rules). For really small things, it might be too much, but for normal or larger things, trying to maintain intermingled javascript and HTML can become a real nightmare, especially if you've got the same "action" in many places and find you need to fix or change something about it.

      For example, using bubblenut's example code, it becomes something like:

      <span class="Lightbox" ptype="<?=$product_type?>" pcode="<?=$product_code?>">QuickView</span>
      var myBehavior = {
      
      // .... //
      
      '.Lightbox' : function(element) {
          element.onclick = function() {
              if ((this.getAttribute('ptype') != null) &&
                  (this.getAttribute('pcode') != null)
              ) {
                  new QuickView.Lightbox(
                      this.getAttribute('ptype'),
                      this.getAttribute('pcode'),
                      event
                  );
              }
          };
      },
      
      // .... //
      
      };

      That is a little more code at first sight; however, if you've got these quick view links in more than a few places, then the benefit of pulling the javascript out of the html quickly becomes apparent. And it also becomes apparent when you realize you can change an element's behavior just by changing its class(es) and/or node location [much akin to how you can do the same for its style]. Though to get the best use of it, you pretty much have to create custom HTML attributes, which won't validate; however it is a tradeoff to get better & easier to maintain code.

        Yea, behaviour's really cool (and can be implemented yourself really easily with Prototype using getElementsByClass). Two reasons why it's not all roses though,

        The page won't validate because of the custom attributes, which doesn't really cause any problems but some might argue should set off alarm bells.
        The other the problem which I come across is that if you have bloated markup, which many larger / older sites do, the time the DOM traversal takes to build the list becomes an issue. Also, the event is only attached on page load, that means after the whole page and every image on it have been loaded. In my case, appart from the bloated markup, we have quite a few images hosted on third party sites which we can't guarantee load times for.

        I would definitely agree, if you can, behaviour is a very cool way of doing things. Unfortunately it's not always practical.

          You know, 'Try.these' was one of the first things that caught my eye as an interesting way for js to root out which version of ajax to serve up. Certainly, it's just as easy using a more conventional method too.

          I was really impressed with the simplification of the language. Normally, I'm rather suspicious of frameworks but this is all pretty darn smart stuff.

          I have been experimenting with moo.fx (which uses Prototype.lite)...it's worthy of a mention around here as well.

            bubblenut wrote:

            I would definitely agree, if you can, behaviour is a very cool way of doing things. Unfortunately it's not always practical.

            Yes such is the nature of any javascript solution, but even more true for JS solutions that would be better handled at the browser level, which i think using javascript to bind javascript to elements would qualify for.

            But for such needs, it is really the best we can do at this point in time. Since around 1998 though there have been numerous proposals by pretty much every browser maker for ways to bind script actions to document elements through either external "action sheets" or simply by extending CSS, yet not a single one has made it very far past proposal in terms of becoming standard and universally adopted. But I still have a ray of hope that one day we might see some kind of action sheets or behavioral CSS adopted as standard.

              Nice; I really should play with Javascript more than I do. For some reason (and I haven't been able to pin it down) I find Javascript syntax ugly. But I agree with vaaaska about Try.these and how the whole thing looks like it could clean JS code up so that I can look at it without feeling irritated.

                dream.scape wrote:

                Since around 1998 though there have been numerous proposals by pretty much every browser maker for ways to bind script actions to document elements through either external "action sheets" or simply by extending CSS, yet not a single one has made it very far past proposal in terms of becoming standard and universally adopted.

                However, at least Mozilla and MSIE have implemented it. I'm not entirely sure how it works in MSIE, but in Mozilla, it's called XBL and it works by extending CSS to cover behaviour as well as appearance.

                Mark

                  MarkR wrote:

                  However, at least Mozilla and MSIE have implemented it. I'm not entirely sure how it works in MSIE, but in Mozilla, it's called XBL and it works by extending CSS to cover behaviour as well as appearance.

                  Not really... each have their own idea of how it should work, proposal to the W3C, and implementation in their own browsers, but that really doesn't do much good unless you are targeting one browser. MSIE has had their own implementations since at least IE 5.5, and Netscape had theirs as well. But again, each browser doing their own thing with this doesn't really do any good.

                  I mean look, it's been 8 years since the proposals for this kind of thing started and there's still no standard that's been adopted, and I don't think any of the proposals have made it much past the "draft" stage, yet everyone refuses to acknowledge that their idea won't be the standard and let go of it to further the pursuit of finding a standard.

                    JavaScript that wonderful language which created the pop-up. JavaScript the backbone of AJAX. JavaScript which can be killed with the uncheck of a button.

                    No Google Adsense. No AJAX. No pop-ups.

                    JavaScript. Web Developers love her pretty little functions. Users on the other hand...

                    JavaScript, Browsers use you differently.

                    When JavaScript cleans up it's act I'll use it more often. How can you say know to it's pretty little innocent onclick function. JavaScript is one of the most evil things people use, why? because they don't know how to use it. It's one thing to copy and paste people's scripts but that by no means makes you a JavaScript programmer. Most people don't even bother to offer an alternative.

                      13 days later
                      a month later

                      Found JQuery last night. I really love the interface and it's only 10Kb! I haven't looked at the source much but at a quick glance it looks very clean.

                      Jason, I usually just ignore you but I'm intrigued. Do you mean to say that Javascript itself is a bad thing because many people don't know how best to use it? I think it is a little naive to base one's judgements of language on the abilities of it's average user base, after all, if you did that PHP would rank pretty low. There are a huge number of brilliant web projects requiring Javascript (have a look on TechCrunch) some of them degrade gracefully but most just inform the user that Javascript is a requirement. I don't think this is a bad thing at all, all programs have requirements, try running amaroK without X running.

                        24 days later
                        bubblenut wrote:

                        Found JQuery last night. I really love the interface and it's only 10Kb! I haven't looked at the source much but at a quick glance it looks very clean.

                        Oh wow...I'm enjoying jquery quite alot. That's it...this is the final straw...Monday I'm going to find a decent book on the basics of javascript (as I've never read one) and learn myself this stuff good and proper. Then I can get into this more formally...

                        Jquery is worth checking out...and prototype as well...

                        Actually, if anybody has a good book on Javascript they are done with and they want to send it to me I'll respond in kind with something of request from Brussels back at you. There's really only one good shop in town that has programming books in English and I'll probably have to back order a good book...the stuff they've had on the shelf in the past wasn't so great.

                          Jason, I usually just ignore you but I'm intrigued. Do you mean to say that Javascript itself is a bad thing because many people don't know how best to use it? I think it is a little naive to base one's judgements of language on the abilities of it's average user base, after all, if you did that PHP would rank pretty low.

                          The PHP community has done a lot to bring security issues to the front of "need to know" information. I don't think I have seen JavaScript and security in the same document before.

                            Tue, security isn't in the limelight as much in the Javascript world as it has been recently in the PHP world (although I think this is changing). You can find some good resources on it by looking at the security tag at ajaxian.com (Ajaxian/Security). That said, it's not really the language which is inherently insecure, it's the developers (well, some of them).

                              I wouldn't say this is representative of a constructive commenting session, but it is what it is...something to read if you feel like it (there's a link to the actual artice that spawned this little mess). From Digg.com a couple days ago:

                              JavaScript Associative Arrays Considered Harmful

                                I've just read this article.

                                It is right in every way except the title, which should read:

                                "Using the Javascript Array object as an associative array is not a good idea"

                                It's not associative arrays themselves which are harmful, only using "Array" as one which is.

                                Mark

                                  As one of the commentators in the Digg thread pointed out, essay titles of the form "Foo Considered Harmful" is a long-established tradition (the archetype is archived here).

                                    7 days later

                                    This prototype sounds very interesting, I might have to check it out.

                                    One thing though is I have always limited my javascript use only because everytime I try something a little more complicated I find it working on one browser, but then do something different (or not at all) in another. Has this changed or was I just coding wrong?