Smalltalk › Frameworks & Tools › Magritte, Pier and Related Tools

Re: Magritte

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Lukas Renggli

Re: Magritte

> 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 <[hidden email]> 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

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

Lukas Renggli

Re: Magritte

> Thinking more about this, I would actually go for a :-) It would be nice if
> other developers could use your framework to make *any* description they
> like, without needing to modify the core framework. Below I outline how it
> could be done:
>
> [snip]

Ok, I understand. a might be a good approach indeed, if you actually
want to modify existing behavior/visitors. By dispatching trough your
owner-ship hierarchy this will be easily possible without the need to
modify the core. I only thought about adding an extra attribute as a
class-extension, but now I understand that you need to modify existing
functionality as well ... ;-)

> I would not expect that the core framework would need many modifications in
> order to get this working. The added value would be large. Other developers
> could simply subclass Description, and use these.

If you think the ownership (or something else that is missing) should
go into the core, you can directly modify the framework and submit to
my repository. If you register at <http://mc.lukas-renggli.ch>, I will
add you as a developer to the Magritte project.

Cheers,
Lukas

On 2/15/06, Runar Jordahl <[hidden email]> wrote:

> Thank you for your answer. Please read my comments below.
>
>
> On 2/14/06, Lukas Renggli <[hidden email]> wrote:
> > > 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.
>
>
> Thinking more about this, I would actually go for a :-) It would be nice if
> other developers could use your framework to make *any* description they
> like, without needing to modify the core framework. Below I outline how it
> could be done:
>
>
> Page 24 of
> http://www.lukas-renggli.ch/seaside/annecy/Magritte.pdf
> shows how Container has many "children" of type ElementDesc. Now, this leads
> me to think (or hope) that Magritte can create a Description being type
> "Container" for a single method (Accessor).
>
> Below I give an example of how a description for phone numbers could be
> marked being private using a new description class named
> MAOwnershipDescription. (Note that this class could have been added outside
> the core framework.)
>
> RunarPersonModel class>>descriptionPhoneNumbers
> ^(MAOneToManyRelationDescription auto: 'phoneNumbers'
> label: 'P. Numbers')
> classes: (Array with: RunarPhoneNumber);
> default: Array new;
> yourself) ,
> (RunarOwnershipDescription isPrivate: true)
>
> Just like "ZeroDivide , RangeError" creates an ExceptionSet (at least in
> VisualWorks), the message #, in the statement above will create a Container
> having two children. If this was used, developers could combine various
> descriptors for a *single* property. They could mix the descriptions in the
> core framework with their own, specialized descriptions.
>
> Accessing the descriptions will need specialised methods to get only one (or
> a set of) types. This is similar to how handling exceptions is done. An
> example could be accessing all ElementDesc (and subclasses), and sending
> #validate to them:
>
> aDescption on: ElementDesc do: [:anElementDesc | anElementDes validate]
>
> I would not expect that the core framework would need many modifications in
> order to get this working. The added value would be large. Other developers
> could simply subclass Description, and use these.
>
>
> Kind regards
>
> Runar Jordahl
>

Lukas Renggli

Re: Magritte

> "A framework for describing the types held by domain classes. This includes
> describing both basic units (like Booleans, numbers, and strings) and
> contents of collections. The framework also allows describing tolerated
> values in individual variables."

Yes, and also some basic relationship between described objects (has
to be improved as well).

For now I didn't add anything to Magritte that I didn't require in one
of my own projects. There are a couple of productive applications
using Magritte, as you can see in the slides. Obviously there are gaps
that need to be filled by other developers and their particular needs,
so this is really an open project that anybody can contribute.

> Thank you for being willing to add me as a developer. Please note that I
> will not submit any changes before you have agreed to them. If I look at
> doing any changes, it will be the ones I described in my last e-mail.

I've added you as developer to the "Magritte" (the core framework) and
"Magritte Add-Ons" (for small add-ons) project, so you can directly
publish there. If you want to keep your package in your own repository
you might want to create a new project and only commit the
fixes/modification that need to go into the core to the other
repositories.

Actually I don't mind if you publish your changes into "Magritte":
from time to time I will review them, maybe discuss with you and
eventually merge them into my image. The official versions known to be
usable are always on SqueakMap, anybody that is directly using code
from my repositories knows about the fact that it might be broken,
incompatible, change, etc.

> Which version of Squeak would you recommend using for Magritte?

I am currently working with Squeak 3.8. If you prefer 3.7 or 3.9
should be fine too. There are some tests that break in some versions
of Squeak, but this is not really a big deal.

Locking forward seeing your commits ;-)

Btw, there is a mailing-list at
<http://www.iam.unibe.ch/mailman/listinfo/smallwiki>, that might be a
good place to further discuss about Magritte, etc.

Lukas

On 2/16/06, Runar Jordahl <[hidden email]> wrote:

>
>
> Thank you for your answer.
>
>
>
> I think the current version of Magritte sums up to:
>
>
>
> "A framework for describing the types held by domain classes. This includes
> describing both basic units (like Booleans, numbers, and strings) and
> contents of collections. The framework also allows describing tolerated
> values in individual variables."
>
>
>
> From the presentation, I think Magritte is well-designed for doing this
> task. ElementDesc forms the superclass for these descriptions. Looking at
> the diagrams, it is easy to understand the design and how it is to be used.
> In my mind, this should not be changed. The core should probably not be
> messed up by introducing new information (like privately owned etc.) just
> because one developer has this need. I think if such a philosophy were
> followed, you would quickly see your well-designed classes cluttered. The
> core (ElementDesc) should stay like it is: "A system for describing types".
>
>
>
> Thank you for being willing to add me as a developer. Please note that I
> will not submit any changes before you have agreed to them. If I look at
> doing any changes, it will be the ones I described in my last e-mail.
>
>
> Which version of Squeak would you recommend using for Magritte?
>
> Kind regards
> Runar Jordahl