Here are a couple of items with my first 5 minutes with the TODO tutorial...
TODOListPresenter >> initializePresenters
todoListPresenter := self newTable
addColumn: ((SpCheckBoxTableColumn evaluated: [:task | task
isDone])
width: 20);
addColumn: (SpStringTableColumn title: 'Title' evaluated:
[:task |
task title]);
yourself.
self layout: (SpBoxLayout newVertical
add: todoListPresenter;
yourself)
In this portion (Showing Tasks) - it does not define todoListPresenter....
is it a local or a missed instVar. I tried it first as a local to enable
save, but then...
TODOListPresenter >> updatePresenter
todoListPresenter items: TODOTask selectAll asOrderedCollection
todoListPresenter isn't available for updatePresenter... so I'm assuming it
must be an instvar? I created accessors, then changed all the
todoListPresenter references to use the accessors (below).
TODOListPresenter >> initializePresenters
self todoListPresenter: (self newTable
addColumn: ((SpCheckBoxTableColumn evaluated: [:task | task
isDone])
width: 20);
addColumn: (SpStringTableColumn title: 'Title' evaluated:
[:task |
task title]);
yourself).
self layout: (SpBoxLayout newVertical
add: self todoListPresenter;
yourself)
and...
TODOListPresenter >> updatePresenter
self todoListPresenter items: TODOTask selectAll asOrderedCollection
Also, in the first example - task isDone needs to be defined (and might be
defined later in the tutorial) - I'm assuming
SpCheckBoxTableColumn>>evaluated: is expecting a boolean, or do I need to
convert this somehow? I can check all these things out - but just curious
if I'm missing something?
TODOTask >> done
^ done
TODOTask >> isDone
^ self done
I'll go through a bit more and update you on my progress. Ted, I also hope
to get to take a look at Zebra today :)
On Sun, Aug 2, 2020 at 2:07 PM Stéphane Ducasse <stephane.duca...@inria.fr>
wrote:
>
>
> On 2 Aug 2020, at 19:51, tbrunz <wild.id...@gmail.com> wrote:
>
> I've been thinking lately that it would be nice to expand the number of
> Pharo tutorials we have available. But rather than (or along with)
> creating
> more "beginner" level tutorials, I'd like to see some good "intermediate"
> level Pharo tutorials.
>
>
> Me too :)
>
>
> Let's do it, then. I'll volunteer to do most of the work. :^)
>
>
> I will review anything you write :)
>
>
> My hope is that participating in this will make me capable of creating
> advanced tutorials all by myself.
>
>
> I usually like to write to learn and dump what I learned.
>
>
> I think that programmers who already know the Pharo
> syntax and messaging semantics could benefit from more advanced tutorials
> that demonstrate how to develop "real world" Pharo code for "real world"
> processing needs.
>
>
> Yes yes I would love that.
>
>
> That was part of my motivation for creating a Pharo app to solve the Zebra
> Puzzle. First, of course, I wanted to solve it. ;^)
>
>
> I will send you some feeedback and PR.
>
>
> What I'm talking about is something that assumes you know the language,
> the
> basics of the IDE (but not necessarily how to leverage its capabilities
> to
> aid development), and the basics of the foundation classes (but not its
> details). I'd like a tutorial for intermediate Pharo programmers who
> want
> to become experts with Pharo. Something that can show you how to apply
> the
> tools of the IDE and the features of the language and base classes to
> create
> solutions that solve complex problems.
>
>
> do you have ideas?
>
>
> I do!
>
> As I started building the Logic Puzzle app, it occurred to me that I could
> probably find several different, common structures in OOP (specifically,
> Pharo) to add to the solution. And then each would be its own example of
> "what real Pharo code looks like". I.e., be good examples.
>
> But first, I needed to explore "how to do it in Pharo" for myself, which
> naturally would have me working the IDE strongly.
>
> Then I thought, the entire application can/should be an example, so it
> should be a tutorial.
>
> That means that I need more than just a completed application (that's "just
> an example"). To be a *tutorial*, it means starting from scratch, showing
> how to approach the solution, how to start a Pharo app, how to use the IDE,
> how to write tests, how to refactor code, etc.
>
> Then I thought, this needs a GUI. Either a Spec2 UI or a web app UI (with
> Seaside or Teapot). But I would need help with that! So I'll start by
> creating a message-based solution, and maybe get help to add a UI later.
>
> I did some prototyping, then got what I think might be a good code
> structure
> (by version 4; it took a while to "think pure OOP"; old habits are hard to
> fight against). It runs, it works.
>
> But.. Is it "good Pharo code"? I'm not experienced enough to answer that
> question. I need a code review, criticism, guidance. Point me in the
> right
> direction and I'll keep working on it, and start thinking about how to
> express the "meta" elements (how to use the IDE to make/test the code,
> etc.).
>
> What does the community think of this idea?
>
>
> I love it. I did Pharo by example so that I can get of rid of the beginner
>
> parts.
>
> After I did learning OOP and Pharo with style so that I do not have to talk
>
> about it
>
> again.
>
> So definitively.
>
>
> Okay, great. I'll do most of the work. But I need help...
>
> I don't want to go any further without someone much more experienced than I
> am to review what I have and let me know what I'm doing right & what I'm
> doing "no quite so right". Yes, it runs, it works -- but that's *not* good
> enough. The goal here isn't to "hack out a solution and move on", the goal
> is to "create an example and tutorial that's high enough quality to use to
> teach Pharo to other people". I don't want to be teaching *my* bad habits!
>
> Also, I know next to nothing about Spec2 or Seaside/Teapot. I just know
> that I need to learn it, and I need to use it to give my tutorial a UI (or
> two). Newcomers will show up wanting to learn Pharo, and they need to be
> reassured that they can create nice (enough) UIs without a huge effort.
> (Not everyone is a command line hacker, and end-users certainly don't want
> to be.)
>
> The more I learn (from you), the more I can be independent, and the more
> tutorials I could produce -- without a lot of help. I'm willing to do the
> work, because that will help make me a Pharo "master programmer". (I don't
> want to be a hack, and I can't really be a trainer if I'm just a hack
> myself.)
>
> I'll pay back the community by helping to attract and advance more
> developers' skills. I just have to have the more advanced knowledge &
> skills myself. So, train the (future) trainer, anyone??
>
> -Ted
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>
> --------------------------------------------
> Stéphane Ducasse
> http://stephane.ducasse.free.fr / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Aurore Dalle
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>
>
--
Russ Whaley
whaley.r...@gmail.com
