Hi all,
I'm writing a series of tutorials for Spec for beginners like myself and I'd really appreciate any input on the material. The first episode is done: http://www.bahmanm.com/blogs/spec-part-1-basics -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) signature.asc (565 bytes) Download Attachment |
I'm glad you are doing that :). Marcus could you tweet about this blog on the Pharo tweeter account ? So many people are waiting for more tutorials on Spec. 2013/11/7 Bahman Movaqar <[hidden email]> Hi all, |
On 07 Nov 2013, at 10:08, Clément Bera <[hidden email]> wrote:
Yes, I will do that (i put it in the queue, I do one per day max :-)
|
well done, this is indeed a very good tutorial and more than welcomed, thank you :) I twitted it :) On Thu, Nov 7, 2013 at 11:30 AM, Marcus Denker <[hidden email]> wrote:
|
In reply to this post by bahman
Bahman Movaqar wrote:
> Hi all, > > I'm writing a series of tutorials for Spec for beginners like myself and > I'd really appreciate any input on the material. > The first episode is done: http://www.bahmanm.com/blogs/spec-part-1-basics > > Thanks Bahman. I like your writing style and theme. The code snippets are well presented. What platform is your blog hosted on? Some feedback... ----------- Not sure if you should be prompting people to dirty the Spec package by using example category Spec-Tutorial. Even though there is currently no such a package, one day there might be. Perhaps using category My-Spec-Tutorial would be better alternative. ---------------- > further radio buttons setup is done in setupTitleRadioButtons: looks like it should lose the colon at the end of the method name ------------- An alternative to the nested IF statements in MyFirstWindow>>userTitle... If you extend RadioButtonGroup with... RadioButtonGroup>>selected ^buttons detect: [:b | b state ]. and add instance variable 'radioButtonGroup' to MyFirstWindow and in MyFirstWindow>>setupTitleRadioButtons do.... radioButtonGroup := RadioButtonGroup new then you could have... MyFirstWindow>>userTitle ^ radioButtonGroup selected label Then again, for someone completely new to Smalltalk, the nested IF statements might be more familiar. So perhaps leave that part as it is, then describe how to refactor the code to be more 'Pharo' like. You might say... "at the time I did this, the RadioButtonGroup class was missing a method to return the selected button, but it was simple to extend the library with the following...." Note that I tested this on Pharo3, but I expect Pharo 2 would be the same for this case. cheers -ben |
Really nice tutorial :)
If I were you, I would based it on Pharo 3.0 more than 2.0. Why ? Because your tutorial will be outdated quite soon (in a couple on months) when 3.0 will be released. Our you could try to use the latest Spec version at least since the one shipped in 2.0 is old and out-dated :P
But it’s always cool to see people writing things about my work :) Once again, really nice tuto, and I like the way you write, keep going :)
Ben On 07 Nov 2013, at 16:01, [hidden email] wrote: Bahman Movaqar wrote:Hi all,Thanks Bahman. I like your writing style and theme. The code snippets are well presented. What platform is your blog hosted on? |
In reply to this post by bahman
On 11/07/2013 09:13, Bahman Movaqar wrote:
> Hi all, > > I'm writing a series of tutorials for Spec for beginners like myself and > I'd really appreciate any input on the material. > The first episode is done: http://www.bahmanm.com/blogs/spec-part-1-basics > Thank you folks for your encouraging! To be honest, that's one of the things that caught my attention to Pharo at first. The positive and helpful community. Glad that I could contribute a tad bit. @Ben: My website is running Plone (http://plone.org) using my own Plone hosting service (http://www.bahmanm.com/services/plone-hosting). Let me know if you're interested :-) Also the code highlighting is done by Good old Emacs :-) RE setupTitleRadioButtons: That's correct. The `:` should be left out of highlighting. RE userTitle: Cool! It takes time for me to change my Swing'ish way of looking at things. I'll add that. RE package: Subtle point. I'll change the package name. -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) signature.asc (565 bytes) Download Attachment |
Very nice tutorial! Keep on posting! best regards nacho Lic. Ignacio Sniechowski, MBA On Thu, Nov 7, 2013 at 2:36 PM, Bahman Movaqar <[hidden email]> wrote: On 11/07/2013 09:13, Bahman Movaqar wrote:
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
|
In reply to this post by bahman
EXCELLENT initiative.
I will read it. On Nov 7, 2013, at 6:43 AM, Bahman Movaqar <[hidden email]> wrote: > Hi all, > > I'm writing a series of tutorials for Spec for beginners like myself and > I'd really appreciate any input on the material. > The first episode is done: http://www.bahmanm.com/blogs/spec-part-1-basics > > -- > Bahman Movaqar (http://BahmanM.com) > > ERP Evaluation, Implementation & Deployment Consultant > PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) > > |
In reply to this post by bahman
Hi all,
A new episode is availabe: Spec - Part II: The Layout (http://www.bahmanm.com/blogs/spec-part-2-layout) I'd appreciate any comments/hints. TIA, -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) signature.asc (565 bytes) Download Attachment |
Bahman Movaqar wrote:
> Hi all, > > A new episode is availabe: > Spec - Part II: The Layout (http://www.bahmanm.com/blogs/spec-part-2-layout) > > I'd appreciate any comments/hints. TIA, > > Some minor nit-picks... > "please do so as we are going to iterate over what was done there." I don't understand what you mean by 'iterate over'? Do you me 'build on'? > "let's first settle for a target design. For the rest of this episode, we will try to achieve the following design. " I get to the bottom and the last snapshot it doesn't look the same as the one at the top. At the top you should mention that your target design is achieved over several posts (if that is the case). > "Note lines 9, 10, 17 and 18." "Note new lines 9, 10, 17 and 18." * At the top you should specify what version of Pharo the tutorial relates to. Information on the web hangs around for a very long time and someone could get trapped later trying your tutorial on a later version of Pharo. * Regarding #defaultSpec, I happen to like what is used in PharoLauncher specLayout <spec: #default> ^ SpecLayout composed ...etc Overall it a nice next step introducing just a bit more functionality. It reads very well. I look forward to the next one. cheers -ben P.S. Some questions for Spec gurus... * looking at #defaultSpec from this episode, if the pattern is always... mainColumn newRow: [ :aRow | aRow doStuff; otherStuff... ] what is gained over a pattern like... mainColumn newRow doStuff ; otherStuff. * is #defaultSpec always going to return a SpecLayout? In which case #defaultSpec feels like is should be #defaultSpecLayout. cheers -ben |
On 11/09/2013 12:23, [hidden email] wrote:
> Some minor nit-picks... > > > "please do so as we are going to iterate over what was done there." > I don't understand what you mean by 'iterate over'? Do you me 'build on'? Yes, that's what I meant: "improve". If you find it hard to understand, let me know. > > > "let's first settle for a target design. For the rest of this > episode, we will try to achieve the following design. " > I get to the bottom and the last snapshot it doesn't look the same as > the one at the top. At the top you should mention that your target > design is achieved over several posts (if that is the case). No wonder it doesn't match :-) Figure 1 is not a snapshot from the system. It is the UI design done in LibreOffice draw. I'll mention that. > > > "Note lines 9, 10, 17 and 18." > "Note new lines 9, 10, 17 and 18." > > * At the top you should specify what version of Pharo the tutorial > relates to. Information on the web hangs around for a very long time > and someone could get trapped later trying your tutorial on a later > version of Pharo. Correct. That's why at the beginning of this episode the reader is asked to first proceed to episode 1 if he hasn't done so already and in episode one in Prerequisites section (http://www.bahmanm.com/blogs/spec-part-1-basics#section-1) it is mentioned that for this series Pharo 2.0 will be used. > > * Regarding #defaultSpec, I happen to like what is used in PharoLauncher > specLayout > <spec: #default> > ^ SpecLayout composed ...etc I don't understand your point. Could you elaborate a bit more on this? > > Overall it a nice next step introducing just a bit more > functionality. It reads very well. I look forward to the next one. Your comments are much appreciated. It's always very useful to have another couple of eyes, QC a document :-) Thanks. -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) signature.asc (565 bytes) Download Attachment |
Bahman Movaqar wrote:
Okay. You should use 'build on'.On 11/09/2013 12:23, [hidden email] wrote:Some minor nit-picks..."please do so as we are going to iterate over what was done there."I don't understand what you mean by 'iterate over'? Do you me 'build on'?Yes, that's what I meant: "improve". If you find it hard to understand, let me know. That comment wasn't aimed at yourself, but to explain further...* Regarding #defaultSpec, I happen to like what is used in PharoLauncher specLayout <spec: #default> ^ SpecLayout composed ...etcI don't understand your point. Could you elaborate a bit more on this? I am not so familiar with Spec, but it would seem there are two ways to define the default layout: * defining the #defaultSpec method; or * adding the <spec: #default> pragma to one method. I'm not really sure of the tradeoffs between the two, but I think I liked the second simply because the word 'Layout' could appear in the method name. I'm not sure if that way of thinking is misplaced, but just based on my current understanding. Actually thinking about it some more, I wonder what would happen in two methods included the <spec: #default> pragma? This seems something that might not be immediately apparent without an exhaustive search through methods. Also, are pragmas inherited? For example, if class A has method #defaultSpec, with (A subclass: B) then class B would still open with the same layout. However if class A has no #defaultSpec method but instead the <spec: #default> pragma, would class B still open with the same layout? I know I could just try it out myself, but I am interested in any wider implications people can think of. cheers -ben |
In reply to this post by Ben Coman
[hidden email] wrote:
> > P.S. Some questions for Spec gurus... > > * looking at #defaultSpec from this episode, if the pattern is always... > mainColumn newRow: [ :aRow | aRow doStuff; otherStuff... ] > what is gained over a pattern like... > mainColumn newRow doStuff ; otherStuff. > I guess I can answer my own question from observing PharoLauncher's use of 'r' in the nested block. PhLCommandToolbar>>dynamicLayout "Create a spec layout with 1 row, and as many columns as there are command classes" ^ SpecLayout composed newRow: [ :r | self commandClasses do: [ :commandClass | r add: commandClass specId ] ] cheers -ben |
In reply to this post by bahman
Bahman Movaqar wrote:
> Hi all, > > A new episode is availabe: > Spec - Part II: The Layout (http://www.bahmanm.com/blogs/spec-part-2-layout) > > I'd appreciate any comments/hints. TIA, > > Question to Spec gevelopers... Referring to Bahman's example, how do you set the color of: * the 'Greet Me' button - I tried adding "buttonGreet color: Color red." to both #initializeWidgets and #initializePresenter, with no error, but also no effect. * dialog background - I don't see anything like #color under ComposableModel. cheers -ben |
I think it’s currently missing.
Not that much to implement though, but still not here :P
Ben On 09 Nov 2013, at 18:26, [hidden email] wrote: Bahman Movaqar wrote:Hi all,Question to Spec gevelopers... |
In reply to this post by Ben Coman
On 09 Nov 2013, at 09:53, [hidden email] wrote:
> Bahman Movaqar wrote: >> Hi all, >> >> A new episode is availabe: >> Spec - Part II: The Layout (http://www.bahmanm.com/blogs/spec-part-2-layout) >> >> I'd appreciate any comments/hints. TIA, >> >> > Some minor nit-picks... > > > "please do so as we are going to iterate over what was done there." > I don't understand what you mean by 'iterate over'? Do you me 'build on'? > > > "let's first settle for a target design. For the rest of this episode, we will try to achieve the following design. " > I get to the bottom and the last snapshot it doesn't look the same as the one at the top. At the top you should mention that your target design is achieved over several posts (if that is the case). > > > "Note lines 9, 10, 17 and 18." > "Note new lines 9, 10, 17 and 18." > > * At the top you should specify what version of Pharo the tutorial relates to. Information on the web hangs around for a very long time and someone could get trapped later trying your tutorial on a later version of Pharo. > > * Regarding #defaultSpec, I happen to like what is used in PharoLauncher > specLayout > <spec: #default> > ^ SpecLayout composed …etc The pragma should be preferred :) Actually the check is done like this: - take the first method found with defaultSpec (if multiple, te first found is used) - if none, and there is only one method with the pragma spec, use it - otherwise look for defaultSpec (this should be deprecated soon) - DNU the defaultSpec is a relic of the first version of Spec :) > > Overall it a nice next step introducing just a bit more functionality. It reads very well. I look forward to the next one. > > cheers -ben > > P.S. Some questions for Spec gurus... > > * looking at #defaultSpec from this episode, if the pattern is always... > mainColumn newRow: [ :aRow | aRow doStuff; otherStuff... ] > what is gained over a pattern like... > mainColumn newRow doStuff ; otherStuff. As I understood your question, you answered it :) I use block here so one can easily have a pointer to the row to do some magic here :) It also represents the columns/rows hierarchy > * is #defaultSpec always going to return a SpecLayout? In which case #defaultSpec feels like is should be #defaultSpecLayout. Even if it returns a SpecLayout most of the time, it could as well return an array with a spec structure. Actually, when you return a SpecLayout, it is converted into an array before wing interpreted :) (try to inspect one of your favorite SpecLayout and look at myLayout asArray ^^) > cheers -ben > |
In reply to this post by bahman
On 11/22/2013 13:51, prova email wrote:
> Hi Bahman, > i just finished to read the second Spec Tutorial, great tuto as > always. Only one question: why do you define the defaultSpec in the > Class-side? > I'm glad you found it useful. RE `defaultSpec`, I believe that's the way it is supposed to be. When I was writing the episodes, I had to read the `Spec-Examples` to figure out how to do stuff and all the examples defined `defaultSpec` as a class-side method. Maybe I'm doing it wrong. I'd appreciate if Benjamin could shed a light on this. -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) signature.asc (565 bytes) Download Attachment |
When a Spec UI is build, the spec are looked up on class side.
But in some special cases you can provide directly a SpecLayout object to a model.
Why on class side? The goal was to have a static description of a widget layout Ben On 22 Nov 2013, at 11:27, Bahman Movaqar <[hidden email]> wrote: On 11/22/2013 13:51, prova email wrote:Hi Bahman, |
|
Free forum by Nabble | Edit this page |