views:

249

answers:

4

I've started to wrap my functions inside of Objects, e.g.:

var Search = {
  carSearch: function(color) {
  },
  peopleSearch: function(name) {
  },
  ...
}

This helps a lot with readability, but I continue to have issues with reusabilty. To be more specific, the difficulty is in two areas:

  1. Receiving parameters. A lot of times I will have a search screen with multiple input fields and a button that calls the javascript search function. I have to either put a bunch of code in the onclick of the button to retrieve and then martial the values from the input fields into the function call, or I have to hardcode the HTML input field names/IDs so that I can subsequently retrieve them with Javascript. The solution I've settled on for this is to pass the field names/IDs into the function, which it then uses to retrieve the values from the input fields. This is simple but really seems improper.

  2. Returning values. The effect of most Javascript calls tends to be one in which some visual on the screen changes directly, or as a result of another action performed in the call. Reusability is toast when I put these screen-altering effects at the end of a function. For example, after a search is completed I need to display the results on the screen.

How do others handle these issues? Putting my thinking cap on leads me to believe that I need to have an page-specific layer of Javascript between each use in my application and the generic methods I create which are to be used application-wide. Using the previous example, I would have a search button whose onclick calls a myPageSpecificSearchFunction, in which the search field IDs/names are hardcoded, which marshals the parameters and calls the generic search function. The generic function would return data/objects/variables only, and would not directly read from or make any changes to the DOM. The page-specific search function would then receive this data back and alter the DOM appropriately.

Am I on the right path or is there a better pattern to handle the reuse of Javascript objects/methods?

+1  A: 

Javascript is ridiculously flexible which means that your design is especially important as you can do things in many different ways. This is what probably makes Javascript feel less like lending itself to re-usability.

There are a few different notations for declaring your objects (functions/classes) and then namespacing them. It's important to understand these differences. As mentioned in a comment on here 'namespacing is a breeze' - and is a good place to start.

I wouldn't be able to go far enough in this reply and would only be paraphrasing, so I recommend buying these books:

Pro JavaScript Design Patterns

Pro Javascript techniques

Lewis
+1  A: 

I started out using the module pattern, but then started doing everything in jQuery plugins. The plugins allow to pass page specific options.

Using jQuery would also let you rethink the way you identify your search terms and find their values. You might consider adding a class to every input, and use that class to avoid specifically naming each input.

Mark
+5  A: 
T.J. Crowder
Very interesting stuff. I'm not sure how feasible the server-side javascript is going to be for me (can you share with us the technologies you use for this?), but I'll be looking into the module pattern and Prototype method you mentioned.
RenderIn
@Renderln: (Weird, I replied earlier but it's gone.) Right now a lot of my app work is on intranets using IIS because of the platform the app runs on, and so there I just use JScript (sometimes JScript.Net, but mostly just JScript). In some of my other work I use Rhino on top of a Java stack (Rhino being JS for the JVM). But there are other options, such as Google's freaky-fast V8 interpreter/compiler (the one they use in Chrome), which is available as an Apache module from at least one and I *think* two projects. SpiderMonkey is used server-side by CouchDB and others. You get the idea. :-)
T.J. Crowder
+1  A: 

(At the risk of sounding like the typical "use jQuery" answer we get on SO 100 times/day...)

No, don't use jQuery (necessarily :) But you should strongly consider using a framework of some sort, expressly for the purpose of solving your reuse problems. Ext JS is actually the framework I'm most familiar with, but any of the good ones will give you really nice tools for producing your own reusable, encapsulated and loosely-coupled code.

Just to throw out a few examples, Ext (and others) give you namespacing, built-in modularity/encapsulation, a robust custom event system (which solves "how do I avoid my objects referencing each other to pass values"), cross-browser support, etc. Not to mention solid architectural/design pattern examples to draw from for solving the types of issues you are struggling with. You could get great benefits from using a base framework even if you never touched the widgets that come with it.

bmoeskau