Make Phoseydon play with Seaside

From Cameron Sanders email:

In order to get the #asComponent (for seaside) feature to work with DBXTalk 
generated classes, I had to make two other tweaks. I have saved 
DBXTools-Descriptions to www.debrispublishing.com/camshared.

I have not signed the Pharo release. However, I will try to do that this week. 
In the meantime, let me say: any works that I author and make available on 
www.debrispublishing.com/camshared is released from my copyright, and made 
available under general copyleft principles.

Changes (sorry no monticello comment was added):

DBXEntity

DBXEntity>>#hasMany:as:  AND DBXEntity>>#hasOne:as:
 - returns new MADescription object
 - changed the #classes: argument.

DBXMagritteWriterVisitor>>#writeDescription:onClass:
 - was changed to produce output that compiles when the value is a kind of Array (e.g. conditions, classes, ...)
 - the commented out branch in the middle was intended to be another hack to generate, what could be a more desirable
    format for the magritte generated classes, e.g. [Smalltalk at: #SomeClass ] magritteDynamicObject.
    However, I forgot about that change and checked it in with the comment in place.

Original issue reported on code.google.com by guillermopolito@gmail.com on 13 Jun 2012 at 9:05

More comments:

Band-aide approach...

DBXMagritteWriterVisitor>>writeDescription: aMADescription onClass: aClass
| properties descriptionMethod classes |
properties := ';
'
join:
(aMADescription properties associations
collect: [ :assoc | 
'{1}: {2}'
format:
{(assoc key). "assoc value printString"
((assoc value isKindOf: Array)
ifTrue: ['{', ('. ' join: assoc value  ), '}' ]
ifFalse: [ assoc value printString ])} ]).
...
- <clipped>

Mine is a horrible solution. Given that there are blocks in the conditions 
loops, the traditional array notation, #( ... ), will not work anyway, so the 
curly-brace approach is fine. I played around with #respondsTo: and tried to 
generalize, but hit problems because the value is often a symbol or string. so 
in the end, to get my classes generated, I just did the above quick-n-dirty 
patch.

The only other changes I have gone ahead and made were to make certain that 
more methods of DBXEntity  return the newly created attribute/entity, so that I 
could say something like the following:

(e hasOne: #DpAddress as: #mailingAddress)
label: 'Mailing Address';
priority: 400.

So all of the #hasOne:as:, #hasMany:as:, etc.  .... Oops... looks like late 
last night, when I was updating packages to see if i was missing anything, I 
lost my changes to those methods! There were only 4 or 5 such changes, and they 
were trivial.

Cheers. I like the DBXTalk approach. And Magritte too. In the two major 
projects I worked on over the years, and even on a couple of small side 
projects, I/we ended up using meta-language tools to add runtime behavior; and 
the starting code for new objects, at least in the one big project, was 
generated from a short-hand table of the meta-language specs. Very powerful. 
And lazy people like me are drawn to such things.

Original comment by guillermopolito@gmail.com on 13 Jun 2012 at 9:06

ajperalt / dbxtalk

Make Phoseydon play with Seaside #73