It's a common misconception that user input can be filtered. PHP even has a (now deprecated) "feature", called magic-quotes, that builds on this idea. It's nonsense. Forget about filtering (or cleaning, or whatever people call it).
What you should do, to avoid problems, is quite simple: whenever you embed a a piece of data within a foreign code, you must treat it according to the formatting rules of that code. But you must understand that such rules could be too complicated to try to follow them all manually. For example, in SQL, rules for strings, numbers and identifiers are all different. For your convenience, in most cases there is a dedicated tool for such an embedding. For example, when you need to use a PHP variable in the SQL query, you have to use a prepared statement, that will take care of all the proper formatting/treatment.
Another example is HTML: If you embed strings within HTML markup, you must escape it with htmlspecialchars. This means that every single echo or print statement should use htmlspecialchars.
A third example could be shell commands: If you are going to embed strings (such as arguments) to external commands, and call them with exec, then you must use escapeshellcmd and escapeshellarg.
Also, a very compelling example is JSON. The rules are so numerous and complicated that you would never be able to follow them all manually. That's why you should never ever create a JSON string manually, but always use a dedicated function, json_encode() that will correctly format every bit of data.
And so on and so forth ...
The only case where you need to actively filter data, is if you're accepting preformatted input. For example, if you let your users post HTML markup, that you plan to display on the site. However, you should be wise to avoid this at all cost, since no matter how well you filter it, it will always be a potential security hole.
I am not an expert in Dojo widgets, but this is what I know:
All Dojo widget constructors have signature:
var widget = new Widget(params, node);
The best way to discover params is to look at the source code — don't get scared, they would be documented variables at the beginning of a relevant class.
The relevant file is usually simple to find using the name of the widget because they are named by their path.
The best way to look up this stuff is to use a Dojo checkout with your favorite text editor. But the nightly checkout works too (if you follow the trunk). Or the Trac source browser.
Don't underestimate the power of looking at tests and demos.
Example: dijit.layout.TabContainer ⇒ dijit/layout/TabContainer.js. If the file is missing look into directories of the hierarchy for _base.js, or some similarly sounding files — the latter can bundle related classes together. But in most cases (like with TabContainer) you'll find it immediately. Let's go and look.
There are two public documented parameters in the top of the class:
- tabPosition — String. Defines where tabs go relative to tab content. "top", "bottom", "left-h", "right-h". Default: "top".
- tabStrip — bool. Defines whether the tablist gets an extra class for layouting. Default: false.
- _controllerWidget — just ignore it, no public parameters start with the underscore — it is a common JavaScript convention to designate protected members.
But it is not all. TabContainer is based on dijit.layout.StackContainer (just look at the dojo.declare() header). We can use StackContainer's public parameters as well:
- doLayout — Boolean. If true, change the size of my currently displayed child to match my size. Default: true.
- persist — Boolean. Remembers the selected child across sessions. Default: false.
As you can see the code and parametrs are nicely documented, yet not always reflected in the API tool. Now we can create the tab container with confidence.
But let's see it in action first. All Dijit tests are always in dijit/tests. Any dijit.layout.* widget will be tested in dijit/tests/layout. The relevant test file would be named something like test_TabContainer.html, and in fact I see 5 files for that:
For example, let's recreate the first TabContainer of test_TabContainer.html:
var tc = new dijit.layout.TabContainer(
{persist: true, tabStrip: true}, "mainTabContainer");
Or we can do it like in the test inline:
<div id="mainTabContainer" dojoType="dijit.layout.TabContainer"
persist="true" tabStrip="true" style="width: 100%; height: 20em;">
...
</div>
Coming back to your original question: now you can see that width and height are specified simply as styles, no special attributes, nothing fancy, just some intuitive CSS. So if you want to do it programmatically, just set them on a node before creating a new instance of TabContainer.
Yeah, I wish the API doc got all these small details too, but the whole setup is intuitive, and relevant parts are documented right in the file. We did go to the source code, but we didn't try to decipher the source code, just read human-readable comments on the top of the class.
Best Answer
For future users of the site that are looking for similar information. In order to do this you must reset the decorator stack, setting the id while you are doing it.