10 Mar
2010
10 Mar
'10
2:02 p.m.
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(a)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(a)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(a)lists.esug.org
http://lists.esug.org/listinfo/esug-list
_______________________________________________
Esug-list mailing list
Esug-list(a)lists.esug.org
http://lists.esug.org/listinfo/esug-list