Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Dojo Toolkit from a Flex developer's perspective

•
•
C
cjolif

The document summarizes a presentation given by a Flex developer about their experience transitioning to using the Dojo toolkit. Some key points of comparison between Flex and Dojo include: - Dojo has a more loose and flexible component model compared to Flex, which can be both an advantage and disadvantage. - Dojo lacks some of the standardized component lifecycle and property validation mechanisms that Flex provides. - Both frameworks provide many predefined UI components, but Dojo's components are more varied in their implementation patterns. - Custom component authoring is similar between the frameworks when using HTML templates, but Dojo lacks an equivalent to Flex's skinning system for complex graphics components. - Dojo has advantages for ext

1 of 15
Dojo Toolkit from a Flex developer’s perspective Christophe Jolif , Senior Software Engineer, IBM Software Group, ILOG Visualization 17 September 2011 DojoConf, 2011 Washington, DC
Who am I to talk about this? Nearly 15 years of experience in visualization component development. I might have strong opinions about component architecture & development but I’m usually technology agnostic and like to discover new platforms and leverage them. Initially for desktops (Java, Swing) but moved to the Web in the early 2000 with JSF server-side and DHTML then SVG client-side. End 2006 got the opportunity to start the development of a new set of visualization components in Adobe Flex, still leading it. In 2010, following IBM acquisition I started working in a parallel with the Dojo Toolkit and since 2011 I’m contributing actively to Dojo (charting, treemap...)
What will this presentation be about / Why should you be interested? What is the journey of a seasoned Flex developer approaching Dojo? Mostly about UI components not much on other facilities as most of Flex is UI. Particular focus on custom components and how to create them. Always good to learn how you compare to others. Would also like to create discussion on how as a community we can help Dojo enlarge its audience by lowering entry barrier for users of non-javascript RIA frameworks such as Flex or Silverlight.
What this presentation is not about This is not an exhaustive (or even slightly complete) comparison of Flex and Dojo
Licensing / Web site / Documentation Both projects have open source licenses: BSD + Academic for Dojo and MPL for Flex (+ Adobe own license for some bits). Documentation presentation is pretty similar, API doc and reference guide. Dojo reference guide is not versioned, might be troublesome when working with “older” versions. Dojo API documentation contains quite big holes (especially in dojox.*). New comers might be confused by dojocampus.org vs dojotoolkit.org. This is not obvious at first glance that one is an on going wiki while another one is latest release documentation. Obviously more marketing is going on around Flex including Websites showcasing real world applications by customers.
Community Dojo does have a thriving open source development community: Lots of contributors / committers with different background / employers. For Flex, all committers are Adobe Only very few external contributors and limited to bug fixing. Might change with the Spoon project. Access to development code? Flex development used to be in the open, now done privately, only release code is visible. Dojo development entirely in the open. Access to development teams discussion? Both have public bug/feature tracking (Trac vs JIRA). Weekly IRC meetings in Dojo, read-only contributors mailing list. Connect Open Iteration meetings on Flex side (but not really each iteration...). Users community are somewhat comparable (quite enthusiastic).
Predefined Components (Flex) Basic (form) components + containers + charting + advanced table, besides that you need to look around. You find two component models the old one MX and the new one Spark. Spark is basically MX + the ability to define the rendering of the component entirely in (MX)ML instead of API drawing: That way both your application and components rendering can be done in markup. Except for rendering customization they share the same usage model: get/set for regular property triggers automatic (lazy) refresh. CSS for style properties triggers automatic (lazy) refresh. all components take data using either value (simple) or dataProvider property for flat model use IList as input (list data abstraction). itemRenderer all take IItemRenderer as input. mapping through the data fields and the component using xxxField/xxxFunction pattern or using data binding in the ItemRenderer.
Predefined Components (Dojo) Pretty much everything can be found in the toolkit either in dijit or dojox. In Dojo component model is a bit less consistent: Dijit / CSS+HTML components (dijit.*, dojox.widget.*). non-Dijit / GFX components (dojox.charting, dojox.geo.*) Dijit / GFX components (dojox.charting.widget, dojox.geo.*.widget) non-Dijit / CSS+HTML components (dojox.gantt.*) Just as in Flex, CSS+HTML components support markup templates however GFX components do not support markup rendering, they are all defined using API rendering: Only your application and some level of customization can be done in markup. Usage patterns are not always consistent: store property (dojo.store and/or dojo.data) vs setStore function (dojox.grid) vs DataSeries ctor argument vs no data input at all (dojox.gantt.*) mapping just as in Flex with xxxAttr (instead of xxxField) When updating a property some components: do refresh automatically (Button.set(“label”, mylabel)) requires you to call a method like render (dojox.charting) to refresh or not (Tooltip.label) item rendering switch can consist in changing TreeNode or its template for Tree or DataGrid cellType property.
Custom Components (Flex) Strong component model / lifecycle (MX): Initialization (simplified): constructor setters are called with markup attributes values if any attachment createChildren initialized first validation: commitProperties measure (natural size request) updateDisplayList (concrete sizing) creationComplete Updates: invalidateProperties, invalidSize, invalidDisplayList trigger respectively commitProperties, measure, updateDisplayList Destruction: detachment
Custom Components (Flex) In Flex new component model (Spark): 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: Initialization: constructor + constructor parameters mixin postMixInProperties, buildRendering, (possibly from a HTML template) setters (with side effect but without notification, even those without attribute value) postCreate, startup Updates: no general invalidation/validation mechanism, property-based. Destruction: destroy.
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. https://github.com/cjolif/dojo-treemap/blob/master/dojox/widget/_Invalidating.js Separation of component logic and rendering: 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).
Extensibility/”Patchability” Dojo gets JavaScript advantages in term of patching the library, you can basically monkey patch the lib if something goes wrong with it. 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.
Conclusion 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) improve data binding abilities in markup
Questions? [email_address]

More Related Content

Dojo Toolkit from a Flex developer's perspective

  • 1. Dojo Toolkit from a Flex developer’s perspective Christophe Jolif , Senior Software Engineer, IBM Software Group, ILOG Visualization 17 September 2011 DojoConf, 2011 Washington, DC
  • 2. Who am I to talk about this? Nearly 15 years of experience in visualization component development. I might have strong opinions about component architecture & development but I’m usually technology agnostic and like to discover new platforms and leverage them. Initially for desktops (Java, Swing) but moved to the Web in the early 2000 with JSF server-side and DHTML then SVG client-side. End 2006 got the opportunity to start the development of a new set of visualization components in Adobe Flex, still leading it. In 2010, following IBM acquisition I started working in a parallel with the Dojo Toolkit and since 2011 I’m contributing actively to Dojo (charting, treemap...)
  • 3. What will this presentation be about / Why should you be interested? What is the journey of a seasoned Flex developer approaching Dojo? Mostly about UI components not much on other facilities as most of Flex is UI. Particular focus on custom components and how to create them. Always good to learn how you compare to others. Would also like to create discussion on how as a community we can help Dojo enlarge its audience by lowering entry barrier for users of non-javascript RIA frameworks such as Flex or Silverlight.
  • 4. What this presentation is not about This is not an exhaustive (or even slightly complete) comparison of Flex and Dojo
  • 5. Licensing / Web site / Documentation Both projects have open source licenses: BSD + Academic for Dojo and MPL for Flex (+ Adobe own license for some bits). Documentation presentation is pretty similar, API doc and reference guide. Dojo reference guide is not versioned, might be troublesome when working with “older” versions. Dojo API documentation contains quite big holes (especially in dojox.*). New comers might be confused by dojocampus.org vs dojotoolkit.org. This is not obvious at first glance that one is an on going wiki while another one is latest release documentation. Obviously more marketing is going on around Flex including Websites showcasing real world applications by customers.
  • 6. Community Dojo does have a thriving open source development community: Lots of contributors / committers with different background / employers. For Flex, all committers are Adobe Only very few external contributors and limited to bug fixing. Might change with the Spoon project. Access to development code? Flex development used to be in the open, now done privately, only release code is visible. Dojo development entirely in the open. Access to development teams discussion? Both have public bug/feature tracking (Trac vs JIRA). Weekly IRC meetings in Dojo, read-only contributors mailing list. Connect Open Iteration meetings on Flex side (but not really each iteration...). Users community are somewhat comparable (quite enthusiastic).
  • 7. Predefined Components (Flex) Basic (form) components + containers + charting + advanced table, besides that you need to look around. You find two component models the old one MX and the new one Spark. Spark is basically MX + the ability to define the rendering of the component entirely in (MX)ML instead of API drawing: That way both your application and components rendering can be done in markup. Except for rendering customization they share the same usage model: get/set for regular property triggers automatic (lazy) refresh. CSS for style properties triggers automatic (lazy) refresh. all components take data using either value (simple) or dataProvider property for flat model use IList as input (list data abstraction). itemRenderer all take IItemRenderer as input. mapping through the data fields and the component using xxxField/xxxFunction pattern or using data binding in the ItemRenderer.
  • 8. Predefined Components (Dojo) Pretty much everything can be found in the toolkit either in dijit or dojox. In Dojo component model is a bit less consistent: Dijit / CSS+HTML components (dijit.*, dojox.widget.*). non-Dijit / GFX components (dojox.charting, dojox.geo.*) Dijit / GFX components (dojox.charting.widget, dojox.geo.*.widget) non-Dijit / CSS+HTML components (dojox.gantt.*) Just as in Flex, CSS+HTML components support markup templates however GFX components do not support markup rendering, they are all defined using API rendering: Only your application and some level of customization can be done in markup. Usage patterns are not always consistent: store property (dojo.store and/or dojo.data) vs setStore function (dojox.grid) vs DataSeries ctor argument vs no data input at all (dojox.gantt.*) mapping just as in Flex with xxxAttr (instead of xxxField) When updating a property some components: do refresh automatically (Button.set(“label”, mylabel)) requires you to call a method like render (dojox.charting) to refresh or not (Tooltip.label) item rendering switch can consist in changing TreeNode or its template for Tree or DataGrid cellType property.
  • 9. Custom Components (Flex) Strong component model / lifecycle (MX): Initialization (simplified): constructor setters are called with markup attributes values if any attachment createChildren initialized first validation: commitProperties measure (natural size request) updateDisplayList (concrete sizing) creationComplete Updates: invalidateProperties, invalidSize, invalidDisplayList trigger respectively commitProperties, measure, updateDisplayList Destruction: detachment
  • 10. Custom Components (Flex) In Flex new component model (Spark): 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
  • 11. Custom Components (Dojo) Relatively (compare to Flex) looser component model / lifecycle in Dojo: Initialization: constructor + constructor parameters mixin postMixInProperties, buildRendering, (possibly from a HTML template) setters (with side effect but without notification, even those without attribute value) postCreate, startup Updates: no general invalidation/validation mechanism, property-based. Destruction: destroy.
  • 12. 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. https://github.com/cjolif/dojo-treemap/blob/master/dojox/widget/_Invalidating.js Separation of component logic and rendering: 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).
  • 13. Extensibility/”Patchability” Dojo gets JavaScript advantages in term of patching the library, you can basically monkey patch the lib if something goes wrong with it. 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.
  • 14. Conclusion 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) improve data binding abilities in markup

Editor's Notes

  1. Dojo licensing a bit more flexible.
  2. setters must be done after buildRendering because usually their action is immediate and require DOM to be present.
  3. No properties validation/invalidation leads to inconsistency like charting not refreshing on property change.