Proposal:Foundry
From MovableType
Contents |
Foundry
Foundry is the next generation framework written in Perl for building MT and MT-style applications.
This rewrite of the core framework will endeavor to leverage as much existing and established open source Perl code (via the CPAN repository) and modularize parts in the MTOS code base where such a library does not already exist.
It's been effectively refactored heavily over time to adapt to the changing roles and environment; however as previous closed source application it has not taken full advantage of the broader open source Perl communities contributions. In other cases MT implemented a solution that did not exist in CPAN, but over time the Perl community has developed a via alternative or replacement to the home-grown (better word) code in MT.
Stopping further MT or MTOS releases to perform a complete rewrite of the code base is not practical or feasible. Foundry will be developed in parallel to ongoing MT releases attempting to keep efforts relatively synchronized and feed back any compatibility issues to the MT application development efforts so a grace deprecation process can be worked out and communicated well in advance of any breaks.
Is it the aspiration of the Foundry effort to be used by the the MTOS trunk for "Movable Type 5" though this is not an official goal or milestone.
There are number of reasons for why the time is right for Foundry:
- The transition from a close license commercial product to an open source project with commercial addons necessitates a diffferent mindset to how code should be architected and developed that is not currently present in the current base.
- As a somewhat new open source citizen, MTOS can provide contributions to the Perl (CPAN) community that are independent of MTOS in addition to acknowledging and supporting other Perl open source communities who are developing and maintaining functionality that can be used as a replacement existing part of the MTOS code base.
- Lower the barrier of entry more engineers and developers to contribute to MTOS projects through the use of well-known tools that are well documented and they are already familiar with.
- Clean out the cruft. The MT code based has seen a long and extensive evolution as its been adapted to the changing landscape and growing user based over the years. Through this dramatic change MT has been resilient and relatively maintained, however; it could be better structured so future development and maintenance is easier and more efficient.
- Modularize MTOS development by separating the framework (and eventually subprojects through other efforts) development from the primary application development. Besides making it easier to contribute back finite pieces of functionality that is independent to the primary MTOS application to CPAN, modularizing should allow for more parallel development to take place this is easier to test and maintain.
In summary, Foundry is an opportunity to take the 6+ years of field experience and experience that the current MTOS code base and community embodies to contribute to the greater Perl community and develop a more stream-lined and efficient means of moving MTOS going forward.
Goals
- Develop a web application framework for creating MT or MT-style systems.
- Integrate MTOS efforts with the broader Perl and open source community, namely CPAN. This means includes refactoring and modularizing existing functionality in to indepedent CPAN distributions and replacing code whose functionlity exists in CPAN.
- Foundry can be submitted and hosted in the CPAN repository.
What defines the Foundry framework?
Developing Foundry means examining the broad functionality of MTOS and MT Pro and commercial addons and then extracting the most basic and core parts from the code base for building a MT-style application, but not actually being an application.
Like many applications, Foundry would provide all the parts for a model-view-controller (MVC) design pattern for application development that MT has always used. These layers are defined as:
- Model: Data persistence
- View: Interface content and publishing
- Controller: Application logic and flow
In addition, to these primary architectural layers, the engine would need to provide a means of initialization, startup and configuration of of an application.
What Foundry is not is MT or any other working application. It is a framework and an engine for building MT or MT-style applications. It does not have any user interface elements itself, however; it how the means to implement them.
Perl 5.8.1 would be the minimum supported version.
Required Module Mapping
Layer MT Class CPAN
--------------------------------------------------------
Controller MT -
Controller MT::Bootstrap -
Controller MT::Dispatch CGI::Application::Dispatch
Controller MT::App CGI::Application
CGI::Application::Plugin::Apache
CGI::Application::Plugin::Forward
CGI::Application::Plugin::Redirect
Controller MT::Callback Class::Callback[2] (Role based?)
Controller MT::CallbackMgr Class::CallbackMgr[2]
View MT::Builder Typist
View MT::Context Typist
View MT::Template Typist
View MT::Publisher[1] Typist
Model MT::Request
View MT::FileMgr File::Manager[2]
File::Manager::Local etc.
Model MT::Object Data::ObjectDriver
Model MT::ObjectDriver Data::ObjectDriver
Model MT::Roles Perl6::Roles
Config MT::ConfigMgr YAML::Config::Tiny[2]
Config MT::Registry YAML::Registry[2]
Plugin MT::Component YAML::Registry[2]
Plugin MT::PluginMgr[3]
Plugin MT::Plugin[3]
Plugin MT::PluginSettings[3]
Utility MT::Util break out 'dirify' as URI::Dirify or Text::Dirify [2]
- Formally MT::WeblogPublisher
- Needs to be developed and submitted to CPAN
- Use Module::Pluggable as the underlying code?
Other Required Modules
- CGI (5.81 core)
- CGI::Cookie (5.81 core)
- File::Spec (5.81 core)
- File::Basename (5.81 core)
- URI
- YAML::Tiny
- Data::ObjectDriver
- Class::Trigger
- Class::Accessor
- DBI + one driver:
- DBD::mysql
- DBD::SQLite
- DBD::Pg
- DBD::SQLite2
NOTE: This is not a full dependency list of modules required by CPAN modules.
Optional Modules
NOTE: By raising the minimal level of Perl to 5.8.1 all these modules listed in mt-check are included in the core distribution.
- Scalar::Util (5.81 core)
- List::Util (5.81 core)
- Storable (5.81 core)
- File::Temp (5.81 core)
- File::Path (5.81 core)
- Fcntl (5.81 core)
Under Consideration for Inclusion
- LWP
- XML::SAX
- MT::Storable and Storable (5.81 core)
- MT::Promise (or CPAN version -- as Role or mixin?)
- CGI::Application::Plugin::LogDispatch and Log::Dispatch
- CGI::Application::Plugin::ErrorPage
- CGI::Application::Plugin::ValidateRM (+YAML profile support)
- CGI::Application::Plugin::Stream
- CGI::Application::Plugin::CompressGzip
- CGI::Application::Plugin::DebugScreen[4]
- CGI::Application::Plugin::DevPopup[4]
- CGI::Application::Plugin::DevPopup::Log[4]
- CGI::Application::Plugin::ViewCode[4]
[4] Part of separate developer pack addons pack? WWW::Mechanize?
(Potentially) Unaddressed Functionality
- Localiztion
- Better testing suite? Seperate developer's addon?
- Better logging facilities? MT::Log? LogDispatch?
- Better error handling? Message stack?
- Validation services?
- Developer tools such as starter (Think Ruby scaffolding.)
Best Practices
- Use only simple YAML files for configuration and registry of core system components, addons and plugins. Embedded data structures and code references should not be used.
- All uses of XML should use XML::SAX. Use of XML::Simple is highly recommended. Is this is a Foundry best practice or one for MTOS and apps?
- Use URI package for all URL generation.
- Always provide a pure perl fallback to compiled speedier options such as XML::SAX. Conversely compiled libraries should not be required.
- Clean RESTful URLs with POST tunneling. See CGI::Application::Dispatch.