> On 13 Feb 2015, at 04:46, Sebastian Heidbrink <shei...@yahoo.de> wrote: > > Ha! > > Now I think I got it! > Spec is MVVM and not MVC!
Something like that ;-) > 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 am confused by your references to the SushiStore. The way I remember it, it was a Seaside demo. You want this re-implemented as a regular UI ? Not that that would be difficult, but it would make little sense. > 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. The world has changed, you can no longer look at a Pharo image and see only one true way. We have multiple, competing solutions in many areas and that is good. It is still perfectly possible to use senders/implementers to find examples and figure things out by exploring. > 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. That is good. Spec is not perfect, its main 'issue' is that the UI elements are called models, which confuses the hell out of people (me too in the beginning). But it does make sense, you model the UI (haha). The cool stuff about Spec is that is was designed to reuse components, not just how they look, but also how they work, with flexible wiring. This very difficult to do with just about any other framework. Just follow the original 'browser' example. Building GUI is not that simple, building good, flexible, reusable ones is hard. Spec can help and it certainly helps normal people building simple UIs. > 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 >>> >>> >>> >>> >> >
