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

Magritte is not ONLY for web development descriptions, but for any description. That's why we are even considerating it for describing the mappings.
Although it is obvious that for the web is fits very well and it is widely used for that purpose.
š

š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,

The other thing I would like to change is that not NECESSARY you need seaside. I say this because maybe the student or the mentor want to use Aida or whatever other thing. I think it should concentrate in the interaction between Magritte and Glorp, but too much in the "user" of Magritte (seaside or whatever).
I am not sure about this.š Just a though.

What do you think ?

Cheers

Mariano

š

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 ŕŇÉĘ íÉŇĎÎĹÎËĎ <tallman@inbox.ru <mailto:tallman@inbox.ru>>

š š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
š šEsug-list@lists.esug.org <mailto:Esug-list@lists.esug.org>

š š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
Esug-list@lists.esug.org
http://lists.esug.org/listinfo/esug-list
š

_______________________________________________
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/listinfo/esug-list