13 Replies Latest reply on Jan 21, 2009 10:56 PM by Thomas B. Nielsen

    pls explain abt prototype

      pls explain abt prototype and its use in indesign scripting
        • 1. Re: pls explain abt prototype
          Thomas B. Nielsen Level 3
          For prototyping in javacript there is loads of info on the net.
          Example: http://www.w3schools.com/jsref/jsref_prototype_math.asp
          • 2. Re: pls explain abt prototype
            Level 1
            thanks Thomas
            • 4. Re: pls explain abt prototype
              You can preset a default value for all instances of employee.
              This only occupies one slot in the prototype,rather than one per instance when preset in the constructor. I do it regularly for methods. Maybe run a speed test?

              For methods it even works with InDesign's native objects.

              // make global"Pages" object available


              Pages.prototype.fancy = function ()






              // See ESTK console for output

              • 5. Re: pls explain abt prototype
                (Simon_Paterson) Level 1
                I use prototyping a lot for standard Javascript classes like Array. The function is then available to any Array that you create. For example:

                >Array.prototype.contains = function (a)


                for (var r = 0; r < this.length; r++)


                if (this[r] == a) { return true; }


                return false;


                You can then just use 'myArray.contains(myValue)' to find if the value is in the Array. If you were doing this with a function, you would need to send both the Array and the value to the function, so it's a little less elegant.

                I love Dirk's tip for prototyping built-in InDesign classes. I can see how that would be useful.
                • 6. Re: pls explain abt prototype
                  Harbs. Level 6
                  Yes. I wasn't thinking of default values...

                  I'm very wary of prototyping standard classes. I once created a
                  prototype function on the js Object class, and it caused some
                  very_difficult_to_track_down bugs in another script which happened to be
                  running in the same engine. Since then, I've stayed far away from
                  prototyping anything besides my own private classes...

                  Generally, there's no need to create a prototype method to accomplish
                  the goal. Simon's example is functionally equivalent to:

                  function Contains(array,a)
                  for (var r = 0; r < array.length; r++)
                  if (array[r] == a) { return true; }
                  return false;
                  and you just write: if(Contains(array,a)){do something...}

                  There's actually an advantage to not use prototyping in Simon's example: My construct can be used on any object which has a length property (like strings or collections).

                  Dirk's example can be done in a similar way.

                  This is the construct that I generally use. I think it's a lot safer (albeit slghtly harder to read) than polluting the public classes...

                  I don't think there's any performance gain by using prototypes here.

                  • 7. Re: pls explain abt prototype
                    Peter Kahrel Adobe Community Professional & MVP
                    I'm with Harbs on this one. Though it's difficult to measure these days on modern computers with their fast processors, on the sub-1Mhz-processor computers I used a few years ago, prototyped functions were clearly slower than non-prototype ones. So I never got into the habit of prototyping. They do look kinky, though.

                    • 8. Re: pls explain abt prototype
                      Harbs. Level 6
                      One simple example where prototyping could be very bad:<br /><br />function1();<br />function function1(){<br />    Array.prototype.getItemIndex = function (item){<br />        for(var i=0;i<this.length;i++){<br />            if(item==this[i]){return i}<br />            }<br />        return undefined;<br />        }<br />    var array = [1,3,5,2,4,6];<br />    DoSomething();<br />    if(array.getItemIndex(10)==undefined){<br />        alert("undefined");//do something<br />        }<br />    else{alert("defined")}//do something else<br />    }<br />function DoSomething(){<br />    Array.prototype.getItemIndex = function (item){<br />        for(var i=0;i<this.length;i++){<br />            if(item==this[i]){return i}<br />            }<br />        return -1;<br />        }<br />    //do some stuff...<br />    }<br /><br />Now, the creator of function1 would expect his script to work properly <br />-- and it will as long as he doesn't include DoSomething() in his <br />script. Once he includes DoSomething() in his script, the public Array <br />object has been changed to conflict with his script. The public objects <br />are outside of the scope of namespaces. Both of these prototype methods <br />are perfectly legitimate, but will conflict with each other, and you'll <br />have a **very hard time** tracking down the problem!!!<br /><br />This kind of thing can very easily happen with nested scripts especially <br />when event handlers are invloved. The DoSomething() function might not <br />even be in your script, and you might not know of its existence... Of <br />course using private scripting engines avoids these issues when used <br />carefully, but I'd rather keep everything in its own namespace and safe <br />from any chance of conflicts...<br /><br />-- <br />Harbs<br />http://www.in-tools.com
                      • 9. Re: pls explain abt prototype
                        Level 1
                        Time for my two cents...

                        As it stands right now, I have three methods added to Array (contains, indexOf,
                        lastIndexOf) so that it has an interface that matches String more closely.

                        On String, I've added 8 or so methods (like contains, trim, and startsWith) for
                        stuff that I typically need to do with Strings.

                        For C-printf-style formatting, I've added String:sprintf, Date:strftime, and

                        On Folder, I've added my own implementation of getFiles (the original
                        implementation had bugs and didn't support RegExp matching) and some similar
                        methods (for doing recursive getFiles calls, for instance).

                        I have stayed away from extending PS/JS-DOM or ID/JS-DOM classes because not all
                        classes have bindings to the interpreter at startup.

                        While Dirks technique
                        Pages.prototype.fancy = function ()

                        works fine if there is a open document, it doesn't work in the general case, so
                        I can't write a set of extensions, drop them in a startup script and have them
                        available for all of my scripts.
                        I've made specific requests in the past to add some support to the ESTK api for
                        binding classes on demand (e.g. $.loadClass('Pages')) so that I could extend DOM
                        classes more easily, but it has either fallen on deaf ears or is technically
                        What makes this even more 'tragic' is that there is an API for adding JS
                        extensions written in C. I would love to be able to selectively implement
                        extensions to DOM classes in C to help get the most performance possible out of
                        my scripts. Lack of a $.loadClass function makes doing this seamlessly somewhat

                        In a previous life, I used to embed interpreters (mostly TCL) into existing
                        in-house applications, so my opinions might be slightly colored :)

                        • 10. Re: pls explain abt prototype
                          frameexpert Level 4
                          When you extend these methods, do you have to do it at the top of every script? Or, is there a way to do it in an include file?

                          Rick Quatro
                          • 11. Re: pls explain abt prototype
                            Level 1
                            Rick_Quatro@adobeforums.com wrote:
                            > When you extend these methods, do you have to do it at the top of every script? Or, is there a way to do it in an include file?

                            I have an include file (stdlib.js) that I include with almost every script I
                            write. I has these extensions and other things that I commonly use.

                            I could also put them in a separate script and place it in the Startup Scripts
                            folder so it gets loaded automatically, but that just creates problem when other
                            people use my scripts.

                            BTW, I get around the include file distribution problem by flattening my scripts
                            to a single file as part of my packaging process.

                            • 12. Re: pls explain abt prototype
                              Thomas B. Nielsen Level 3
                              Why not use the "Export As XHTML" solution?

                              Adding a folder inside the Scripts folder (Not scripts panel), and making a subdir of this with the name Startup scripts.
                              • 13. Re: pls explain abt prototype
                                (Simon_Paterson) Level 1
                                I can see where you are coming from, Harbs, but my example was just that, an example. In many other instances you would need separate functions for different data types and in those instances there would no benefit to using a function instead of an prototype. In fact, as I stated, in many situations it is often far more elegant to use a prototype because you pass less arguments.

                                There is a lot more to be said about when and where to use prototypes but in the end it will probably come down to an individual's goal in terms of how they want their code to be structured. None of the reasons given here, besides potential performance impact, really touch on the reasons why prototypes are beneficial.

                                In the context of the original question, however, it seems that we can probably say they have very little impact on the way someone might approach scripting InDesign (unknown performance impact issues aside). You can choose to use them, or choose not to. Put it this way, when you have written enough code that organisation through class structure and inheritence becomes key to efficiency, then prototyping will be something you want, rather than something you need.