Question

In Seaside, in all those renderContentOn: methods, I can use the HTML canvas object to assemble my DOM tree.

I am writing a bunch of helpers for my components currently, because I’m using Twitter Bootstrap for the styling and don’t want to write all that boilerplate code (<div>s en mas) all the time.

For the way this is setup, the easiest way for me is to simply (I want to avoid using with: aBlock in those helpers) write out the HTML for the wrapping DIVs like this:

html html: '<div class="control-group">'.

Is there any reason for me not to do this? Any downsides?

Answer 1

There are various advantages in using the HTML canvas:

• The HTML canvas ensures valid tags, a valid tag structure, that all tags are properly closed (at compile time), and that contents is properly escaped.
• The HTML canvas ensures valid attributes, that all attributes are properly closed, and that contents is properly escaped.
• As a consequence of the above two the HTML canvas automatically avoids the possibility of cross-site scripting (XSS) vulnerabilities.
• The HTML canvas enables better reusability by enabling composition of tags (simple function calls), presenters (renderOn: in Objects), and components (renderContentOn: of components).
• The HTML canvas avoids generating unnecessary whitespaces.
• The use of HTML canvas enables one to use the standard tools the Smalltalk IDE provides on HTML code: senders, implementors, refactoring engine (extract to method, extract to component, inline method, automatic rewrite, …), etc.

I agree that in some rare cases it is not worth to use HTML canvas: For example, when large static junks coming from an external source need to be embedded into a page.