createChildren(), measure() and updateDisplayList() are delegated to “skins”
“ skins” are defined in (MX)ML
component only contains the logic and delegate rendering to the skin
properties in the skin can be bound to component or data properties
Custom Components (Dojo)
Relatively (compare to Flex) looser component model / lifecycle in Dojo:
constructor + constructor parameters mixin
buildRendering, (possibly from a HTML template)
setters (with side effect but without notification, even those without attribute value)
no general invalidation/validation mechanism, property-based.
Custom Components (Pros & Cons)
Looser component model can be good ... or not
Good because you don’t have too much constraints and can adapt your code to your exact needs.
Bad because each component might invent his own way and you don’t have coding pattern consistency.
No size management lifecycle (natural size request etc...) in Dojo except Container sizing the children DOM nodes or calling resize method if available. Not much a problem with HTML+CSS components sized a bit more problematic with GFX components. https://gist.github.com/879552
No properties validation/invalidation mechanism in Dojo:
Good cause lightweight.
Bad for complex components with dozens of complex property to set leading to dozens of refresh.
A tradeoff would be a simple validation/invalidation at component level using setTimeout, that solves the useless refreshes issue while still being lightweight.
Quite similar in Flex and Dojo for simple widgets relying on HTML templates and CSS .
No equivalent to “skins” for complex widgets that requires vector drawing (GFX).
This is leveraged in the library itself to keep download size reasonable when you do not need advanced features like Bidi text.
In Flex you would have to modify the library itself, recompile it and use your own version for your application. But in that case you lose standard library advantages like local caching of the library code by the Flash Player.
Landing in Dojo community from a community where contributions are difficult is exciting, you can really expect to have an impact on the toolkit!
Documentation holes: your help needed! Submit doc patches, edit dojocampus.org!
Component usage consistency for easier learning / customization:
new components should try to follow existing patterns as much as they can
might need to introduce lightweight patterns for non covered use-case like invalidation
Simpler application / component coding:
widen the use of markup besides application & HTML templates (customization of GFX based components)