Object oriented javascript best practices question: How should I configure my objects for the following

I've decided I need to improve my javascript programming skills, as well as my OO skills. I am currently reading through some books, but sometimes it's hard to get a grip on the theory without seeing some practical examples first. So, I have a theoretical question about "best practices" for the following scenario...

I would like to create an OO script that displays a list of searc开发者_开发知识库htag records retrieved from the server. I also want to be able to edit each searchtag record in place.

Currently I am doing this procedurally with a bit of help from the jQuery library:

I accept a JSON-encoded list of searchtag records from the server. It looks like this:

[
   { "searchTagName" : "tagOne", "searchTagID" : "1" },
   { "searchTagName" : "tagTwo", "searchTagID" : "2" },
   { "searchTagName" : "tagThree", "searchTagID" : "3" },
   etc...
]

I dump the JSON directly into jTemplates to create the appropriate html, like so:

$("#searchTagList")
   .setTemplateElement("template_searchTagList")
   .processTemplate(searchTagData);

Finally I want it to be possible to modify each searchtag with an edit-in-place method, so I attach a pre-built edit-in-place method to each html element:

$(".searchTag").editInPlace();

This works very well procedurally. And maybe the smartest thing would be to leave well enough alone. :) But, for the sake of argument, what is the best way to write something like this from an OO perspective.

Should I have a single object "searchTagList" that has methods for each of the steps discussed above?

var searchTagList = 
{
    searchTagData: JSONdata,
    renderList: function () { /*send to jTemplates */ }
    bindEdit: function() { /* attach edit-in-place */ }
}

Or is that incorrect? (It seems like all I'm doing is wrapping my procedural functions in an object.) Should I somehow be parsing the JSON data into instances of each searchtag, and then attaching individual methods to each searchtag? (This seems like a lot of overhead, for no gain.)

Apologies in advance if it seems like I am picking at hairs. But I really want to get this stuff straight in my head.

Thanks,

Travis

Actually, the jQuery examples you posted are not procedual, they're OO. Specifically they are an implementation of chainable objects which comes from the Fluid Programming school of OO design.

Procedual would be something like:

var el = cssQuery("#searchTagList");
var templateObject = makeTemplate(el,"template_searchTagList");
processTemplate(templateObject,searchTagData);

Functional would be something like:

processTemplate(
    makeTemplate(
        cssQuery("#searchTagList"),
        "template_searchTagList"
    ),
    searchTagData
);

jQuery have done a pretty good job of objectifying the DOM API. It's OK to use it as an inspiration of your own OO DOM library. Another one that I'd recommend you to look at is YUI3 (YUI2 is very procedual).

Specifically, the general pattern of jQuery and YUI3 is:

nodeListConstructor(query_string).nodeMethods();

Where they define an OO-like node object to wrap around DOM HTMLElements and then another OO style nodeList object to allow you to batch process nodes. This in my humble opinion is a good design pattern.

You could use Javascript Module pattern to good effect here.

According to that pattern your searchTagList definition would change to:

var searchTagList = function() {
    searchTagData: JSONdata;
    return {
    renderList: function () { /*send to jTemplates */ },
    bindEdit: function() { /* attach edit-in-place */ }
   };
}();

The two functions renderList and bindEdit would still be able to access searchTagData but will remain inaccessible to code outside searchTagList module.

Observe that the anonymous function executes immediately and returns an object containing two public methods ( renderList and bindEdit ) that form a closure on the private member searchTagData.

You could read more about the Module pattern here.