Good way to chunk HTML code?

[Zamfir]

I recently made some little javascript programs, and each of them has a simple HTML page to provide UI elements.

I then wanted to put hem together on a single larger page, with some cooperation between them. On the javascript side, I can keep this nice and organized. The standalone programs have their own file or files, they each get an interface object that raises events and allows to get and set data, and the cooperation code can ignore the internal details of each subpart.

But I have no idea how to do something similar on the HTML side. I now have a single large (IMO) HTML file with lots and lots of elements in them, organized only by divs.

My gut feeling says that the main page should only contain overall layout, plus tags that say "the drawing UI goes here". While the actual HTML for the drawing UI is in some other file, where I can maintain it together with the drawign code behind it. So the main html page knows where the subparts' UIs are, the cooperation code knows the interface of the subparts, and the details of the subparts can change while the overall setup stays the same.

Is there some good way to do that? I have considered programmatically inserting the elements into the DOM, or using innerhtml to insert the code, but both feel clumsy.

[freakish777]

Are you doing this all in straight HTML, or are you doing this with a server side language as well (C#/Java/PHP)?

CSS can mitigate some of what you're talking about by ensuring a consistent look/feel to objects, but I'm assuming this isn't what you're after.

If you're using C#/ASP.NET, then you want to looking into both MasterPages and (more importantly) User Controls (C#'s building block, which goes in an .ascx files instead of an .aspx file and has different run time properties). My understanding of PHP is that you can separate out everything into individual files, and then have other files call the first one (the building block as it were). I assume Java allows something similar.


I'm unsure of a way to make "building blocks" that you maintain strictly in (and call from other) HTML files.

[Zamfir]

Yeah, something like usercontrols is what I had in mind, but then a for a pure html+javascript page. I guess I might be pushing how far I can take a pure client-side, browser-based program.

Keeping the program that way is extremely attractive, it makes it easy to turn into a desktop or phone widget for example. And it can run on an off-line Kindle!

[freakish777]

Are you currently using jQuery to set an elements innerHTML property? Shouldn't you be able to put HTML into individual files and then use jQuery's load method?

[Zamfir]

No, I am not using jQuery. The load method comes pretty close, I guess. An xmlhttprequest + innerhtml does basically the same, but reading around on the internet gives me the impression that people don't like to do such things if they can avoid it.

Might be speed issue? Faster to build the entire page up on the server side, then send it as one file?

[Steax]

jQuery's load function is more or less exactly for what you've described, and is the solution I'd go with. It's also very easy and quick, though ideally you also want to use the HTML 5 history API to change the URL and support history operations.

It won't be significantly slow. I use it quite liberally in some applications and it's not slow at all.

[Zamfir]

Until now I've avoided jQuery, as yet-another-thing to learn. I'd like to postpone that a bit more if possible, but perhaps this is the right time to look into it.

Would a jquery's load have advantages over a self-made little function that uses xmlhttprequest and writes the retrieved text to innerhtml? Safety checks for example?

[Xanthir]

Not really. The jQuery function is quite simple, it just handles cross-browser compat.

[Steax]

But you do gain quite a bit from learning jQuery, and from my experience it's one of the easiest libraries to get into. To learn any particular aspect, like the ajax load() function, you really just need to learn this:

Code: Select all

$('#css-esque-ID-selector').load('your-html-file.html');


It has option to include a callback and all that, it's not much to learn.

I do admit it doesn't give a huge advantage; jQuery mostly just streamlines (development-wise) and works out corner-cases and other cross-browser issues.

[Zamfir]

I am not really doing web development here, so cross-browser compatibility or browser history are not high on the list. I've run into a few places where jQuery might be a little help, just never into a single must-have case.

With respect to this:

Code: Select all

$('#css-esque-ID-selector').load('your-html-file.html');


Is it common to mix actions on an element with the identification of the element, like here? I've mostly tried to keep those separated: if functions or objects works on elements, they will require javascript references to elements. While some other place in the code is responsible for identifying those elements and passing them to the objects that require them.

[Xanthir]

There's nothing wrong with it, though if your architecture favors separating the two, that's fine too.

[Zamfir]

Thanks! Does that work in jQuery as well? Jquery example code seems to follow that pattern of identifying elements, than directly performing action on it through the chained dots.

But if I understood right, you can't perform jQuery operations on javascript references to elements?

[Steax]

You can:

Code: Select all

var container = $("#id");

container.load("foobar.html");


It's just more common to do them straight off because most web development involves one-offs. When you need to do a certain routine on a selection often, you're also usually better off extending the jQuery object (i.e. a 'plugin') rather than a function.

[Xanthir]

I'm not entirely sure I understand the question, because I think your understanding of the model is a little incomplete, and I'm not quite sure at what level to respond on.

I'll just say that in "foo().bar()", you're calling the bar method of whatever foo() returned. jQuery always returns jQuery objects, so you can call jQuery methods on it. If you use a DOM search method, like document.querySelector(), you'll get a DOM element, so you can call DOM methods on it.

[Steax]

I think he meant something along the lines of:

Code: Select all

function do_something(elements){ /**/ }

var collection = document.getElementById("foo");

do_something(collection);


[Zamfir]

I had some trouble parsing the special jQuery syntax, especially the dollar-sign.

If I understand it, the dollar-sign is just a very short variable name, and it is overloaded to do some different actions. Without arguments it is the namespace of the library, with a string it is a selector function, with a DOM element it translates from DOM element to a jQuery object. Most of jQuery's functionality is accesible as methods of jQuery objects, and those methods usually return jQuery objects which allows for chaining.

Is that right? The result does looks almost as if someone grafted extra syntax on javascript.

EDIT: anyway, thanks for answering my questions with patience! I know they are a bit unfocussed. They;re not really issues I am stuck with, more issues where I am unhappy with what I am doing.

[Steax]

You're pretty much correct.

The $ is just a heavily-overloaded object. It's technically the "jQuery object"; it's just abbreviated to a dollar-sign for brevity. You can also call it as jQuery.ajax() or jQuery(".foobar").

It's very much like a different syntax, but I've learned to love it. Chaining is the important concept to parse it well; most of the time it just goes "select elements according to selector n, and do a, b, and c." Other methods work upon jQuery objects to modify the selection scope, modify the selected items, and other wacky things.