4

So I'm developing this web application in Django. The exact web framework doesn't matter, but the point is: We have a nice separation between code, data and the actual HTML. The further we go however, the more we find we'd like to keep on a single web page and make the interface respond to user actions via AJAX requests. Now I find myself writing all these handler functions which expect a particular input from the AJAX request and construct large parts of the page by basically concatenating strings and data. Suddenly it's 1999 again and I'm manually creating HTML strings. This can't be it?

So my question is, what's a decent pattern/framework/... to create HTML on the browser side in a systematic fashion? I'm aware there are some templating plug-ins for jQuery, before I commit to one of those however I wonder if there isn't a more fundamental approach to this problem that can't be all that rare?

Improve this question
2
  • 2
    I would strongly suggest exploring some type of client-side templating. (For example, Handlebars) Commented Dec 25, 2011 at 22:24
  • Generally it is a bad design to make your application completely dependent on JavaScript. You should make your page work with JavaScript disabled, even if it is only 2-3% of users that will ever disable it. This will allow your page to work on more platforms, and will make it run much faster on their machine. It is also much harder to detect, report, and repro bugs that happen in client side code. You can still use AJAX in scenarios like this to enhance the page, add fancy effects, get rid of things like page loads that make the client experience clunky, etc. Commented Dec 25, 2011 at 22:36

3 Answers 3

Reset to default
1

What I've done before is let my server do the processing and code generation. Keeps the load off the client.

You could load partials (views) and return them, json encoded or otherwise. If you use json, make the HTML be "content" in your response object or something similar.

This way, there's no code duplication since you can use the same views. The trick becomes how to split them up.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

thanks, that's a nice idea. for some reason, I've never thought of this before. has the advantage that we can keep logic and templates on the server-side. of course at the cost of bloating up the size of the ajax data to be transported. wonder if it makes sense to apply compression or if that's taken care of at deeper levels anyhow.. will leave unanswered for now just to keep the ideas coming...
Seriously, how big is a view? A few kb? I wouldn't worry about it = )
hehe that's my type of thinking usually, but you caught me in 'fundamental problem solving mode' ;)
I've never thought of keeping the load off the client as being a concern (unless you're building some really complicated HTML)
1

Instead of constructing html strings, have you considered holding an array of javascript dom objects inside of javascript classes which hold your relational database data in them and then just cycling those around / building them with AJAX based on user interactions? This is how I maintain a photo gallery of nearly 500 photos (broken into sets) on one page with dynamic preloading (allowing the user to have a full size image instantly when they select it).

Improve this answer

Comments

1

Also came across this 1999 feeling and settled for jQuery tmpl. It'll allow you to keep model and views separated and more time to concentrate on the business logic. You can define a template by using a script-tag of type text/x-jquery-tmpl anywhere within the documents body and use it by addressing it by its id.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.