[ TaskService Test | Namespace Test | Message Test | Feature Test | whitefrost.com | Stephen W. Cote ]
The M3 project is now defunct, and has been replaced with Engine.
The origins of this project were as a script-based widget toolkit I referred to as the MDI Project (refer example #1 and example #2). In deciding on names, my first conclusion was to drop the "mdi" moniker as it is no longer describes many of the project features. I also elected not to describe it as any sort of widget toolkit, or an "mdi" or "gui" toolkit. There are myriad things I don't want to call it so as not to be confusing, but an apt name escapse me.
At the moment, I am refering to the project as m3 - it is the third major revision on the "mdi" code since its inception in 1998.
The objectives of the m3 project are to:
Improvements from the original mdi code base are:
08/27/2002 - Updated content to reflect recent changes.
08/16/2002 - Document created.
08/27/2002 - Updated core feature prototype to compensate for changes in the code base. Added new test for TaskService.
08/12/2002 - First public prototype of core features, application driver, and demo UI widgets container, menu, and result set.
08/02/2002 - First prototype of core features in object_structure_test.
08/28/2002 - Re-purposed the driver and added a new TaskService. The TaskService is a more robust version of the bootstrap feature employed by ApplicationDriver. TaskService came about while working on a web services module, and the need to load XML synchronously or asynchronously, and not implementing a custom stack and callback mechanism to keep track of the various objects. A stack hasn't been added yet, but it would be very easy to do given this new design.
Added support for synchronous transactions in the xml utility.
Added a new general purpose configuratin utility. A config instance will load XML, hash it, and throw away the object. Once the web services component is in place, or I re-implement my dumbed-down TransactionService, then a save-to-server feature could be added.
08/23/2002 - Updates to the driver and the xml utility I was very pleased with how well the bootstrap utility worked out while piecing together an early webservices utility. It was nice to be able to load the WSDL file, create a bootstrap for files that needed to be imported, and then specify a handler for when those imports were finished. The XML utility required several updates to make use of XMLHttp requests for posting back to the server.
Once I switched over to using the XMLHttp objects and made the XML requests asynchronous for IE, I uncovered a rather nasty little bug related to the delay in the message service. I could not pinpoint the exact location where the problem arose, but resolved it by preventing bootstraps from firing their completed handlers twice. The problem manifested itself as the developer-specified bootstrap_loader was executed twice, and ultimately, the application_initialized event was fired twice. It was pretty ugly.
08/18/2002 - I threw out the LoggerFactory and EventFactory classes and replaced them with a MessageService class. While one may argue that the separation of a logging facility and event facility made sense, I came to the conclusion that it was more aptly implemented as a message service. The resulting class unified the logging and event classes and switched the API around a bit. So, rather than "log", one now uses "sendMessage". Instead of "addEventListener" and "fireEvent" (note name collisions w/ DOM members), one uses "subscribe" and "publish".
This change made a lot more sense and is easier to implement.
08/17/2002 - Updated bootstrap code in ApplicationDriver to be more fluid and less reliant on a hard coded "_bootstrap_driver". Now, the developer specifies the name of the loader, and the config path and type, when the instance is created. The handler for the loader executes a procedure from the config file to launch the bootstrap named "_bootstrap_driver", but at this point the name could be anything.
Added some clarity to the definition of a bootstrap in the configuration. Now, a bootstrap has an id, a primary action, and a handler. Child elements are its dependencies. It should be noted that at this point, a dependecy affects the handler, not the primary action.
Two remaining issues.
08/16/2002 - Add support to resultset for auto-selecting and auto-scrolling to new items. Also added support for maximum entries and auto-rollover (clear the first item) when the maximum limit is reached. These features were added during a debug session to make the widget more useful for other development tasks. Also make use of Array.splice instead of custom code (Array.prototype.pull) in resultset.
Add debug-level output to bootstrap test page.
08/15/2002 - Many enhancements made to how an instance of an object "inherits" and "implements" from base prototypes. A UI widget can now be derived from a configuration-based dataset, and then implement a required base class. An example model is a result set is a new instance of a ui.object. The ui.object is a new instance of an object which is defined by the xml configuration file, and implements a base_object which is hard wired. creates a new instance
Updated EventFactory to support delayed response, and updated the resultset widget to support auto-commit when buffering is enabled. The last two changes make the bootstrap prototype pretty smooth in both IE and Mozilla, even when simulating an event queue flood. A flood was created by driving 200 LoggerFactory.log calls to a resultset via the "onlog" event).
ApplicationDriver was updated to fix several bugs resulting from the enablement of a delay in EventFactory.