Peter Yee has been working hard on integrating the Dojo build system
with our own so we can build profiles that we can build different
profiles for different types of applications.
In addition I have been thinking more about minimal builds. For example
if someone wants to use macros rarely or not at all can they simply
leave those out of the build?
Currently the answer is no because the ClientSession object requires the
NamespaceHandlerManager, which in turns requires handlers for each
namespace like mco, macro, etc.
My proposal is that have a core set of functionality then any particular
namespaces we handle are injected rather than included by default. I was
playing with the XapConfig.xml file and changed it to look like this:
<plugins>
<plugin-file file="src/xap/taghandling/plugin.xml"/>
<!-- assume require on this name will work -->
<plugin-class class="xap.mco.McoNamespaceHandler"/>
<plugin-class
class="xap.xml.xmodify.XmodifyNamespaceHandler"/>
<plugin-class class="xap.macro.MacroNamespaceHandler"/>
<plugin-class class="xap.xml.XalNamespaceHandler"/>
</plugins>
Basically what this says is load the file
"src/xap/taghandling/plugin.xml" and instantiate the 4 classes. These 4
classes when loaded configure themselves to be part of the overall
framework.
If you didn't want to use macros at all, you could simply leave out the
entry for MacroNamespaceHandler and leave it out of your Dojo-style
profile.
This is also nice in that if we or end users want to add their own
namespace handlers later they can do so. In fact they can add any old
classes that will get instantiated and passed a session to.
This last point is key. If the user simply wants to include their own
files they can without using this mechanism, but these classes can
follow the contract that allows us to inject a session into them so they
can do things like add themselves to the list of namespace handlers. We
want a lot of functionality scoped to the current session rather than
the current window object so simply having files perform some operation
when they are loaded is not sufficient - they need some indication of
the current session.
These objects could also dynamically add methods to the session object.
For example instead of a getMcoContainer() on session we could
dynamically add that method if MCO support is included. The downside
there is that it makes documentation a bit messier.
Proposal in short:
1: XapConfig.xml allows you to specify tag-handling file (which was
previously hardcoded for the time being)
2: XapConfig.xml also allows you to specify classes that will be
instantiated and then called with the current session.
3: Using this mechanism you can add your own handlers for new namespaces
and provide a variety of other functions as well. Each of these classes
is the root for a plugin that exposes some new functionality.
4: Along with this you can build you own Dojo-style profiles to include
in the large concatenated file whichever of these files you wish.
5: This will allow us to package a core set of functionality and let
user pick, choose and add their own functionality on top of that.
6: This defines a standard way to extend the base functionality with new
tags, functions, etc.
I have this working on my machine and it works well. I like the general
approach of having a core with plugins, it is similar to the way Eclipse
works as one example.
James Margaris
