1. Readability of UI code
   • Templating System
     • Compare:
       1. inner html:
          • html += "<span>" + user.name + "</span>";
       2. DOM code:
          • var span = document.createElement("span");
span.appendChild(document.createTextNode(user.name));
dom.appendChild(span);
       3. DOJO:
          • <span>${user.name}</span>
   • CSS that is specific to that widget is located within it's own file, making it easier to maintain.
2. Widget Autonomy
   • testability: Making widgets independent means that you can test them easily - you should be able to drop them on to any page, inject services, dependencies into them and test them independently of the rest of the app.
   • clear separation of concerns. Widgets make it easier to enforce MVC - the backing javascript code is the controller, the view is the template. The model is connected via topics and event handlers.
3. Do it one way - all ui code should be widgetized
   • Right now it's hard to trace where the code which creates a given UI element is located. Widgets and subwidgets make this easier ex. main page could look like: main.html

           <cosmo:canvas>
           </cosmo:canvas\>
           

     canvas.html:

           <div>
               <cosmo:sideBar/>
               <cosmo:timeContainer default="week"/>
               <cosmo:detailView/>
           <div/>
           

     sidebar.html:

           <div>
               <cosmo:dropdown source="cosmo.localrepository.loadedCollections" value="cosmo.localrepostitory.currentCollection" />
               <cosmo:minical subscriptions="{viewTimeRangeChange : this.handleChangeTimeRange}, itemSelected : this.handleItemSelected}"/>
           </div>
           

4. Dojo Data API
   • when Dojo data API becomes more integrated into widgets, standard way to bind data to UI

1. lifecycle - matt mentions he wanted to "pull out rendering" but if we use dojo there are already entry points into widget lifecycle functions. Let's not do the work of figuring out how to make a UI toolkit, let others do it for us
2. developer adoption
   • will be easier to pick up devs who have developed using dojo widgets.
   • will be easier to pick up other devs too, because we are doing everything consistently

Dojo Topics

1. We need this Application Event Architecture - right now we don't have one
2. Plug-ins - plug ins will be able respond to app events without messying up main code
3. maintainability - as new ui elements are added, we don't need to inform controller to update them
4. Independence of UI elements (sep. of concerns)
5. Topics are a public API. We must carefully construct the API together and document it well and use it consistently.