Dojo Toolkit from a Flex developer's perspective

2,914 views

Published on

DojoConf 2011 presentation

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,914
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Dojo licensing a bit more flexible.
  • setters must be done after buildRendering because usually their action is immediate and require DOM to be present.
  • No properties validation/invalidation leads to inconsistency like charting not refreshing on property change.
  • Dojo Toolkit from a Flex developer's perspective

    1. 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. 2. Who am I to talk about this? <ul><li>Nearly 15 years of experience in visualization component development. </li></ul><ul><li>I might have strong opinions about component architecture & development but I’m usually technology agnostic and like to discover new platforms and leverage them. </li></ul><ul><li>Initially for desktops (Java, Swing) but moved to the Web in the early 2000 with JSF server-side and DHTML then SVG client-side. </li></ul><ul><li>End 2006 got the opportunity to start the development of a new set of visualization components in Adobe Flex, still leading it. </li></ul><ul><li>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...) </li></ul>
    3. 3. What will this presentation be about / Why should you be interested? <ul><li>What is the journey of a seasoned Flex developer approaching Dojo? </li></ul><ul><li>Mostly about UI components not much on other facilities as most of Flex is UI. </li></ul><ul><li>Particular focus on custom components and how to create them. </li></ul><ul><li>Always good to learn how you compare to others. </li></ul><ul><li>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. </li></ul>
    4. 4. What this presentation is not about <ul><li>This is not an exhaustive (or even slightly complete) comparison of Flex and Dojo </li></ul>
    5. 5. Licensing / Web site / Documentation <ul><li>Both projects have open source licenses: BSD + Academic for Dojo and MPL for Flex (+ Adobe own license for some bits). </li></ul><ul><li>Documentation presentation is pretty similar, API doc and reference guide. </li></ul><ul><ul><li>Dojo reference guide is not versioned, might be troublesome when working with “older” versions. </li></ul></ul><ul><ul><li>Dojo API documentation contains quite big holes (especially in dojox.*). </li></ul></ul><ul><li>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. </li></ul><ul><li>Obviously more marketing is going on around Flex including Websites showcasing real world applications by customers. </li></ul>
    6. 6. Community <ul><li>Dojo does have a thriving open source development community: </li></ul><ul><ul><li>Lots of contributors / committers with different background / employers. </li></ul></ul><ul><li>For Flex, all committers are Adobe </li></ul><ul><ul><li>Only very few external contributors and limited to bug fixing. </li></ul></ul><ul><ul><li>Might change with the Spoon project. </li></ul></ul><ul><li>Access to development code? </li></ul><ul><ul><li>Flex development used to be in the open, now done privately, only release code is visible. </li></ul></ul><ul><ul><li>Dojo development entirely in the open. </li></ul></ul><ul><li>Access to development teams discussion? </li></ul><ul><ul><li>Both have public bug/feature tracking (Trac vs JIRA). </li></ul></ul><ul><ul><li>Weekly IRC meetings in Dojo, read-only contributors mailing list. </li></ul></ul><ul><ul><li>Connect Open Iteration meetings on Flex side (but not really each iteration...). </li></ul></ul><ul><li>Users community are somewhat comparable (quite enthusiastic). </li></ul>
    7. 7. Predefined Components (Flex) <ul><li>Basic (form) components + containers + charting + advanced table, besides that you need to look around. </li></ul><ul><li>You find two component models the old one MX and the new one Spark. </li></ul><ul><li>Spark is basically MX + the ability to define the rendering of the component entirely in (MX)ML instead of API drawing: </li></ul><ul><ul><li>That way both your application and components rendering can be done in markup. </li></ul></ul><ul><li>Except for rendering customization they share the same usage model: </li></ul><ul><ul><li>get/set for regular property triggers automatic (lazy) refresh. </li></ul></ul><ul><ul><li>CSS for style properties triggers automatic (lazy) refresh. </li></ul></ul><ul><ul><li>all components take data using either value (simple) or dataProvider property </li></ul></ul><ul><ul><ul><li>for flat model use IList as input (list data abstraction). </li></ul></ul></ul><ul><ul><li>itemRenderer all take IItemRenderer as input. </li></ul></ul><ul><ul><li>mapping through the data fields and the component using xxxField/xxxFunction pattern or using data binding in the ItemRenderer. </li></ul></ul>
    8. 8. Predefined Components (Dojo) <ul><li>Pretty much everything can be found in the toolkit either in dijit or dojox. </li></ul><ul><li>In Dojo component model is a bit less consistent: </li></ul><ul><ul><li>Dijit / CSS+HTML components (dijit.*, dojox.widget.*). </li></ul></ul><ul><ul><li>non-Dijit / GFX components (dojox.charting, dojox.geo.*) </li></ul></ul><ul><ul><li>Dijit / GFX components (dojox.charting.widget, dojox.geo.*.widget) </li></ul></ul><ul><ul><li>non-Dijit / CSS+HTML components (dojox.gantt.*) </li></ul></ul><ul><li>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: </li></ul><ul><ul><li>Only your application and some level of customization can be done in markup. </li></ul></ul><ul><li>Usage patterns are not always consistent: </li></ul><ul><ul><li>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.*) </li></ul></ul><ul><ul><li>mapping just as in Flex with xxxAttr (instead of xxxField) </li></ul></ul><ul><ul><li>When updating a property some components: </li></ul></ul><ul><ul><ul><li>do refresh automatically (Button.set(“label”, mylabel)) </li></ul></ul></ul><ul><ul><ul><li>requires you to call a method like render (dojox.charting) to refresh </li></ul></ul></ul><ul><ul><ul><li>or not (Tooltip.label) </li></ul></ul></ul><ul><ul><li>item rendering switch can consist in changing TreeNode or its template for Tree or DataGrid cellType property. </li></ul></ul>
    9. 9. Custom Components (Flex) <ul><li>Strong component model / lifecycle (MX): </li></ul><ul><li>Initialization (simplified): </li></ul><ul><ul><li>constructor </li></ul></ul><ul><ul><li>setters are called with markup attributes values if any </li></ul></ul><ul><ul><li>attachment </li></ul></ul><ul><ul><li>createChildren </li></ul></ul><ul><ul><li>initialized </li></ul></ul><ul><ul><li>first validation: </li></ul></ul><ul><ul><ul><li>commitProperties </li></ul></ul></ul><ul><ul><ul><li>measure (natural size request) </li></ul></ul></ul><ul><ul><ul><li>updateDisplayList (concrete sizing) </li></ul></ul></ul><ul><ul><li>creationComplete </li></ul></ul><ul><li>Updates: </li></ul><ul><ul><li>invalidateProperties, invalidSize, invalidDisplayList trigger respectively </li></ul></ul><ul><ul><li>commitProperties, measure, updateDisplayList </li></ul></ul><ul><li>Destruction: </li></ul><ul><ul><li>detachment </li></ul></ul>
    10. 10. Custom Components (Flex) <ul><li>In Flex new component model (Spark): </li></ul><ul><li>createChildren(), measure() and updateDisplayList() are delegated to “skins” </li></ul><ul><li>“ skins” are defined in (MX)ML </li></ul><ul><li>component only contains the logic and delegate rendering to the skin </li></ul><ul><li>properties in the skin can be bound to component or data properties </li></ul>
    11. 11. Custom Components (Dojo) <ul><li>Relatively (compare to Flex) looser component model / lifecycle in Dojo: </li></ul><ul><li>Initialization: </li></ul><ul><ul><li>constructor + constructor parameters mixin </li></ul></ul><ul><ul><li>postMixInProperties, </li></ul></ul><ul><ul><li>buildRendering, (possibly from a HTML template) </li></ul></ul><ul><ul><li>setters (with side effect but without notification, even those without attribute value) </li></ul></ul><ul><ul><li>postCreate, </li></ul></ul><ul><ul><li>startup </li></ul></ul><ul><li>Updates: </li></ul><ul><ul><li>no general invalidation/validation mechanism, property-based. </li></ul></ul><ul><li>Destruction: </li></ul><ul><ul><li>destroy. </li></ul></ul>
    12. 12. Custom Components (Pros & Cons) <ul><li>Looser component model can be good ... or not </li></ul><ul><ul><li>Good because you don’t have too much constraints and can adapt your code to your exact needs. </li></ul></ul><ul><ul><li>Bad because each component might invent his own way and you don’t have coding pattern consistency. </li></ul></ul><ul><li>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 </li></ul><ul><li>No properties validation/invalidation mechanism in Dojo: </li></ul><ul><ul><li>Good cause lightweight. </li></ul></ul><ul><ul><li>Bad for complex components with dozens of complex property to set leading to dozens of refresh. </li></ul></ul><ul><ul><li>A tradeoff would be a simple validation/invalidation at component level using setTimeout, that solves the useless refreshes issue while still being lightweight. </li></ul></ul><ul><ul><li>https://github.com/cjolif/dojo-treemap/blob/master/dojox/widget/_Invalidating.js </li></ul></ul><ul><li>Separation of component logic and rendering: </li></ul><ul><ul><li>Quite similar in Flex and Dojo for simple widgets relying on HTML templates and CSS . </li></ul></ul><ul><ul><li>No equivalent to “skins” for complex widgets that requires vector drawing (GFX). </li></ul></ul>
    13. 13. Extensibility/”Patchability” <ul><li>Dojo gets JavaScript advantages in term of patching the library, you can basically monkey patch the lib if something goes wrong with it. </li></ul><ul><li>This is leveraged in the library itself to keep download size reasonable when you do not need advanced features like Bidi text. </li></ul><ul><li>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. </li></ul>
    14. 14. Conclusion <ul><li>Landing in Dojo community from a community where contributions are difficult is exciting, you can really expect to have an impact on the toolkit! </li></ul><ul><li>Documentation holes: your help needed! Submit doc patches, edit dojocampus.org! </li></ul><ul><li>Component usage consistency for easier learning / customization: </li></ul><ul><ul><li>new components should try to follow existing patterns as much as they can </li></ul></ul><ul><ul><li>might need to introduce lightweight patterns for non covered use-case like invalidation </li></ul></ul><ul><li>Simpler application / component coding: </li></ul><ul><ul><li>widen the use of markup besides application & HTML templates (customization of GFX based components) </li></ul></ul><ul><ul><li>improve data binding abilities in markup </li></ul></ul>
    15. 15. <ul><li>Questions? </li></ul><ul><li>[email_address] </li></ul>

    ×