Re: Re[2]: [Esug-list] GSoC idea: GLORP & Magritte integration - smallwiki

11 Mar 2010

Ok....It is important what Alan said. However, from my point of view it is
worth to see what there is in common and in case that it is not too much,
how can we extend or modify Magritte to be that way. The student should also
look at keith's Magritte-RDB when we acutally did something similar to this
but without Glorp.

Юрий Мироненко  do you want to change something to Niall proposal ?   In
true, please do it as soon as possible and send me the updated version.

For the moment at the end you will find the version with my little changed
with what I said in my previous mail.

Now....we need a mentor. Diogenes Moreira offers to be the co-mentor. He
knows a lot of Glorp (he is actually developing with us SqueakDBX/GlorpDBX)
and Magritte. His main problem is that his English is not the best one ;)
So...we still need a mentor.

Volunteers ?

Refactoring model mapping commonalities from Glorp and Magritte
--------------------------------------------------------------------
Mentor: TBD   Second mentor: TBD

Level
====
Glorp and Magritte both map between model-layer objects and other domains;
 in Glorp's case, the relational database, in Magritte's case, the web.  The
truth is that Magritte is a meta-description framework for all kind of
description. However, it is mostly used for web applications.

There are many similarities in how each framework maps model-layer class
aspects/instVars/etc. to RDB tables and fields, and to web entities.
 Developers of Seaside or AidaWeb apps using RDBs, in particular, sometimes
feel they are repeating themselves when they code first the Glorp mappings
and then the Magritte mappings, or vice versa.

The goal of this project is to analyze by experiment how far common aspects
can be extracted to a single core:

  - Are any limitations of one framework revealed by comparison with the
other?

  - Can the API be refactored so that the same concept uses the same method
call in both frameworks?

  - Can a single set of descriptor classes, extended by each framework, be a
common core to both?  Can a single set of meta-model walking functions be
used by both?

  - Can a single set of descriptor objects be used by both?

The output is both a refactored codeset exploiting the commonality that can
sensibly be achieved and an analysis of why more commonality cannot, or
cannot easily, be achieved

Technical Details
===========
Glorp and Magritte have good test suites.  XP development to ensure existing
facilities remain functional will protect the student from breaking some
facilities as they experiment with refactorings.  Maintaining deprecated
methods that call new API in terms of old API may be appropriate in the
project, and may also assist introduction of the results to the community.

Benefits to the Student
===============
Glorp and Magritte are two meta-modelling/mapping frameworks with impressive
capabilities solving real problems:  the student who does this project will
acquire significant practical knowledge of this kind of meta-modelling.
 Glorp and Magritte are also important parts of one way of writing web
applications:  the student who does this project will have skills that can
be turned to practical account in web development.

2010/3/10 Юрий Мироненко &lt;tallman(a)inbox.ru&gt;

...
   Magritte is
not ONLY for web development descriptions, but for any
 description. 
 Unfortunately, it's very common to use Magritte only as a tool for
 generating web-forms. Most if not all Magritte examples are about it. Tool
 like Magritte looks very powerful...potentially :) And it's not only about
 descriptors. Memento functionality is described in pretty easy-to-understand
 way, for example. Conditions structure and validation is very funny, too. I
 personally used two described above.

 Firstly, I used magritte-based memento to fight GLORP limitations. GLORP
 has no nested UnitOfWorks, and you really need something in realworld
 application that will handle "save" button :). So, on "save" button
pressing
 I begin UnitOfWork, commit memento and then commit UnitOfWork. It works very
 funny...but I was forced to implement my own memento class for it. There are
 two problems with Magritte mementos, and both leading to idea of
 GLORP-Magritte integration:

 a) Magritte's default memento try to manage parallel edits to the model
 (and well, GLORP needs something like this, isn't it?). It makes two
 "copies" of object, one for manipulating, and other for comparing to
"real
 object" on commit. It gives possibility to track modification to "real
 object". made in period from making memento to commiting it. Well, it
 conflicts with GLORP proxies. Instantiating of a proxy forces Magritte think
 there are edit conflict...well, you can manage it by using not-default
 memento (Caching instead of Checking).

 b) Magritte's mementos can't manage model's behavior. For example, if I
 have simple object with two editable fields #price and #amount and one
 read-only field #total, it will be impossible to use Magritte's mementos to
 edit such an object. Supposing you want to observ #total during edit, i.e.
 before commit will happen. To manage this, I made a new Memento class. It
 makes a new instance of model's class for caching, and then uses every
 not-read-only Accessor to copy values from model to this class (well, it was
 little bit harder, but not much). And you see, it's very, very similar to
 GLORP caching technique.

 You can overlook this on http://squeaksource.com/SmallPOS.html

 Secondly, I trying to use (working on it just now) Magritte conditions not
 for just making data entry validations, but for implementing fast search and
 to build where-clauses for GLORP. And well, trying to do it I feel myself
 like...hmmm...translating from one language to another with similar semantic
 but different words :)

 I was forced to expand Magritte descriptor's system with "this accessor
 should return this value". And GLORP already has it.

 Next, GLORP's blocks parsing technique looks very promising for Magritte.
 Magritte has "plugable" condition, but it's out of Magriite concept
really.
 Parsing of blocks may help a lot, combining "easy to write and read"
 advantage of blocks and "it's possible to serialise/manage
programmatically"
 advantage of explicit using of special classes. GLORP uses block parsing for
 very same reasons, I believe.

 _______________________________________________
 Esug-list mailing list
 Esug-list(a)lists.esug.org
 http://lists.esug.org/listinfo/esug-list