February 2015 - Pharo-users

Seaside jQuery - Sorting a list with drag and drop and sending it back via Ajax causes OrderedCollection to turn into an Array?

by Mircea S.

The code below is form the Seaside book at: http://book.seaside.st/book/web-20/jquery/enhanced-todo-application/drag-an… ToDoListView>>renderContentOn: html self renderHeadingOn: html. html form: [(html unorderedList) id: (listId := html nextId); script: ((html jQuery new sortable) onStop: (html jQuery ajax callback: [:items | self model items: items] passengers: (html jQuery this find: 'li')); axis: 'y'); with: [self renderItemsOn: html]. (html submitButton) callback: [self add]; text: 'Add']. html render: editor My instance variable _itemList is initially OrderedCollection. As soon as I move the rows around in the page then entire list is sent back in it's new order. However, this time setItemList: receives an Array. Does this make any sense? Am I missing something?

Feb. 13, 2015

Re: [Pharo-users] Changes file size

by Guillermo Polito

El Wed Feb 11 2015 at 4:08:36 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> escribiÃ³: > 2015-02-11 10:02 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >> ps: As said in another thread, Torsten's version (descendant of mine) > >> didn't seem to have this issue. > > > Yes, we are making (some) progress. > > Maybe we should promote the latest version to #stable ? > > I think we should, but there is something with that too. There is only > one version in the MetaRepo whilst the rest of Metacello configs are > in the DBXTalk/Configurations repo. > > Well, the configurations should inhabit close to their projects. MetaRepo is only to publish the configurations. So the usual way to release should be: - commit the configuration to the repo of its project - then copy this configuration to metarepo Guille

Feb. 13, 2015

Learning Spec

by Sven Van Caekenberghe

Hi, >From now on it is forbidden to complain about Spec in general, unspecific terms unless you have taken the time to learn about it. Here is a guide to documentation about Spec, most recent first. There is an excellent presentation by Johan Fabry did during the last Pharo Days, 'Using Spec to Build a UI'. *MUST WATCH* (the video is not yet fully public, but soon will be, the link should work though): http://youtu.be/OL23s9ZUIR0?list=PL4actYd6bfnz98ngrKALwwStl3C3odEKG The slides are also not yet available, but soon will be (the talk is much better that the slides on their own). This draft chapter 'Spec: a framework for describing user interfaces' for an upcoming book: https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… Look in the image. Browse the hierarchy below AbstractWidgetModel in the category Spec-Core-Widgets in Pharo 4, look at the protocols called 'protocol' & 'protocol-events' mainly. Look for references to each class. Trace senders of methods until you arrive at examples. Study the examples, play with them, change them. The UI of most tools in Pharo is also implemented using Spec. Browse the hierarchy below ComposableModel to find them. (Komitter, Versionner, Critics, Metacello, the old Eye Inspectors, ..). Watch and learn. The cool Spec website: http://spec.st Read some cool articles like: https://medium.com/concerning-pharo/rediscovering-the-ux-of-the-legendary-h… See the section 'HP35CalculatorModel' for the Spec part. The following papers (some older ones refer to API that has changed): 'Seamless Composition and Reuse of Customizable User Interfaces with Spec' http://rmod.lille.inria.fr/archives/papers/Ryse13a-SCICO-Spec.pdf 'Spec - A Framework for the Specification and Reuse of UIs and their Models' http://rmod.lille.inria.fr/archives/papers/Ryse12b-Spec-IWST12-Final.pdf 'Spec â Technical Report' http://rmod.lille.inria.fr/archives/reports/Ryse12a-SpecTechReport.pdf Use the image to build a couple of simple UIs using Spec. You will be surprised to learn that it is not that difficult. Just go with the flow, don't try to enforce your world view on it, wait until you are further along. Have fun ! Sven PS: Once you have done all the above, you are most welcome to help improve Spec by discussing specific, concrete issues. -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

Feb. 13, 2015

Re: [Pharo-users] Changes file size

by Sven Van Caekenberghe

> On 11 Feb 2015, at 16:07, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > 2015-02-11 10:02 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> ps: As said in another thread, Torsten's version (descendant of mine) >>> didn't seem to have this issue. > >> Yes, we are making (some) progress. >> Maybe we should promote the latest version to #stable ? > > I think we should, but there is something with that too. There is only > one version in the MetaRepo whilst the rest of Metacello configs are > in the DBXTalk/Configurations repo. Torsten, should I try to fix this, or do you have other plans ? > I don't know if that is intentional or accidental. > > Regards. > > Esteban A. Maringolo

Feb. 13, 2015

Re: [Pharo-users] Writing a Login Dialog using Spec in 3 methods

by Sven Van Caekenberghe

> On 13 Feb 2015, at 04:46, Sebastian Heidbrink <sheidev(a)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: ' >>> john(a)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 >>> >>> >>> >>> >> >

Feb. 13, 2015

Re: [Pharo-users] Writing a Login Dialog using Spec in 3 methods

by stepharo

Thanks sven for your spirit and attittude. I should say that if people would have more your attitude I would fell much better. Yes indeed I'm down because of people wanting always more and not putting a drop of energy on the table. PS: I turned your mail into a spec future book chapter :) Le 13/2/15 00:53, Sven Van Caekenberghe a Ã©crit : > t 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: 'john(a)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.

Feb. 13, 2015

Re: [Pharo-users] Spotter vs Spotlight was: [Re: Cleaning code completition's namespace]

by Tudor Girba

Hi, On Wed, Feb 11, 2015 at 6:25 AM, Laura Risani <laura.risani(a)gmail.com> wrote: > > What do you mean about all existing menus in the image? Right now, the >> default Spotter searches for the top level entries in the World menu and >> then lets you dive if you want. It can also be made easily to search for >> all menu entries from the World menu. Is that what you have in mind? >> > > At that moment i thought of searching on all existing menu entries, for > example if Spotter-search for "Browse" menu-category results will include > "Browse scoped" (an entry of a menu you get for classes on the > ClassBrowser). Yet at this moment i'm not sure of how useful it could be. > > >> In this mail alone you list 4 different search tools: Finder, >> MessageBrowser, Spotlight, Search in Nautilus. Each of these behaves >> radically different without much of an added value. >> > >> The whole philosophy of Smalltalk revolves around a minimal and uniform >> model that can be used to express elegantly any action. For example, >> Smalltalk has a simple syntax, and yet you can explain with that simple >> syntax all things for which other languages require lots of hardcoded >> constructs. The same rigor should be applied to the user interface. With >> Spotter we strive to reach such a simple model that can be infinitely >> moldable to fit custom needs. >> >> Now, besides elegance, if any, what else is there? Given that search is >> such a pervasive action, before I start anything I first want to find an >> entry point. That can be a method, a class, a file, or whatever other >> object. To this end, first people think of what tool to use and then of how >> to find the interesting object inside that tool. With Spotter we want to >> eliminate the first step: we just open Spotter and start searching for what >> we want. It's not quite there, but I think it is amazingly close to this >> goal. >> >> > I liked a lot these paragraphs in theirself and also as a motivation for > Spotter. > > 2) Not having the regular features of a window that are useful depending >>> on the case, for shortcuting i would like volatile but for browsing results >>> i could depending on the case prefer persistency . >>> >> >> Certainly. The current solution focuses on search. Creating a persistent >> list of objects is still a work in progress but it is out of scope at the >> moment. >> >> > If at the method GTSpotterGlobalShortcut>>openGlobalSpotter one changes > #openInWorld by #openInWindow , one gets the persistent behavior (it also > includes the preview if opened). > So now i can open a volatile or persistent Spotter, i'm going to have a > keycombination for each one. In addition i get all the regular window > behavior i in some cases want. > This makes me really happy :) > > Only one little keybordian issue, Cmd+w doesn't close the window as usual, > the same happens with GTPlayground. It would be nice if these come > implemented so one doesn't have to add them. > Spotter is not yet meant to be used in a window. The rendering is really not appropriate for that :). Cmd+w should work for Playground. Does it not? Indeed openInWindow does not install the Cmd+W action, but that is morphic specific. > This already works. As explained before, something like: >> d #i >> >> will give you only the implementors of "d". So, # will search for the >> name of the category. This feature is not yet complete in that it does not >> highlight properly the results, but could you try to see if this fits what >> you have in mind? >> > > I've just read about that, and also the last bit on custom categories on > the blog. So now i will define a category for classes+selectors and map a > keycombination to open a volatile Spotter on ti, and remove the 5 results > limit (how do i do this?). This gives me my wanted "selector/class > shortcut" Spotlight provided me, improving the annoying deficiency > Spotlight has of showing no-longer defined names (i asked about it in a > recent mail to the list). > > Having a shortcut (Cmd+Shift+ArrowUp/ArrowDown) to jump through > categories, then why to limit the number of results in each category to 5? > Why not to show them all to avoid the need of going into the category? > Because you still want to have an overview of what is being detected. Spotter should not be optimized for the default pane that is being opened. It has to handle any object. Nevertheless, we do need a more obvious way to show the all items. > Did you try compiling the method that I sent in the previous mail >> (basically just copy paste that method in the GTSpotter class)? It should >> provide the behavior of Spotlight. Please try and let me know if it works >> for you. >> >> > Yes, it works at some degree. > I face this issue, if i type 'openIn' i get only 1/1 selector > #openeningDelimiters, and only if i continue to type 'openInW' i get 5/28 > selectors. > There was a mistake in the algorithm as the matching was case sensitive which is not useful in our case. So, try this: spotterSelectorsFor: aStep <spotterOrder: 0> | processor | processor := aStep listProcessor. processor title: 'Selectors'; filter: [ :originalQuery :stream | |query selectors | query := originalQuery trimBoth asLowercase. query isEmpty ifFalse: [ selectors := Set new. SystemNavigation default allBehaviorsDo: [:class | class selectorsDo:[ :selector | ((selectors includes: selector) not and: [ selector *asLowercase* beginsWith: query ]) ifTrue: [ selectors add: selector. selectors size > 5 ifFalse: [ stream addObject: selector inProcessor: processor ]]]]. selectors ] ]; actLogic: [ :each | self systemNavigation browseAllImplementorsOf: each ] > Also at some point i started to get an #inform: msg saying "WorldState > interCyclePause failed". > As Ben suggested, this is a separate issue. > So additions i would like to see built by default > Cmd+w to close on GTSpotter and GTPlayground. > This works. Could you explain what you do (including the versions and OS you use)? > Remove/know-how-to remove the 5 limit on results. > Every processor is defined in a class extensions annotated with <spotterPreview:>. The processor can specify the limit. Right now, the implementations specify 5 items. You can play with variations. > Selectors category. > You can just install this in your image. That is the whole point of a moldable tool: that you have the power of easily specifying what works for you. Font size configured at SystemBrowser to have effect on GTSpotter both on > search results and preview. > Good point. Could you open a Pharo issue for this one? > To summarize i love Spotter and it will be the tool i use the most (in > number of openings). > You see :) Thanks, Doru > Love, > Laura > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 13, 2015

Re: [Pharo-users] Writing a Login Dialog using Spec in 3 methods

by Sebastian Heidbrink

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: 'john(a)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 >> >> >

Feb. 13, 2015

Re: [Pharo-users] GSOC 2015 application

by Martin BÃ¤hr

Excerpts from Ben Coman's message of 2015-02-12 19:30:06 +0100: > Having the page title "Pharo Bachelor and Master Topics" is a little > uninviting for a short program like GSoC. > Might this be changed to something like "Pharo Topics" - with Bachelor & > Masters mentioned underneath along with GSoC. Later perhaps links to > additional sponsored-coding events could be added (anyone know of any?) http://semesterofcode.com greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

Feb. 13, 2015

Re: [Pharo-users] Writing a Login Dialog using Spec in 3 methods

by Sebastian Heidbrink

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: 'john(a)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 > >

Feb. 13, 2015