externalizing Magritte descriptions and partial forms
Hi, I'm trying to wrap my head around Magritte but I am failing hard... Imagine I have object with three attributes. ~~~~~~~~~~~~~~~~~~~ Object subclass: #Person instanceVariableNames: 'name age email' ~~~~~~~~~~~~~~~~~~~ Now the normal way would be to add magritte descriptions... ~~~~~~~~~~~~~~~~~~~ Person>>descriptionEmail <magritteDescription> ^ MAStringDescription new label: 'Email'; accessor: #email; beRequired; yourself ~~~~~~~~~~~~~~~~~~~ etc for the rest... And now if I want to manipulate it I would do... ~~~~~~~~~~~~~~~~~~~ |p| p := Person new name: 'Someone'; email: 'some@one.com'; age: 20. p asMagritteMorph addButtons; openInWindow. ~~~~~~~~~~~~~~~~~~~ So far so simple... however what I don't understand: 1. What if I want to have different descriptions for the same attribute? For example in some views the email is required and in others it is not. 2. Must the description be part of the object? Maybe I am still not fully committed to the having massive protocols with tons of extension methods instead of externalizing the code to separate adapters and whatnot. 3. What if I want only partial rendering? For example in one view I want to be able to edit only name and age, and in another one all three. Since #asMagritteMorph collects everything I don't see how I can customize this. Now I do expect that all these things are possible, however as I'm just starting with Magritte it's a lot of information and concepts to absorb... so any help is appreciated. Also, is there maintained Magritte-Spec? I've seen something by Sean, but it's from 2013 with a single-ish commit. Thanks, Peter
On 21-09-15 02:46, Peter Uhnák wrote:
So far so simple... however what I don't understand:
1. What if I want to have different descriptions for the same attribute? For example in some views the email is required and in others it is not.
asMagritteMorph is just the quick and dirty variant for straightforward situations.
2. Must the description be part of the object?
Yes. Single responsibility principle applied.
Maybe I am still not fully committed to the having massive protocols with tons of extension methods instead of externalizing the code to separate adapters and whatnot.
Ahum, that is exactly what Magritte does, while reusing the smalltalk tools. For very large domain models (more than several hundred domain classes), you'll be able to do better using a dynamic object model, and then you'll have to develop browsers, editors and inspectors for that.
3. What if I want only partial rendering? For example in one view I want to be able to edit only name and age, and in another one all three. Since #asMagritteMorph collects everything I don't see how I can customize this.
asMagritteMorph provides the default. On Object it is defined as Object>>asMagritteMorph self magritteDescription asMorphOn: self Object>>magritteDescription ^ self basicMagritteDescription Object>>basicMagritteDescription ^ MAPragmaBuilder for: self which collects all descriptions and puts them in the container described by Object>descriptionContainer "Return the default description container." <magritteContainer> ^ MAPriorityContainer new label: self class label; yourself. The nice thing about a MA(Priority)Container is that it supports a large part of the collection protocol, so you can just do Person>>asNameMagritteMorph ^(self magritteDescription select: [:each | each label = 'Name']) asMorphOn: self So you'd define all possible descriptions you want on the domain object itself, possibly using extension methods, and override #asMagritteMorph to only return the default descriptions. For complex dependencies with extensions, use a smarter MAPragmaBuilder subclass that makes decisions based on which extensions are loaded. You also want to take a look at reference. In the Seaside generation that is used like MAInternalEditorComponent>>buildComponent ^ self value isNil ifFalse: [ (self magritteDescription reference asComponentOn: self value) setParent: self; yourself ] so that provides an extension point for nested objects. I don't see it used in Magritte-Morph
Also, is there maintained Magritte-Spec? I've seen something by Sean, but it's from 2013 with a single-ish commit.
I don't know if it needs more. Nothing changed in the spec interface since then, did there? Stephan
Thank you Stephan, I think the image is becoming much clearer. However I still don't understand how SRP applies here:
Person>>asNameMagritteMorph ^(self magritteDescription select: [:each | each label = 'Name']) asMorphOn: self
Surely this is responsibility of the tool that needs it, no? Otherwise the Person class would have to describe every single possible scenario. Or maybe the tool would puts this into an extension protocol, which while visually places the code to Person class is actually separated (because it's part of another repository).
Also, is there maintained Magritte-Spec? I've seen something by Sean, but it's from 2013 with a single-ish commit.
I don't know if it needs more. Nothing changed in the spec interface since then, did there?
The Magritte-Spec seems to be just an experiment (with three classes) and it breaks Magritte-Morphic. Also I know I have changed Spec interface in the last year alone and as far as I can tell there was a lot work done in before. In any case I can always use asMagritteMorph morph asSpecAdapter in the meantime and maybe stitch together a Spec version once I am comfortable with Magritte. Thanks! Peter
On 21-09-15 12:09, Peter Uhnák wrote:
Thank you Stephan, I think the image is becoming much clearer.
However I still don't understand how SRP applies here:
Person>>asNameMagritteMorph ^(self magritteDescription select: [:each | each label = 'Name']) asMorphOn: self
Surely this is responsibility of the tool that needs it, no?
No. It is a domain model. The person class is an information holder/structurer (Object Design, Roles, Responsibilities, and Collaborations), describing all possible uses, the user selects the one it needs. If the morph you need depends on the context in which it is shown, you might want to add a Person>>asMagritteMorphFrom: aDomainContext ^(aDomainContext magritteDescriptionFor: self magritteDescription) asMorphOn: self and do the selection on the other side
Otherwise the Person class would have to describe every single possible scenario.
Not the scenario, but the possible combinations yes.
Or maybe the tool would puts this into an extension protocol, which while visually places the code to Person class is actually separated (because it's part of another repository).
For optional parts that works well, especially using MAObject subclasses with the dictionary based properties.
In any case I can always use asMagritteMorph morph asSpecAdapter in the meantime and maybe stitch together a Spec version once I am comfortable with Magritte.
That sounds like the right order.
Peter Uhnák <i.uhnak@gmail.com> writes:
~~~~~~~~~~~~~~~~~~~ Person>>descriptionEmail <magritteDescription> ^ MAStringDescription new label: 'Email'; accessor: #email; beRequired; yourself ~~~~~~~~~~~~~~~~~~~
to complement Stephan's answer, you can add properties to your description that you use to filter them when building the morphs. For example: Person>>descriptionEmail <magritteDescription> ^ MAStringDescription new label: 'Email'; accessor: #email; beRequired; shouldBeShownInTheBasicView: true; yourself Then, when building the morph, you can #select: on 'shouldBeShownInTheBasicView' value. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
participants (3)
-
Damien Cassou -
Peter Uhnák -
Stephan Eggermont