General information
The goal of Dijit is to provide a set of basic widgets which support theming, accessibility, and globalization. The widgets and widget infrastructure have been moved into a separate subproject called "Dijit" and vastly streamlined and with a new directory structure.
Widget code is found at dijit.* now (compared to dojo.widget.* in 0.4). Widgets live in various points in the hierarchy, including dijit.*, dijit.form.*, dijit.layout.*, etc. The actual list of supported widgets differs from 0.4, and the function set and API choices have generally been simplified in favor of usability and quality. The parser has been redesigned and removes some significant performance bottlenecks from the previous release. Widgets and their style sheets are no longer loaded automatically, so the method of instantiating widgets has changed substantially.
Creating widgets from markup
To use markup in a page, you must require the Dojo parser along with any widgets referenced, and enable a page scan using the "parseOnLoad" setting:
<script type="text/javascript" src="../../dojo/dojo.js"
djConfig="parseOnLoad: true"></script>
<script type="text/javascript">
dojo.require("dijit.form.Button");
dojo.require("dojo.parser");
</script>
References to widgets use the dojoType attribute on some HTML tag. The name must be fully qualified using the Javascript package, and references are case-sensitive. XHTML-style namespaces and Dojo-specific tags are no longer supported. These two styles of declaration in 0.4
<button dojoType="button">...
<dojo:button>...are replaced by
<button dojoType="dijit.form.Button">...
Programmatic creation of widgets
In place of dojo.widget.createWidget(), simply use the Javascript "new" constructor:
var button1 = new dijit.form.Button(params, srcNodeRef);
where srcNodeRef is a reference to an existing DOM node or id string.
Many widgets now have a startup() method that you must call after the widget is created and you have done addChild() for all of it's children
accordion = new dijit.layout.AccordionContainer({}, dojo.byId("accordionShell"));
accordion.addChild(new dijit.layout.ContentPane());
accordion.addChild(new dijit.layout.ContentPane());
accordion.addChild(new dijit.layout.ContentPane());
accordion.startup();
Styling and Themes
Dijit ships with a default theme called "Tundra". The widget implementations no longer bootstrap with their own CSS. The style sheets for Dijit must now be loaded by the developer in the HTML page. For example:
<style type="text/css"> @import "../dijit/themes/tundra/tundra.css"; </style>
And then on the <body> tag add class=tundra:
<body class="tundra">
Please see the manual for more details on theming, about using different themes or even multiple themes on the same page.
- Printer-friendly version
- Login or register to post comments
- Subscribe post
xhtml namespaces
Does the removal of the xhtml-style namespace notation mean that Dojo is not XHTML-compatible any more? What are your thoughts/proposals for using Dojo inside of XHTML strict pages? Afaik such pages wouldn't validate any more because of the dojotype attribute.
If my assumptions are right this seriously limits usefulness of Dojo for a wide range of applications - at least all applications that like to process non-html markup inside a XHTML page. Am i missing something? I seriously hope.
the parser
I guess I need to add documentation about the parser rationale somewhere, like the release notes.
There's a big religious war about whether pages validating or not is important and I don't want to beat that dead horse anymore.
My decision for Dijit (well now the parser is actually in Dojo but it started in Dijit) was that the parser doesn't support XML-like syntax BUT users can write their own parser that does. That would probably be a good addition to the DojoX widget project. We've gone to great pains in Dijit to make sure that there's a Chinese wall (is that the right term?) between the parser and the widgets, so that widgets don't assume anything about how widget parameters are declared... thus all you need to do is change the parser a little bit to get what you want.
xhtml compat and the parser
Being involved with XML and standardisation of XML languages i really don't think XHTML is something to be religious about. Of course you can take the pragmatic approach letting aside such details for a start. But to reach real interoperability within the chorus of markup languages it's simply the question if want to adhere to standards (in this case W3C) or not. If you want to spread the technology and being used in serious applications you getter go with the standards. Standards don't come by chance and if they are good they involve many man-years of hard thinking about exotic edge cases and interoperabiltiy with other technologies. You might think about standards as you like but following them makes sure your piece of software plays well with other related technologies.
That doesn't mean that i see e.g. namespace support as mandatory. But wasn't there a syntax allowing to create widgets by setting certain CSS classes. - something like class="dojo:button" ? This would be an escape cause it doesn't involve 'polluting' the (X)HTML markup with foreign attributes (dojotype).
I would be happy if the Dojo team would consider this option again.
class="dojo:button"
Yes, we could write an alternate parser that supported <button class="dojo:button"> but that would make CSS people mad at us for abusing the class attribute. And it doesn't address how to pass parameters to the widget either (think about widget parameters like iconClass that have no HTML equivalent attribute).
Or alternately we could implement a parser that supported <button dojo:class="dijit.Button" dojo:params="{iconClass: 'saveIcon'}"> and then write a DTD that allowed dojo:class and dojo:params as a parameter on any node.
At some point I may write alternate parsers that support either of those syntaxes but no immediate plans to. If it's really important to you, you should contribute a parser that does what you want.
parameter microformat
Using the 'class' attribute for such things is perfectly in shape with the HTML Spec:
http://www.w3.org/TR/html4/struct/global.html#h-7.5.2
It says:
"The class attribute has several roles in HTML:
* As a style sheet selector (when an author wishes to assign style information to a set of elements).
* For general purpose processing by user agents."
Further see the work on microformats using class assignments for attaching semantic information to content:
http://microformats.org/wiki/Main_Page
Therefore to think about a class attribute to be exclusively for attaching CSS classes is obviously a widespread but wrong assumption.
The following would be valid (x)html:
Developing a microformat for Dojo widget parametrization looks to me like a valueable thing to do. We use Dojo as a strategic component to give our XForms processor a dynamic interface but not being able to output valid xhtml brings us into danger of being laughed at one day. Missing that ability even might lock us (and Dojo) out of being used for serious applications where organisations enforce accessibility and certain standards. This would really be a pitty as i consider Dojo the best player currently in the cross-browser javascript league. If it comes to the worst i would implement that stuff myself though i'm not an javascript expert and would have hard times with that i fear.
Hey Joern, So we thought
Hey Joern,
So we thought long and hard about using "class" for declaring where widgets are located and eventually decided against it as the default. While it's in the spec, it's not clear that any arguments for "semanticness" of using "class" vs whimsical attributes actually hold water. That the microformat you propose somehow conforms to the validator seems to be its only advantage...and it's slower. We used to support the syntax you are suggesting, and the speed of parsing (from the potentially large) set of direct child elements is a huge speed loss. What *can* be done is to write an alternate version of dojo.parser which parses a microformat you describe. It's not much code, and we'd happily accept the patches.
That said, we may be adding some conventions (and widget support) for degraded forms of widget markup which better capture what people mean when they create widgets from markup. I don't think that'll change how we locate and provide *default* parsing of widget properties (outside of the alternate parser I described above), but it may fit better with how you think of providing data to widgets via markup.
Regards
Does the dojo Namespace for attributes still work in 0.9/1.0?
In the FAQ the use of the Dojo Namespace is offered as solution. I can understand, that you dropped <dojo:button since it doesn't fallback very well when JS is disabled. However <input type="button" dojo:dojoType="dijit.form.Button ... makes a lot of sense.
Does that still work?
I believe we nixed that...
I believe your answer is in the page above....
XHTML-style namespaces and Dojo-specific tags are no longer supported. These two styles of declaration in 0.4
<button dojoType="button">...
<dojo:button>...
are replaced by
<button dojoType="dijit.form.Button">...
ps. thats an 0.4.x FAQ page
-Karl
We dropped all but one way
We dropped all but one way of doing it, and that wasn't the way we went with. The performance impact of supporting multiple styles turns out to be very non-trivial.
Regards
Yes - but (and I might be picky)
Thx for the clarification. Reducing options for performance sounds like a sensible decision. However....
I'm fine if <dojo:button ../> is gone and class="dojo:button etc.
Is it really so
hardslow to support both <button dojoType="dijit...."> and <button dojo:dojoType="dijit....">?The background: while the non (x)HTML attributes don't matter for current browsers they do matter for current (validating) XML parsers. If you design some server side processing (think CMS templating) that generates Dojo enriched (x)HTML, you want to make sure your code is valid. By using stuff others have written (validating parsers) you could within well tested code check that nothing "slips through" that doesn't belong to the dojo and/or xHTML namespace. (and as usual: be generous in what you accept and stingy in what you emit :-) )
So my worry is not so much on the client side processing but on the server side generation (especially with possible templates where unknowing users provide questionable html parts, that you might want to clean before processing, but of course leave the dojo stuff in there).
Thoughts on that?
:-) stw