Proposal by Mirko Kiefer for GLORP & Magritte integration/refactoring

Proposed by Mirko Kiefer (profile, biography) Don't forget to submit this proposal to official Google Melange site too!


Background

GLORP and Magritte are both frameworks that make heavy use of meta-descriptions in Smalltalk models. GLORP uses these to map model-objects to a relational database - Magritte is mostly used for dynamic generation of user interface components in web applications but could in fact be used in a much broader range of scenarios.
Both frameworks manage accessing model-object's properties, mapping them to their representation, transactions, validation, caching and more. As the process of writing meta-descriptions is similar in both frameworks it would be very beneficial to combine common metamodelling parts, relieving developers to do the same work twice. A refactored codeset of both frameworks would also avoid double-efforts when advancing the frameworks themselve.
This project is a chance to increase adoption of both frameworks overall.  It will decrease the complexity and entry level and make developing web applications using GLORP, Magritte and Seaside an even more productive task both on the user interface and on the persistence side.

How will I do that project

The project would consist of two large parts - firstly the comparison and analysis of both frameworks and secondly, based on these results, the actual refactoring.
The analysis will start by detecting common aspects in both frameworks. The implementation of these aspects will be compared and assessed to identify the "best parts" and potential limitations.
The two implementations will then be compiled to a more generic one and refactored to become independent of each framework. As described in the project details page (http://gsoc2010.esug.org/projects/glorp-magritte) the refactoring should split the codebase into three level of abstractions: "common metamodeling", "generic ORM" and "GLORP-related".
In the end you would have a much more generic codeset and the analysis that lead to the refactoring. The analysis part will be very important when presenting the results to the community to make the decisions transparent.

What methodologies will I use

As this project will include major refactoring, good test suites are an absolute must to avoid breaking things when experimenting. Luckily both frameworks are well covered with tests. This makes it easy to continue using XP development methodology and ensure the final codeset is still functioning.

Suggested timeline and milestones

  • Week 1: detecting common aspects of both frameworks
  • Weeks 2-3: comparing implementation, choosing/compiling "best" parts and identifying limitations. Documenting analysis results for potential reviewing by the community
  • Weeks 4-10: refactoring the codeset and splitting it into three levels of abstraction as described earlier
  • Week 11: cleaning up code and ensuring full test suite covert
  • Week 12: documenting codeset and reasons for refactoring
  • Ongoing afterwards: provide guidelines and tutorials for integrating into existing applications. Present results and tutorials for developers to get started on community websites/new website

Where I see the risks

As the major risk I see that the community might not adopt the result of the project. As outlined earlier it is therefore crucial to make the reasons for the refactoring as transparent as possible.
This is still not sufficient though - to ensure the project will be successful it is necessary to provide guidelines for advancing existing applications so that they can make use of the refactored generic GLORP/Magritte codesets.

There is also a risk that due to the complexity especially of GLORP, I might not be able to finish the refactoring process within the project's official timespan. If thats the case I will certainly continue the work as I have a  personal interest in getting this working.

How the results will look like

The result of the project will consist of two parts: the refactored codeset of GLORP and Magritte with the three abstraction levels and the result of the analysis and comparison that led to the refactoring.

 

 




Updated: 9.4.2010