Smalltalk › Pharo › Pharo Smalltalk Users

Writing a Login Dialog using Spec in 3 methods

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

Sven Van Caekenberghe-2

Writing a Login Dialog using Spec in 3 methods

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: '[hidden email]'.
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

Screen Shot 2015-02-13 at 00.12.55.png (23K) Download Attachment

LoginModel.st (3K) Download Attachment

Sebastian Heidbrink-2

Re: Writing a Login Dialog using Spec in 3 methods

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: '[hidden email]'.
  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

Sebastian Heidbrink-2

Re: Writing a Login Dialog using Spec in 3 methods

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: '[hidden email]'.
  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

stepharo

Re: Writing a Login Dialog using Spec in 3 methods

In reply to this post by Sven Van Caekenberghe-2

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: '[hidden email]'.
> 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.

Sven Van Caekenberghe-2

Re: Writing a Login Dialog using Spec in 3 methods

In reply to this post by Sebastian Heidbrink-2

> On 13 Feb 2015, at 04:46, Sebastian Heidbrink <[hidden email]> 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: '
>>> [hidden email]
>>> '.
>>> 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
>>>
>>>
>>>
>>>
>>
>

Stephan Eggermont-3

Re: Writing a Login Dialog using Spec in 3 methods

In reply to this post by Sven Van Caekenberghe-2

In order to not get results like

the extent and width should be calculated values.

That would change the example code to something like

LoginModel class>>defaultSpec
<spec: #default>
^SpecLayout composed
newColumn: [ :col |
col
newRow: [ :row |
row
add: #usernameLabel width: self labelWidth;
add: #usernameField ]
height: self inputTextHeight;
newRow: [ :row |
row
add: #passwordLabel width: self labelWidth;
add: #passwordField ]
height: self inputTextHeight ];
yourself

LoginModel class>>labelWidth
^((StandardFonts defaultFont widthOfString: 'Password') max:
(StandardFonts defaultFont widthOfString: 'Username'))+12

Please note that there are still several places in Spec where

hardcoded values like 12 are used instead of semantic values.

This value should actually be dependent on font size.

Having the label texts twice in the code should also be avoided.

LoginModel class>>textFieldWidth
^(StandardFonts defaultFont widthOfString: '[hidden email]')+12

LoginModel>>initialExtent
^(3*12+self class labelWidth+ self class textFieldWidth) @ (5*self class buttonHeight)

There are several calculated values missing:

width = outside border + labelWidth + label field separator+fieldWidth+outside border

height = dialog title + textInput height + separator + textInput height+ separator+button height + outside border

Stephan

Sven Van Caekenberghe-2

Re: Writing a Login Dialog using Spec in 3 methods

Hi Stephan,

You are 100% right: I had similar code in there during my hacking but I decided to take it out to simplify things. A couple of important semantic constants are indeed missing. But it is not just that, IMHO, the LoginModel should say 'I am 2 fields heigh', the wrapping in the Dialog should add what is needed around that, because the dialog is adding stuff that the wrapped component does not know about.

Also, given Spec's (unfulfilled) ambition to have different backends, the whole idea of careful layout and measuring becomes quite hard, because that should be totally abstract.

Sven

> On 13 Feb 2015, at 10:48, Stephan Eggermont <[hidden email]> wrote:
>
> In order to not get results like
> <PastedGraphic-1.png>
>
> the extent and width should be calculated values.
>
> That would change the example code to something like
>
> LoginModel class>>defaultSpec
> <spec: #default>
> ^SpecLayout composed
> newColumn: [ :col |
> col
> newRow: [ :row |
> row
> add: #usernameLabel width: self labelWidth;
> add: #usernameField ]
> height: self inputTextHeight;
> newRow: [ :row |
> row
> add: #passwordLabel width: self labelWidth;
> add: #passwordField ]
> height: self inputTextHeight ];
> yourself
>
> LoginModel class>>labelWidth
> ^((StandardFonts defaultFont widthOfString: 'Password') max:
> (StandardFonts defaultFont widthOfString: 'Username'))+12
>
> Please note that there are still several places in Spec where
> hardcoded values like 12 are used instead of semantic values.
> This value should actually be dependent on font size.
> Having the label texts twice in the code should also be avoided.
>
> LoginModel class>>textFieldWidth
> ^(StandardFonts defaultFont widthOfString: '[hidden email]')+12
>
> LoginModel>>initialExtent
> ^(3*12+self class labelWidth+ self class textFieldWidth) @ (5*self class buttonHeight)
>
> There are several calculated values missing:
> width = outside border + labelWidth + label field separator+fieldWidth+outside border
> height = dialog title + textInput height + separator + textInput height+ separator+button height + outside border
>
> Stephan

Ben Coman

Re: Writing a Login Dialog using Spec in 3 methods

In reply to this post by Sven Van Caekenberghe-2

On Fri, Feb 13, 2015 at 4:18 PM, Sven Van Caekenberghe <[hidden email]> wrote:

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).

I find the same. So should we really rename ComposableModel to ComposableUIModel ? (And before Spec becomes more widely used?)

cheers -ben

jfabry

Spec terminology: renaming some terms.

If we think about renaming things in Spec, actually I’d rename:

- ComposableModel to ComposableUI

- all the protocols ‘protocol-*’ to ‘API-*'

On Feb 13, 2015, at 14:58, Ben Coman <[hidden email]> wrote:

So should we really rename ComposableModel to ComposableUIModel ? (And before Spec becomes more widely used?)

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile

EstebanLM

Re: Spec terminology: renaming some terms.

On 13 Feb 2015, at 18:29, Johan Fabry <[hidden email]> wrote:

If we think about renaming things in Spec, actually I’d rename:
- ComposableModel to ComposableUI

- all the protocols ‘protocol-*’ to ‘API-*’

+100

I’m super tired of “protocol” category (it is actually a protocol… as any other category under the “protocol” pane :P)

api is a lot better

On Feb 13, 2015, at 14:58, Ben Coman <[hidden email]> wrote:

So should we really rename ComposableModel to ComposableUIModel ? (And before Spec becomes more widely used?)

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile

Sven Van Caekenberghe-2

Re: Spec terminology: renaming some terms.

> On 13 Feb 2015, at 18:47, Esteban Lorenzano <[hidden email]> wrote:
>
>
>> On 13 Feb 2015, at 18:29, Johan Fabry <[hidden email]> wrote:
>>
>>
>> If we think about renaming things in Spec, actually I’d rename:
>> - ComposableModel to ComposableUI
>> - all the protocols ‘protocol-*’ to ‘API-*’
>
> +100
> I’m super tired of “protocol” category (it is actually a protocol… as any other category under the “protocol” pane :P)
> api is a lot better

I am pro too, but it does influence the docs a bit, ...

>>
>>> On Feb 13, 2015, at 14:58, Ben Coman <[hidden email]> wrote:
>>>
>>> So should we really rename ComposableModel to ComposableUIModel ? (And before Spec becomes more widely used?)
>>
>>
>>
>> ---> Save our in-boxes! http://emailcharter.org <---
>>
>> Johan Fabry - http://pleiad.cl/~jfabry
>> PLEIAD lab - Computer Science Department (DCC) - University of Chile
>>
>

jfabry

Re: Spec terminology: renaming some terms.

> On Feb 13, 2015, at 19:44, Sven Van Caekenberghe <[hidden email]> wrote:
>
>
>> On 13 Feb 2015, at 18:47, Esteban Lorenzano <[hidden email]> wrote:
>>
>>
>>> On 13 Feb 2015, at 18:29, Johan Fabry <[hidden email]> wrote:
>>>
>>>
>>> If we think about renaming things in Spec, actually I’d rename:
>>> - ComposableModel to ComposableUI
>>> - all the protocols ‘protocol-*’ to ‘API-*’
>>
>> +100
>> I’m super tired of “protocol” category (it is actually a protocol… as any other category under the “protocol” pane :P)
>> api is a lot better
>
> I am pro too, but it does influence the docs a bit, ...

I have no problem in fixing the docs, as you might well imagine :-) We should do a pass on all the Spec documentation anyway. I hope to find time somewhere in the beginning of april ...

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD lab - Computer Science Department (DCC) - University of Chile

Sean P. DeNigris

Re: Writing a Login Dialog using Spec in 3 methods

Administrator

In reply to this post by Sven Van Caekenberghe-2

Sven Van Caekenberghe-2 wrote

Spec is not perfect, its main 'issue' is that the UI elements are called models

I appreciate the ability to easily create standard vanilla business UIs... which we did not have in the not-too-distant-past. And I'm not too worried because everything's a work in progress. But I would say that my main issues with it are discoverability and understandability. It seems that we're getting further and further from the Morphic dream of dragging something visual that "almost does what you want" and dropping it into your cool new UI, or at least digging down through halos to see how things work. And when I step through layers of symbol interpretation I feel sad.

Cheers,
Sean

stepharo

Re: Writing a Login Dialog using Spec in 3 methods

In reply to this post by Ben Coman

Le 13/2/15 14:58, Ben Coman a écrit :

On Fri, Feb 13, 2015 at 4:18 PM, Sven Van Caekenberghe <[hidden email]> wrote:

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).

I find the same. So should we really rename ComposableModel to ComposableUIModel ? (And before Spec becomes more widely used?)

Yes we could in VW it is call ApplicationModel

cheers -ben

stepharo

Re: Spec terminology: renaming some terms.

In reply to this post by jfabry

I would like to clean the API with all the changed: [ ] and other

I am pro too, but it does influence the docs a bit, ...

> I have no problem in fixing the docs, as you might well imagine :-) We should do a pass on all the Spec documentation anyway. I hope to find time somewhere in the beginning of april ...
>
> ---> Save our in-boxes! http://emailcharter.org <---
>
> Johan Fabry - http://pleiad.cl/~jfabry
> PLEIAD lab - Computer Science Department (DCC) - University of Chile
>
>
>

Ben Coman

Re: Writing a Login Dialog using Spec in 3 methods

In reply to this post by stepharo

If ComposableModel's semantics is similar to VW ApplicationModel then calling it the sameis probably an advantage, but but I can't help thinking that ApplicationModel is more related to the application domain than the UI as we need. The suggestion in another thread for ViewModel sounds better - but I haven't dug into Spec enough to get a feel for which is more appropriate.

cheers -ben

On Sat, Feb 14, 2015 at 5:39 PM, stepharo <[hidden email]> wrote:

Le 13/2/15 14:58, Ben Coman a écrit :

On Fri, Feb 13, 2015 at 4:18 PM, Sven Van Caekenberghe <[hidden email]> wrote:

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).

I find the same. So should we really rename ComposableModel to ComposableUIModel ? (And before Spec becomes more widely used?)

Yes we could in VW it is call ApplicationModel

cheers -ben

Ben Coman

Re: Spec terminology: renaming some terms.

In reply to this post by EstebanLM

On Feb 13, 2015, at 14:58, Ben Coman <[hidden email]> wrote:

So should we really rename ComposableModel to ComposableUIModel ? (And before Spec becomes more widely used?)

On Sat, Feb 14, 2015 at 1:47 AM, Esteban Lorenzano <[hidden email]> wrote:

On 13 Feb 2015, at 18:29, Johan Fabry <[hidden email]> wrote:

If we think about renaming things in Spec, actually I’d rename:
- ComposableModel to ComposableUI
- all the protocols ‘protocol-*’ to ‘API-*’

+100
I’m super tired of “protocol” category (it is actually a protocol… as any other category under the “protocol” pane :P)
api is a lot better

Lets do it! If you recognize in yourself that feeling of "tension"between doing what is right, and the effort to do it - then we should do what is right. So can we first decide that we should and _will_ do something, and then have some debate to finalise the actual term. I proposed ComposableUIModel, but ComposableUI sounds fine, maybe better. And at the same time, are there any other Spec classes that should follow the same philosphy? We should make such change a one-time spoon of medicine!

cheers -ben