Matchbox RC2

[eluser]esra[/eluser]
[quote author="Zacharias Knudsen" date="1196721106"]esra: Neat, is this part of the CI/EXTJS-application you've been working on for a long time now?[/quote]

Yes and no. I started to work on this last March and have made some major changes in approaches since starting. CodeIgniter has not changed much since then, but EXT JS has undergone extensive changes and significant performance gains.

I started off using the CI 1.5.x MVC architecture but ran into numerous problems getting the client-side code to harmoniously communicate with the server-side code and vice versa. That is, EXT JS takes over the Presentation aspects of the MVC triad (with the exception of calling the views) and wants complete control over view presentation. Thus the view is more like a viewport peering into the EXT JS presentation. I did some research and discovered the ARCH model used in the PAC-Amodeus framework. This led to some experimentation with using the PAC (Presentation-Abstraction-Control) architectural pattern in a PHP5 Strict version of CI last March. In this scheme, EXT JS and a set of PHP wrappers based on the View library became the Presentation Toolkit component of the ARCH model which separates the View from the actual presentation of the View using a GUI-like toolkit. Rather than creating views using EXT JS code directly, I'm loading views extended from GridView, TreeView, AccordianView, PortalView, EditView, FormView, etc. EXT JS properties are handled using ini files.

I also needed a solution for allowing modules (now, applications for all practical purposes with Matchbox) to perform synchronization actions based on events, a mediator, or chain of responsibility. I'm trying to get a bunch of ideas all working in what will eventually be a themable EXT JS 2.x Desktop container environment simultaneously supporting the MVC, HMVC and PAC architectural models. I needed more abstraction for controllers, models, and views (in the least case), since the design patterns used for controllers, models and views are different for each architectural pattern. This resulted in using interfaces or abstract classes to create concrete controller, model and view implementations. I added a lot more abstraction to the framework than necessary, in some cases for future needs (e.g, Config is an interface supporting XML, YAML, INI, and Array configuration classes; multiple DBAL support, multiple View renderers, etc.). Because the custom version of CodeIgniter supports multiple cores (i.e., one set of core files for PAC, MVC, and HMVC) with files of similar names, I added namespaces support to the framework. With the use of interfaces for abstraction and the ability to implement a class based on multiple interfaces, it is also possible to support other presentation libraries other than EXT JS (e.g., PRADO). Basically, this project has undergone many changes of plan to workaround obstacles met along the way.

The basic principles of Matchbox and the View library are integrated into the core but are implemented differently because of PHP5.

Basically, what started out as a moderately long project and turned into someting much more complicated. I look at it as more of a challenge than anything else and as a platform for developing future applications. I consider this code to be highly experimental and open to more changes in the future. This project also gave me an opportunity to use design patterns more effectively, unit testing and to design the project using UML. A considerable amount of documentation has been created along the way for these reasons.

I plan to work out the kinks and refactor the code using more design patterns until Rick releases a PHP5 version of CodeIgniter. Then, it might be possible to release what I have as a set of extensions. I'm not too keen on forks for personal reasons. Over the long-term, the solution is going to be used in a complex application I have planned for the future. I'm in no rush to get this done.