Ha!
Now I think I got it!
Spec is MVVM and not MVC!
That means if I would like to implement with Spec, my root of entry
should be a subclass of Model (ViewModel in real).
If I would like to have a more MVC approach I would rather subclass
MorphicModel or StandardWindow as an Entry for own windows&widgets.....
That also means that using the MVC approach I would probably have to
implement my own controller layer with announcements and such, whereas
SPEC already provides quite some default "Adaptor" implementations that
handle and redirect events...
Well, it would really be great to have a "SushiStore" example for both
approaches so that newcomers could learn from the differences and decide
which way will work best for their existing experience.
I absolutely share the thought of diversity, but one should be able to
unload one of both approaches from an image so that learning and
development can be done more efficiently.
Maybe one should think of a move of all Spec Model subclasses to a
ViewModel subclass of Model. That could lower the initial learning curve
a little....
Getting there! I think.
Sebastian
On 2015-02-12 4:34 PM, Sebastian Heidbrink wrote:
Hi Sven,
I had it this way too. Thanks.
Unfortunately my Spec definition was a little different and didn't
work out at all. Especially upon resize.
But here is my question regarding embedding this into an "application".
Is this MVC? Here we have Model, View and Controller within one class
called Model....
That is exactly what made me think 1000times if this is right and a
vital way to go once you want to implement a real workflow.
I looked at all the different approaches.
Just becomming aware that Morph is actually not a class to derive from
is something a beginner needs to understand when he just wants to
implement a Window using Morphs.... and that is already a major
difference to other frameworks where a Window and a Button are part of
the same Hierarchy.
Oh wait and what is a MorphicModel then?
Is it a Morph or a Model? Or Both?
I did browse the Squeak/Self Morphic wiki sites and even though most
links do not work anymore, I have the feeling that a lot of knowledge
her e has already been lost and everybody invents his own wheel currently.
I want to be able to take a LoginModel and have 5 different Morph/View
implementations using it.
If Spec asks for this kind of Model subclassing, then I do understand
that some community members have their problems with it. Not saying
that this is the wrong way to go, but I would also rather devide the
scpec the model and the controll layer into different classes.
But since there is no example available for this I think one can't
even properly discuss that.
For beginners ther eshould be ONE implementation that guides them
through all needed aspects of OO programming including UIs.
Sebastian
Am 12.02.2015 um 15:53 schrieb Sven Van Caekenberghe:
So, how hard would it be for a normal user like me, who knows little about the
Pharo UI or Spec, to write a plain, simple Login dialog ?
It turns out it only takes 3 methods and some boilerplate code that is mostly
auto generated.
0. Make a subclass of ComposableModel with instance variables for the UI
elements that we need
ComposableModel subclass: #LoginModel
instanceVariableNames: 'usernameLabel usernameField passwordLabel
passwordField'
classVariableNames: ''
category: '_UnpackagedPackage'
1. Specify the layout of the UI
LoginModel class>>#defaultSpec
<spec: #default>
^ SpecLayout composed
newColumn: [ :col |
col
newRow: [ :row |
row
add: #usernameLabel width: 80;
add: #usernameField ]
height: self inputTextHeight;
newRow: [ :row |
row
add: #passwordLabel width: 80;
add: #passwordField ]
height: self inputTextHeight ];
yourself
2. Build the UI elements
LoginModel>>#initializeWidgets
usernameLabel := self newLabel.
usernameLabel text: 'Username'.
usernameField := self newTextInput.
usernameField autoAccept: true; ghostText: 'j...@acme.com'.
passwordLabel := self newLabel.
passwordLabel text: 'Password'; yourself.
passwordField := self newTextInput.
passwordField beEncrypted; autoAccept: true; ghostText: '******'.
self focusOrder add: usernameField; add: passwordField
3. Open the UI as modal dialog
LoginModel class>>#getCredentials
"self getCredentials"
| login dialog |
login := self new.
dialog := login openDialogWithSpec.
dialog modalRelativeTo: self currentWorld.
dialog cancelled ifTrue: [ ^ nil ].
^ login credentials
X. Some boilerplate code
Auto-generate read accessors for the 4 instance variables.
LoginModel>>#title
^ 'Login'
LoginModel>>#initialExtent
^ 350 @ 150
LoginModel>>#credentials
^ usernameField text -> passwordField text
I think this is pretty cool. I really can't imagine how much easier, how much
less code this should take.
Let us all learn to use what we have, accept it the way it is, and make it
better, together.
Sven
BTW: While writing this, following some senders/implementers, I found out that
in Pharo 4, CredentialsEditor does almost the same thing.
--
Sven Van Caekenberghe
Proudly supporting Pharo
http://pharo.org
http://association.pharo.org
http://consortium.pharo.org
