That's very nice, now if we can get GLORP working with it by generating GLORP descriptor systems off the magritte model, we will have the full package. That's what I'm starting to work on. -Todd Blanchard On Jan 13, 2007, at 11:41 AM, Lukas Renggli wrote:

Yes, just yesterday we discussed about it and in what direction we want to push our models. We also discussed about maybe merging Magritte and Meta. I also learned that he is going into the direction of automatic code-generation, something that I always wanted to avoid ... Lukas -- Lukas Renggli http://www.lukas-renggli.ch

So is Ramon, and I think Alan Knight said he had an ActiveRecord for GLORP as well. Is there any overlap between you guys, or are all three approaches different? If so, maybe the news team could interview you guys for a feature break down, so outsiders like myself could see what options are out there. I think it would be good for it to become more public that Squeak probably handles CRUD apps better then Rails at this point. _________________________________________________________________ Communicate instantly! Use your Hotmail address to sign into Windows Live Messenger now. http://get.live.com/messenger/overview

Yea, I'd definitely like to work with the latest version. I just released what I have on SqueakSource, check out my blog for where I'm at, I just explained it on http://onsmalltalk.com/programming/smalltalk/a-smalltalk-activerecord-using… Ramon Leon http://onsmalltalk.com

Todd Blanchard wrote: Sweet, I look forward to it, Glorp's my new favorite tool. Ramon Leon http://onsmalltalk.com

The meta model used in Moose, the re-engineering tool of the SCG. http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi? query=Duca06d&abstract=yes Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Interesting. From my own experience, I've seen this problem first hand. A couple years back, I was thinking of the same basic principal that Magritte solves. My family owns a small business, and have a software program tracking customers and other related data. Certain data however, would have no applicable field. So it would instead be placed in a "Customer Notes" text field. Several issues came from this. The obvious is it was essentially impossible to search and sort. The data was extremely inconsistent. "Customer has pets" is different than "Customer has a dog", etc. Even remembering to note if a customer has pets or not is a challenge, since the field wasn't required. It also brings up training issues with new employees. And this is just a small business, the problems would be amplified with larger companies. On top of all that, it would be nice if you could market to specific "customers with pets" as an example. So you are losing a potential revenue stream here. And that is just one little field. I remember thinking at the time, it would be nice if you could create fields on the fly maybe using a oodb. Giving a place for the data. The idea kinda got stored somewhere. Probably never to be brought up again. But when I learned of Magritte it immediately sparked a light bulb in my brain. -- Jason Yates jaywhy(a)gmail.com

That depends on where the recursion happens. Imagine the following problem: Person class>>descriptionPartner ^ MAToOneRelationDescription new reference: self description; yourself This is purely Smalltalk and Magritte cannot do anything about the recursion caused here. When you evaluate "Person description" Magritte will collect all the description elements and also call #descriptionPartner that calls #description and leads to an infinite recursion. 1. The simplest solution to this problem is a hack: Person class>>descriptionPartner ^ (MAToOneRelationDescription selector: #partner) reference: (MADynamicObject on: [ self description ]); yourself MADynamicObject is a proxy that delegates most of its messages to the result of the block evaluation. This is easy and mostly works, however it is very hard to debug and usually leads to problems sooner or later. There are a couple of examples in Magritte, Pier and Pier- Unix-Security of this hack. This does not solve the problem with the recursion when validating or printing the object. 2. Another solution is just to exclude the circular references from the referenced: Person class>>descriptionPartner ^ (MAToOneRelationDescription selector: #partner) reference: (MADynamicObject on: [ self descriptionWithoutReferences ]); yourself And then you need to implement something like this: Object class>>descriptionWithoutReferences ^ self description reject: [ :each | each isKindOf: MAReferenceDescription ] Not very nice, but it works well. It should also solve the problem when validating or printing a recursive object. 3. Compose your descriptions dynamically on the instance side. Person>>description | desc part | desc := MAContainer new. part := MAToOneRelationDescription selector: #partner. desc add: (part copy reference: part). ^ desc Ugly and looks like a Java UI built manually, but it also works for validating or printing recursive objects. As I mentioned in earlier mails the goal would be to enable the detection of recursion in validation, printing and serialization automatically. Note: Magritte seems to lack some feature in the field of complex composed objects (especially if you compare it with EMOF that has something like an 'opposite' for back references, etc). This comes from the fact that most (or even all) my described objects form a tree and not a graph with loops. Of course the object model has loops, but they are all handled manually with the glue-code in- between that is not considered by Magritte. That's the power of Smalltalk, everything is real close together ... HTH, Lukas -- Lukas Renggli http://www.lukas-renggli.ch