Here's some simple code to help you clean any string concatenation you
may have in your JS:

String.wrapTags = function(tag, args){
  var attributeString = '';
  var text;
  if (args.length == 2){
    text = args[1];
    var attributes = args[0];
    for(var i in attributes){
      attributeString = attributeString + ' ' + i + '="' + attributes
[i].toString() + '"';
    }
  } else{
    text = args[0];
  }
  return '<' + tag + attributeString + '>' + text.toString() + '</' +
tag + '>';
}

// syntax 1
String.prototype.toTD = function(attributes){return String.wrapTags
('td', [attributes, this];}
String.prototype.toUL = function(attributes){return String.wrapTags
('ul', [attributes, this];}
String.prototype.toTABLE = function(attributes){return String.wrapTags
('table', [attributes, this];}
   ... etc ...

// syntax 2 (preferred in most situations)
function TD(args) { return String.wrapTags('td', arguments);}
function UL(args) { return String.wrapTags('ul', arguments);}
function TABLE(args) { return String.wrapTags('table', arguments);}
   ... etc ...


This stands out quite nicely with the upper case function names from
the rest of your javascript - especially with syntax highlighting. Try
copying/pasting the following example code in your favourite JS editor
to see what I mean.

Eg:

// Using string concatenation: - yuck!
$('<div class="item">' +
  '<input type="text" value="' + aValue + '" />' +
  '<ul id="main-list">' +
    '<li>' + item1 + '</li>' +
    '<li>' + item2 + '</li>' +
    '<li>' + item3 + '</li>' +
  '</ul>' +
'</div>');

// Using new methods: - Better
$(
  DIV({'class': 'item'},
    INPUT({type: 'text', value: aValue},'') +
    UL({id: 'main-list'},
      LI(item1) +
      LI(item2) +
      LI(item3)
    )
  )
);

Notes:
a) This is NOT a substitute for applying design patterns/frameworks/
etc.
b) I'm not advocating you go and start writing truckloads of html
strings in your js.

Bayan

On Dec 8, 1:20 pm, David Lee <[email protected]> wrote:
> Gabe, thanks for the link. I think JS templating for jQuery is a great idea.
>
> Now if someone could just implement HAML in JS, it'd be impossible to render
> structurally malformed HTML with a typo, and it'd tidy up a bunch of view
> code...
>
>
>
> On Tue, Dec 8, 2009 at 1:15 PM, Gabe Hollombe <[email protected]> wrote:
> > Lately, I've had some similar thoughts myself, Craig.  I've been using John
> > Resig's micro templates approach for outputting html from json data
> > structures, but I still have a somewhat unstructured approach to where/how I
> > include event handlers on my pages. So, my reply isn't too much help here,
> > other than mentioning the micro templates approach.  But, at least you know
> > you're not the only one thinking about these things.
>
> > I'd be interested to hear other folks' thoughts as well.
> > -g
>
> > On Tue, Dec 8, 2009 at 12:27 PM, Craig Ambrose 
> > <[email protected]>wrote:
>
> >> Hi folks,
>
> >> I'm feeling the need for a bit of structure, like that provided like a
> >> framework like rails, for the client side of my rails apps. I'm
> >> finding that more and more I'm really disliking returning javascript
> >> from rails requests. Doing so makes lots of assumptions about the page
> >> that is making the request, and makes my rails actions less versatile.
> >> I'm also doing more and more on the client side, and so I really want
> >> to just talk to the rails app via JSON for all AJAX behavior.
>
> >> I could of course switch to a client side framework (like GWT, or EXT-
> >> JS), and could still use rails for a backend. However, I'm not saying
> >> that I want to built totally client heavy apps. I'm just saying that
> >> *when* I choose to use AJAX, I want to leave the task of presenting
> >> the result to the client. I still want to use a lot of non-ajax pages,
> >> as most of my work is still "webby", not just a single page app.
>
> >> So, my javascript is better than it used to be. I organise my
> >> javascript into classes, and put each class in a seperate file (using
> >> caching to combine them later). That's about the extent of it.
>
> >> Javascript programming (for the web) is by nature fairly event driven.
> >> It feels a lot like building desktop applications. I think my
> >> javascript could benefit from the structure a framework wold provide.
> >> In fact, I even think that MVC is the right pattern. Models could
> >> provide functionality on top of the simple data structures transmitted
> >> from the server as JSON. Controllers handle events on the page and
> >> decide what to do. Views may or may not be necessary, but html
> >> templating in javascript is sometimes necessary if we're building
> >> parts of the page on the fly.
>
> >> Most importantly though, a framework would give me expected directory
> >> structure, common plugin structure, and encouragement to test. The
> >> benefits would be many, including making it easier to spot duplication
> >> (due to the common structure), and easing multi-developer work.
>
> >> What options do I have here? What have people tried for rails? I've
> >> used EXTJS before, but I'm looking for a way of organising my JS
> >> inside rails, not an actual javascript interface library. Does anyone
> >> know of any plugins, or have any thoughts?
>
> >> cheers,
>
> >> Craig
>
> >> --
>
> >> You received this message because you are subscribed to the Google Groups
> >> "Ruby or Rails Oceania" group.
> >> To post to this group, send email to [email protected].
> >> To unsubscribe from this group, send email to
> >> [email protected]<rails-oceania%[email protected]>
> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/rails-oceania?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "Ruby or Rails Oceania" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<rails-oceania%[email protected]>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/rails-oceania?hl=en.
>
> --
> cheers,
> David Lee

--

You received this message because you are subscribed to the Google Groups "Ruby 
or Rails Oceania" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/rails-oceania?hl=en.


Reply via email to