[Esug-list] GSoC idea: GLORP & Magritte integration
Mariano Martinez Peck
marianopeck at gmail.com
Wed Mar 10 14:02:17 MET 2010
Hi Niall. Thank you very much!! It is really interesting.
There are two things I would change, if you are agree of course. See below.
====
> 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 at inbox.ru <mailto:tallman at 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 at lists.esug.org <mailto:Esug-list at 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 at lists.esug.org
>> http://lists.esug.org/listinfo/esug-list
>>
>>
>
> _______________________________________________
> Esug-list mailing list
> Esug-list at lists.esug.org
> http://lists.esug.org/listinfo/esug-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100310/ebe5d0ce/attachment.html>
More information about the smallwiki
mailing list