Questions about Magritte
renggli at gmail.com
Tue Apr 14 20:42:53 MEST 2009
> 1) Has anybody defined the descriptions in other class but the model class?
> It seems to me that defining the descriptions as class methods in the model
> class creates a coupling between the model and the view that I would like to
> avoid. Part of that coupling is because of some view's "attributes" like
> label, priority, beSorted, readOnly, etc. It also couples the model with
> Magritte, which avoids me to use the model in an environment without
Magritte is not the "View". Magritte is model as well, the meta-model.
If you would like to keep descriptions separate, that can be easily
done using extension methods. So one could imagine having the
descriptions in a separate package, other than the actual model.
Furthermore different other packages could modify these descriptions,
or add their own.
Foo class>>descriptionBar (in model package)
^ MAStringdescription new
Foo class>>descrptionBarView: aDescription (adds the label in view package)
^ aDescription label: 'Bar'
Personally I keep the descriptions all in the model, unless there is a
good reason not to do so.
> I was looking around and it seems possible, but the method #asComponent
> sends the message #description which finally creates the description
> container with all the collected descriptions. I could have my own
> implementation of #asComponent or have another object to do it, but I wanted
> to know if somebody already did it.
You could override #description in your classes, or use
#asComponentOn: that can be used to use any description together with
any model to build a component.
> (btw, why #description and not #magritteDescription? it keeps my model
> objects from using the message #description for a business porpoise)
That concern comes up every couple of years. Probably it is because I
am not a native speaker and I never called one of my own business
properties #description. As you can see above, Magritte does not
depend on that name, if you do not like it you can use something else
with little additional code.
> 2) The description "descriptionCanton" of the tutorial, is another example
> of why I want to decouple descriptions from the model class. In the tutorial
> the cantons are hard coded in the method, but that is not possible in a
> "real" app. Cantons should be taken from another object, lets say the
> "Cantons" object. But if I keep the "descriptionCanton" in Address and use
> "Cantons" from there, I will be coupling Address with Cantons, which will
> prevent me from using Address in another context or with provinces or states
> instead of cantons. Does anybody has a suggestion for doing this?
See above and <http://www.lukas-renggli.ch/smalltalk/magritte/faq>.
> 3) To keep the objects that are created, the tutorial suggests to use a
> class variable, but that is an option that does not scale. For instance,
> what happens if I want to host the same app several times with different
> data? (we are planning to use GLASS) Using the tutorial classes, I would
> like to have an instance of MAPersonManager for one of our customers,
> another instance of MAPersonManager for other customer, and so on. Also,
> using a class variable keeps us from writing tests for that class because
> that variable is shared among all the objects (tests, the real app, etc). I
> think this is more a SeaSide question...
I would make the customers part of the model and store a
MACustomerManager in some "persistent root". Tests get their own
> 3) I see that Magritte always needs an object to edit it. I mean, an
> instance of Address to edit an address, an instance of Person to edit a
> person, and so on.
No. Descriptions can always be used on any object, as long as the
object can handle them. MAMemento is such a power-object. It can
essentially handle any set of descriptions. It simply keeps a
dictionary from descriptions to their current values.
These mementos are used during edit operations. To Magritte a memento
object looks like the real object, but it can be edited and changed so
that it is temporarily in an invalid state without affecting the real
object and thus other concurrent users. Some memento subclasses can
even detect and merge conflicts. The real object is only changed when
all validation conditions are satisfied.
Keep the questions rolling.
More information about the smallwiki