Objectives:
- App Builder runs on the latest version of Dojo
- Apps can be developed on any (supported) level of Dojo
The separation of AB/app is achieved with an IFrame for the edit pane.
<mnog>
This is not so simple...Currently, Page Editor's (App Builder's) Dojo is used to parse and create widgets in the iframe. Page Editor should:
- Load another Dojo instance of the target level into the iframe.
- Somehow hook parsing events in the iframe for callback functions in Page Editor (for some tracking purposes).
- Switch Dojo "global" to the target level when widgets are created (insertion and modification) in the iframe.
</mnog>
Metadata associated with Dojo
- Palette metadata : describes the palette in terms of sections/members
- Widget metadata : for property sheets
- ...
The metadata will be versioned with Dojo. The most natural way to manage this is to have the metadata associated with the application, under a folder set by convention. That provides App Builder (and other tools) with a standard means of accessing the metadata associated with that particular application, and also enables folks to augment the metadata via modules and the sMash virtual file system.
<mnog>
Does this mean each application has a set of metadata files? I don't think it would be efficient way. I'd propose metadata be provided from modules with namespacing (stored in separate folders) by versions. Page Editor should:
- Manage metadata providers per Dojo version (with version aware base URL).
</mnog>
Managing the migration to Dojo 1.2
There's a lot of work ahead, including:
- Port App Builder to Dojo 1.2
- Add to page editor support for multiple Dojo versions
Note: We cannot check Dojo 1.2 into svn until we have OSSC approval.
Plan:
- Branch trunk/DEVTOOLS (silverstone)
- Bug fixes for App Builder (trunk) would also have to be committed to the branch (branches/b_bug6006)
- Enhancements would be developed in the branch to avoid dual maintenance
- At the end, we'll remove trunk/DEVTOOLS then move the branch to trunk/DEVTOOLS; that way we'll have the full history of the Dojo 1.2 rework along with the history prior to the branch
Would be nice to be able to run continuous builds on the branch; that would make it easier for others to try it out (we'd have to describe how they first package Dojo 1.2 for themselves).
Questions
- How to manage two versions of Dojo as sMash modules? Today, module names in svn match the folder name; we can't have two "dojo" folders. Seems best to use distinct names: dojo for 1.1 (legacy); dojo-1.2 for 1.2.