this space intentionally left blank * roadmap - definitions of "success" For Dojo to be successful, we must have measureable criteria upon which to base our definition of "success". This means that for short, medium, and long terms there must be some kind of meaning of "success" that we can quanitfy. For example, a short term measure of success might be "become the toolkit of choice for discerning professional DHTML hackers", while a medium-term definition might be "become the defacto DHTML toolkit for web application professionals and Open Source projects", while long term, we might shoot for "become baked into tools, and be the defacto DHTML UI toolkit for IT organizations worldwide". (DKS: hmm, should our success be described on adoption, or capabilities?) (RAR: adoption. Nothing matters more than adoption) - short term - Our current roadmap is to continue working on the plumbing and core components until we reach a point at which we can release something that people will find useful. (RAR: ummm...what exactly does this break down into?) - medium term - long term One of Dojo's guiding principles is to lower adoption costs of the framework. This statement informs many of the non-functional requirements of the framework. Put another way, the framework must give the developer a minimal number of reasons not to adopt it within the target market. For browser applications, the factors that influence adoption decisions include size of the javascript file to be downloaded, performance and capability of the widgets, platform support (breadth of supported browsers, versions, and operating systems), stability, and "hackability". If the framework does not provide an adequate experience to either end-users or developers, a barrier to adoption has been created. Other factors that can affect adoption decision cost ("adoption cost" or "barriers to adoption") are the quality and completeness of documentation, the availability of examples that illustrate common problems and usage scenarios, ease of obtaining support for the framework, ability to file and track bugs, and the extent of (actual or perceived) industry support. To ensure that Dojo provides a complete and acceptable framework for our target market, non-functional requirements for the framework at large and each major sub-component will be laid out in architecture or design documents. Testable metrics will be determined on a per-item basis (where possible), target values and minimum-acceptance values will be specified for each, and automated tests will be constructed to verify that each component meets our standards for developer and end-user acceptance. * releases * getting involved - Currently, contributors are added to the project through invitation only, `much like firefox`. If you would like to contribute to the Dojo project, please contact us. - Subversion - Java * milestones * project goals * current status - Dojo is currently in development. We have finished a significant portion of the core "plumbing" for the project, and we also have our first widget, a button, that can be constructed from markup in HTML and SVG namespaces. We still have a lot of work to do on making our widget system better, especially in the world of SVG. The current SVG button could be described as hacky at best. A button is a surprisingly complex widget, at least if it is done with any sort of sane flexibility and constraints. Other things we are actively working on include our event, IO, and data binding systems. .. FIXME: add a concise, one sentence explanation of what this buys us. Ongoing improvements and refinements are being made to our xml declaration language (specifically to support contraints and state) and parser. The parser currently supports the most necessary markup constructs, with space to later accomodate more elaborate declaration mechanisms. - infrastrstructure (complete) - compression - single-file builds from profile - bootstraps - package system - basic linker - basic unit testing - generic xml parser - IO (partial) - widget features (complete) - button (html/svg) - widget parsing infrastructure - base widget classes - event handling and mixins - easy html widget hacking - infrastrstructure (incomplete) - doc generation (discussing options w/ Erik Arvidsson) - single-file builds from arbitrary file - successful linking in build process - in-browser unit testing in addition to command line tests - JavaScript language extensions - dojoml - data binding - events ( tag, wrapper around dojo.event.connect) - property sets - app/ui "state" - repetition - server-side "hooks" - soap - same source security proxy workaround thinger - core api work -math - alg - collections - text - lang - mop/aop, functional programming support - widgets features (incomplete) - constraints - layout manager - movable borders - overflow - percentage layouts - relative positioning/containing - zoom - resize - panning - split pane - element resizer - combo box - auto-complete - sliders - data table - menus and drop downs - toolbar - toggle buttons - tab set - debugger/logger - tree - progress bar - status bar - context menu - status indicators - WYSIWIG editor or rich-text edit control - animation (RAR: need to engage Dan to get his code for this) - drawing - keyboard events - drag and drop - method for determing if you "accept" a drag or drop - mime types? component class names? introspection? generic hook? - internationalization? (RAR: good catch!) - form controls ? (i.e. date picker, etc.) (RAR: we should break these out, lots of work here) - combo box - static data set - dynamic data sets (server query for complete) - filters - hide/show (i.e. accordion in flex-speak) - html+ controls - text - grid - scrolling - sorting - tree - list - box - window - pop-ups - alerts - dialogs - configuration systems (wizards) - - combo box - whatwg widgets (no, really, at least partial support) - etc. - gratuitous 3-d transition effects ;) - cursor - tooltips - footnotes, may draw text from external URLs - data validation - form validation - focus - movement across windows/namespaces (IE drag a component from an html document to an svg document) - printing (RAR: is this mostly a style-sheet issue, you think? DKS: probably 80-90% is stylesheet, with the rest perhaps being a different mechanism for grabbing data, etc.) - performance optimizations (for example, pre-rendering of hidden widgets, or waiting until a widget is need to grab data, etc.) - style manager/abstraction between visual styles (RAR: hmm...how is that different than allowing differnet people to plug into a concerete implementation of a widget? DKS: I'm thinking general things for manipulating styles... we have some of this already for positioning/sizing, for example... not sure we need this) - generic data loader (i.e. Google AdSense, Amazon, sports scores, etc. ... basically a widget that makes it numingly easy to add a self-updating data source) (RAR: how is this not a feed+diff tied to mod-pubsub?... DKS: it is (or with xmlhttprequest, but it's the sort of thing that by providing it as a "widget" will likely increase initial uptake of the toolkit) - themes ? - viewport coordinate translation - app keyboard shortcuts/preferences manager? ################################################################################ might be useful: The Benefits of Webapps +++++++++++++++++++++++ Traditional desktop-deployed applications provide a host of benefits over web applications. From filesystem access to complete and dependable GUI toolkits, the desktop application is by all accounts the best way to provide a rich and immersive user experience. So why then does anyone bother with the web? And why should INFA? The answer lies, paradoxically, in the relative lack of features that the web environment provides to application authors and the design choices that this has forced. Instead of applications deployed to every desktop, web applications must be deployed to a single location which general-purpose clients must then navigate to to use. The upside of this? Lower deployment, maintainance, and development costs. Your application only need perform correctly in your server environment. Likewise, the web provides relatively poor user-interface components to build UIs with, and state keeping mechanisms are primitive at best. The upside? Web apps must by their very nature be more robust in the face of intermittent failure, constantly re-think the end-user experience (since it is simpler to modify it in HTML than in C++ and competition reacts faster), and application rendering is now entirely standardized around the feature set defined in W3C specs and deployed to millions of desktops world wide. But perhaps the biggest "win" for web applications is development agility. Web applications are traditionally authored in dynamic languages which C and C++ engineers view as "toy" languages such as PHP, Perl, and even Java. The productivity gains with both this new crop of languages, combined with the flexibility and inside-out benefits to businesses of using web applications makes Informatica's past and ongoing investment in web-deployed application technology prudent and increasing in importance as our competitors increasingly take advantage of the cost, time-to-market, and customer acceptance advantages of webapps. The Value Of Responsive UIs +++++++++++++++++++++++++++ One of the primary trade-offs that traditional web applications have made in respect to desktop applications has been a general decrease in UI responsiveness in return for universal deployability. As web applications have become ever-more commonplace, the value of a richer, more featureful user interface experience has gained in prominence as a differentiator among web applications. Users increasingly expect web browsers to do more of the tasks traditionally the purview of desktop appliations (email, chat, analytics) without tremendous sacrifices in the functionality or usability of the software. As we have proven with PowerAnalyzer, richer web application UIs can effectively compete with desktop applications, so long as the responsiveness, feature set, and "fit and feel" of the application are within reasonable distance of parity with the desktop-based competition. For some applications, the traditional request/response paradigm of traditional web applications simply won't work. Real-time data analysis or monitoring applications in particular make great targets for "webification" if only the UI and data latency problems can be solved. Problems Dojo Solves -------------------- - competitive advantage through desktop-like interactivity delivered in a true-web environment - low-latency communcation between web clients and servers - cross-browser, cross-renderer toolkit - markup-based UI declaraion for rich components - HTML and SVG co-existance and cooperation - clear, unambiguious, and friendly licensing terms for both INFA and INFA clients - extensible, themeable, complete widget set to provide consistent look and feel for INFA products Widget Instantiation From Markup -------------------------------- Dojo will receive "markup" in whatever output language is used by the server (usually HTML) in order to locate declarative instructions to create widgets, data bindings, and event handler attachments within the client. The machinery to make all of ths happens relies on an object-model for components to declare and describe themselves. Also necessary in Zeus is a template system by which the visible (HTML or SVG) representaiton of a widget can be easily "jump started" and filled in with data later. This template system will allow for quicker turn-around for initial development and subsequent changes to the UI of Dojo widgets. Functionally, all of these pieces work together to allow application authors on the server side to output rendering-agnostic code with which to construct dynamic UI elements. On the client-side, inline Dojo markup allows mixed-mode (Dojo + non-Dojo) applications to peacefully co-exist without sacrificing UI responsivenes for those portions of an app that are constructed with Dojo. XML-to-Widget Declaration +++++++++++++++++++++++++ Dojo provides an XML declaration language which is translated (via XSLT) to generate declarative markup which is parsed on the client side (by the two-pass parser). Class constructors for each widget are then called, components are rendered from templates, and then populated from data requested from the server. Communication Infrastructure (I/O Subsystem) ++++++++++++++++++++++++++++++++++++++++++++ Provides consistent interfaces to manage all of the various methods by which a responsive webapp can request partial or incremental data updates and notify the server of changes. This includes dealing with the vagaries of synchronous and asynchronous communication through the XMLHttp object (and it's propertary equivalents available in plug-in SVG environments), commmunication through managed queues built on top of hidden iframes, and data transport over a repubsub bus. Background submission of forms via GET or POST is also managed by the comm layer, as is notification of returned data from each submission. This function is essential to any responsive internet application, and entire toolkits have been built up around each one of these capabilities. Dojo will bring the best of all of these to the table, allowing application authors to choose the mechanism that best fits their needs and the capabilities of their environment. Two-Pass Parser ++++++++++++++++++++++++++++++++++++++++++++ A two-pass parser is a core part of Dojo. It supports the XML-to-Widget pipeline by creating JavaScript data structures from markup, handles the mechanics of calling widget constructors (and placing the resulting widgets into the UI), and implements the abstractions upon which data source binding and property sharing among widgets is predicated. Abstract Event Handling ++++++++++++++++++++++++++++++++++++++++++++ Dojo, as a UI toolkit, operates in environments which may or may not define their own low-level event notification mechanism from UI primitives. While these low-level handlers are useful, a well-architected system should allow various components of the system to be able to communicate via the same method as the user's communication with the system. To address this, Dojo will introduce a variant on the Aspect Oriented Programming (and Meta Object Protocol) concept of method "advice". This system does NOT require source code pre-processors, since the JavaScript language is dynamic enough to allow connection-time interception of subsequent function/method calls. A detailed discussion of this system (and the requirements document which arose from our research in this area) is available upon request. Interfaces ---------- The primary interface exposed by Dojo to the application author will be either in the form of custom or customized JSF components or DojoML markup. The markup language which Dojo uses to build components is specified elsewhere. Subsequent to the inital construction of a "page", Dojo will interact with server components via HTTP requests which send and receive messages/actions and data. Algorithms ---------- This document (a functional spec) is the wrong place to be discussing algorithmic design of a system such as Dojo. Regardless, major fuctional areas may require specialized patterns of usage, but it is not expected that any major design areas will require new or unique algorithms beyond what is commonly accepted in the areas of caching, sorting, event handling (call interception), and structured markup parsing. Internal -------- The most minimal amount of code necessaray to initialize Dojo are the `bootstrap1.js`, `hostenv_*.js`, and `bootstrap2.js` files. In a "compressed" build, these files may be provided for a single environment by a single file loaded into the target environment. Subsequent to this, Dojo loads components based on "include" directives. Dependency statisfaction for these includes is handled by the system, but no non-JS dependencies are required to declare an application. Subsequent interaction (via the I/O subsystem) is done over HTTP, and interfaces passed to the client are called by these requests. Any sever-side system that integrates with Dojo will be required to define these call points and expose the expected list of parameters. External -------- Dojo attempts to be a cross-platform and cross-server as possible. It is possible for an end user to receive the Dojo package and use it without external dependencies beyond an HTTP server and a modern web browser. More sophisticated users may choose to generate custom builds of Dojo to operate in command line or customized browser or vector-graphics environments. Browser environments that will be supported include all modern web browsers, and several SVG renderer implementations. Interaction ("plays well with others") ====================================== Dojo is designed and implemented in such a way as to "play nicely" with other DHTML/DSVG toolkits. The implementation strives to prevent global namespace polution to an extent not seen before in any DHTML toolkit. Dojo will also support "namespacing", which allows users to place the entire dojo class hierarchy at a location other than [[global]].dojo.*. On the server side, the integration plan with the various server-side technologies available is still under investigation by Martin and Sri, but it is not expected that are hurdles remain that would make Dojo incompatible with any chosen server-side framework. Page-based vs. no refresh applications -------------------------------------- The spectrum of rich client application varies from the traditional one page at a time, refresh the page for every action end, to the never refresh, always incrementally update the view given user and application actions and commands. The traditional page-based approach may be accomplished through a more declarative manner with significantly less JavaScript code, but suffers from a significant reduction in the responsiveness of the user interface. The richer interface applications require more JavaScript code for the application logic, but require only the initial construction of the interface components to be provided by the server. Look and Feel --------------------- The view of the application may be modified by changing the component templates, by making programmatic changes to the application style API, and through component specific properties. Layout is changed through modifying the document structure that is passed to Dojo upon initialization of the application. More extreme changes to the look and feel include changing the rendering context (html to svg for example), or alterting the collection of components and their behaviors in an application. Build System ------------- Most of the features in the build system, such as generation of documentation, compression, namespacing, modularization, etc. are optional. What is required is specification of the components that the application author is interested in including.