Why Gjallar is a "bad" Magma example (was Re: Great News - Pharo Support - Now Seaside.)

[Göran Krampe]

Hi!

Timothy James Ziebart wrote:
> 4. Are there other implementation options - sample code?  I understand 
> the Gjallar implementation is not recommended - true?

If the question is - should I look at Gjallar for general information on 
how to use Magma (regardless of Seaside actually) then the answer is no. :)

But sure, if you take the time to understand *why* this is so, then 
there may be interesting bits in there still.

Gjallar uses the "Command pattern" extensively which means that all 
modifications to the object model are done by instantiating a certain 
"Transaction" class, feeding it with all state desribing the change to 
be made, creating a Magma transaction, telling this object to "apply" 
itself, add that object to a never ending MagmaCollection and finally 
committing.

This means Gjallar has both a traditional Magma domain model AND an 
endless collection of "delta" objects that describe each and every 
change that has been made to the model.

The reason was originally to support an offline mode, which still 
exists, but no user of Gjallar has yet actually made use of that mode.

regards, Göran

PS. Gjallar will soon move to latest Magma, and hopefully gain 
performance from that. We are also probably going to test other means of 
persistence during the autumn. Magma is great and cool, but we do have 
some performance problems in Gjallar and while I can't say 100% for sure 
it is all Magma related we will profile and experiment.