SetupWebPage is an alias for ModuleDiscovery and the module files should be updated progressively to invoke ModuleDiscovery::AddModule() instead.
The implementation of the module still assumes they are in the directory 'modules'... this has to be changed later to ensure the distinction between the source modules and the executed modules
SVN:trunk[1758]
- When adding modules: the data model was not refreshed in the cache before attempting to load "structure" (or "sample") data
- When removing a module: remaining (invalid) triggers were still used.
SVN:trunk[1401]
- includes are relative to the application root folder, aka APPROOT
- changed the config file, while preserving the compatibility with older installs
SVN:trunk[962]
Trac #93 - Fixed issue within the setup data load (related to memory_limit)
Fixed issues with the consultant toolkit: upgrade an existing DB (add new class/attribute)
Developed core services to allow for demonstrating impact computation capability
Deprecated option operation=direct on page UI.php
SVN:trunk[313]
- stopper bug in case of reinstallation/upgrade: the file keyscache.tmp could be left in case of issue in the previous execution of the setup ; the file is now deleted prior to running a new session
- if a fatal error (e.g. call to undefined function) occured during the load of a file (ajax), then we had no clue that this happened ; a log has been added after the load so that we can get faster to the issue
- reordered data files (not the same order in MS-Explorer) to maximize ext key resolution on the first pass
- resolving external keys afterwards should work again (though the file order is avoiding this currently), as the objects are declared "dirty" and no automatic reload will be attempted during further manipulations
- added a log when an external key cannot be resolved during the final round
SVN:trunk[191]
