To add to what Peter said, the 'prototype' property referes to the prototype that a constructor function will apply to instances that it creates. HTML elements are not created by constructors (at least not in any way that you have access to) so your approach is not feasible.
One way is to create pick wrapper objects from a Pick constructor. Each new pick object will reference the DOM object of the pick cell. But to be honest for the effort involved I would say the advantages of using prototype here are minimal. I would simply create a helper function called editInline or something, which took your pick element as an argument and toggled it back and forth between read only and editable state. There are quite a few examples of this kind of utility in the existing JavaScript framework Angus On Jun 13, 3:29 am, Peter van der Zee <[email protected]> wrote: > On Mon, Jun 13, 2011 at 5:44 AM, radiate <[email protected]> wrote: > > Not sure if I misunderstood the purpose the prototype object of a > > javascript object but I wanted to add functionality to an HTML Table > > Cell that would generate a text box if a user clicked on the cell. I > > wanted to provide this functionality to all table cells in the table. > > I thought this would be a good use of the prototype functionality in > > Javascript. It seems like I can't get it to work. Here's the code: > > Well, there are two reasons it's not really working or going to work like > that. > > For one, in order to extend an object through prototype you have to > extend the parent object's prototype property, not that of the child. > So.. if person is a child of Person: > > person.prototype.newMethod = function(){}; // NOT > Person.prototype.newMethod = function(){}; // YES > > Note that the .prototype property of an instance (person) does not > refer to "its prototype object", or Person.prototype. Formally you > have no access to it through an instance but in most (not all!) > browsers you can still find it through .__proto__ . > > The other reason results might vary is because dom nodes are > implemented using so called "host objects". These are special kinds of > objects that typically don't adhere to the general rules of js. That > means that in most cases, they behave as regular objects insofar as > accessing properties go (and not even that, really) but extending them > or creating new instances of them is all left up to the > implementation. Pretty much any object related to the DOM is a host > object. > > - peter -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
