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

GLORP & Magritte both uses a lot of similar techniques. It's not descriptors only. Accessors and Conditions are other examples. So, why not clean up everything metamodel-related from GLORP, and utilise Magritte functionality instead?

I thing it gives boost to both projects: Magritte will be forced to evolve and include techniques like collection tracking. GLORP, first of all, will lost part of it's complexity. And, secondly, it will be possible to use, say, Chain or Pluggable accessors.

And there are several sinergy effects expected. First of all, we avoid double-working when you try to use Magritte and GLORP in one project. Yes, there are some package fir this, but it built "on top" of both systems, and provide only very simple and straitforward possibilities. Next, it becomes easier to implement "list all objects links to this very object", which is definetly in a lot of relation-databases-based applications.

Finaly, as far as Magritte is often used (for generating forms, for example), it will be funny "just add few code and force my code to work with Postgresql". Really, I think, lot of people described different pieces of proposed system in their own projects. I personally did.

_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/listinfo/esug-list

====
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.

 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 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 Seaside applications:  the student who does this project will have skills that can be turned to practical account in web development.

        Yours faithfully
              Niall Ross

Mariano Martinez Peck wrote:

I am one of the developers of SqueakDBX and GlorpDBX so...of course, I really like the idea. Having to create the GLORP mappings in a separate class and then create also the Magritte description  (for other purpose, like web description) is not cool. Maybe managing all the metadata (for different purpose lile web, validations, RDB mappings, etc) with the same tool would be cool.

What others think ?

So, yes, I like it. Can you send me the proposal ? something like what it is in http://gsoc2010.esug.org/ideas.html

Someone wants to be the mentor ?
Cheers

Mariano

2010/3/10 Юрий Мироненко <[hidden email] <mailto:[hidden email]>>

   GLORP & Magritte both uses a lot of similar techniques. It's not
   descriptors only. Accessors and Conditions are other examples. So,
   why not clean up everything metamodel-related from GLORP, and
   utilise Magritte functionality instead?

   I thing it gives boost to both projects: Magritte will be forced
   to evolve and include techniques like collection tracking. GLORP,
   first of all, will lost part of it's complexity. And, secondly, it
   will be possible to use, say, Chain or Pluggable accessors.

   And there are several sinergy effects expected. First of all, we
   avoid double-working when you try to use Magritte and GLORP in one
   project. Yes, there are some package fir this, but it built "on
   top" of both systems, and provide only very simple and
   straitforward possibilities. Next, it becomes easier to implement
   "list all objects links to this very object", which is definetly
   in a lot of relation-databases-based applications.

   Finaly, as far as Magritte is often used (for generating forms,
   for example), it will be funny "just add few code and force my
   code to work with Postgresql". Really, I think, lot of people
   described different pieces of proposed system in their own
   projects. I personally did.

   _______________________________________________
   Esug-list mailing list

   [hidden email] <mailto:[hidden email]>

   http://lists.esug.org/listinfo/esug-list

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

------------------------------------------------------------------------

_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/listinfo/esug-list
 

_______________________________________________
Esug-list mailing list
[hidden email]
http://lists.esug.org/listinfo/esug-list

> 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
[hidden email]
http://lists.esug.org/listinfo/esug-list