14 Feb
2006
14 Feb
'06
11:18 p.m.
1 - Does Magritte allow describing how objects relate
to each other in terms
of ownership? For example, an address might be "privately owned" by a
person, and a method is "privately owned" by a class. On the other hand, a
person might "refer" to a birth country, but does not own this country.
No, there is no such metaphor (yet). It probably comes closest to the
property #persistent with the two states #bePersistent and
#beEphemeral.
a - Subclass ElementDesc and add a Ownership
hierarchy.
b - Add some new property on RelationDesc to store type of ownership.
I would go for b, as I don't see a reason why to introduce a new
Ownership hierarchy.
2 - I notice that extra support has been added to
build GUIs and Seaside web
pages. Will this code be separated in they own packages, so that it is
possible to only load the "core" Magritte framework into an image? Then,
making new support code (for example building Pollock forms) should be
easier, as one can follow the pattern in your support code, and no
modification to the core Magritte is needed.
Yes, this is already the case. You can load Magritte-Core and you just
get the model. Loading Magritte-Seaside loads the Seaside support,
loading Magritte-Morphic loads the Morphic support, loading
Magritte-Tests loads the tests, etc. The repository with all packages
is available at: <http://mc.lukas-renggli.ch/magritte.html>.
3 - Do you have any plans for porting the framework to
VisualWorks?
Good luck with your work! It would be nice if you could make one single
framework that can be used for automatic GUI building, domain object
validation, relational persistency framework, web services, and other
systems requiring description of the domain.
I was asked about a VisualWorks version already several times. Some
time ago I adapted the exporter that Seaside is using to Magritte and
Pier. Moreover while writing the code I payed attention not to use
Squeak specific features, unfortunately there are a few problems that
are not that simple to solve (#initialize and streams).
With the help of the tests it should be possible to do a complete port
in one day, however I can't do it myself: Magritte and Pier are
basically a single-man project and I don't have the time to
concentrate on other things beside my master-thesis right now.
Contributors are of course welcome in all areas (porting, extending,
testing, documentation, ...)!
Thanks for your comments,
Lukas
On 2/14/06, Runar Jordahl <runar.jordahl(a)gmail.com> wrote:
>
>
> I read about Magritte at
> <http://www.lukas-renggli.ch/seaside/annecy/Magritte.pdf>
> and have a few questions, which I would be thankful if you could answer.
>
1 - Does Magritte allow describing how objects relate
to each other in terms
of ownership? For example, an address might be "privately owned" by a
person, and a method is "privately owned" by a class. On the other hand, a
person might "refer" to a birth country, but does not own this country.
>
> In order to make such a description, I can see two solutions:
>
a - Subclass ElementDesc and add a Ownership
hierarchy.
b - Add some new property on RelationDesc to store type of ownership.
>
> I ask, as describing such relationship between objects can be helpful when
> copying them (where to stop copying), deciding where a version field should
> be located (at the top object), and when deleting from a relational database
> (delete recursively all "privately owned" objects).
>
> I remember TopLink had such a property in its descriptor.
>
2 - I notice that extra support has been added to
build GUIs and Seaside web
pages. Will this code be separated in they own packages, so that it is
possible to only load the "core" Magritte framework into an image? Then,
making new support code (for example building Pollock forms) should be
easier, as one can follow the pattern in your support code, and no
modification to the core Magritte is needed.
>
3 - Do you have any plans for porting the framework to
VisualWorks?
Good luck with your work! It would be nice if you could make one single
framework that can be used for automatic GUI building, domain object
validation, relational persistency framework, web services, and other
systems requiring description of the domain.
>
> Kind regards
> Runar Jordahl
--
Lukas Renggli
http://www.lukas-renggli.ch