February is nearly out and I haven’t posted for a few weeks so I thought I’d just throw in my thoughts on the use and misuse of Singletons! Many of my colleagues working in Java pepper their code with static methods and use them as placeholders for pure function calls. Some would argue that the language encourages this.

I’ve also seen the same thing in Smalltalk code - since the class side only exists once in the image it is in effect a Singleton and therefore we can use this to our advantage and write class methods to achieve the Singleton effect. So if you want to create a WidgetFactory as a Singleton you can simply add class methods to WidgetFactory that return widgets for you (e.g. #getWidget:). But just because you can doesn’t mean you should!

So why not?

Responsibility Design

Good software objects have clearly defined responsibilities. The class side of an object has two basic contracts with the rest of your application…

1. To deliver properly formed instances of itself.
2. To manage state that is shared across all instances of the class

The class side should not be responsible for delivering instances of other classes. The class side of a WidgetFactory can return an instance of a WidgetFactory but it should not return a Widget. It’s not its responsibility.

Object Domain Model

It sounds obvious but an object software is made up of objects. Classes are not part of your domain model. They are meta objects that describe the shape and contents of your domain objects. If there is a need for a Singleton to perform a task like “create new Widgets based on some criteria” then this should be the responsibility of a WidgetFactory or the WidgetFactory (if you only want one of them in your image) but it is not the responsibility of the “WidgetFactory Class”. There is no such thing as a “WidgetFactory Class” in your domain model (unless of course your domain is meta programming)

Extensibility

As you design you can often be pretty sure that you want the WidgetFactory to be a Singleton (i.e. there will only ever be one WidgetFactory in the entire image). But what happens down the line when you discover the need for a second WidgetFactory (like the first but maybe implementing a slightly different WidgetContruction strategy). If all of your Widget creational methods (e.g. #getWidget are implemented as instance methods you can easily allow your application to create a second WidgetFactory which all your code will work with unaltered.

If you implemented #getWidget: as a class method on WidgetFactory you’ve now got a refactoring job to do. You can’t have a second WidgetFactory class - Smalltalk won’t let you and what’s more all your clients of #getWidget: are calling the class side. Ouch!

So how so you code a Singleton in Smalltalk?

Well first you define a class variable to hold the single instance - (I usually name this “Instance”)

Object subclass: #WidgetFactory
instanceVariableNames: ”
classVariableNames: ‘Instance’
poolDictionaries: ”
category: ‘WidgetsRUs-Model’

Then I create a class method #getInstance which returns the contents of “Instance” (lazy initializing if necessary)

class>>#getInstance
^Instance ifNil: [Instance := self basicNew ].

Finally I stop #new from returning another instance of my class

class>>#new
^self shouldNotImplement

Some people are tempted to make class>>#new return Instance although I prefer not to as this sets a false expectation on the reader of any client code that a new instance is being returned.

I picked up seaside for the first time 2 months ago and having played with the stuff I guess I’m intrigued by the question “why wouldn’t you use seaside?“.

Maybe it’s fundalmental to all conversion experiences to hold your new found beliefs as “patently obvious” but there must be reasons why people write web applications in other languages and frameworks rather than using seaside. A few (non technical) thoughts then on comparative religion and why people don’t write webapps in seaside.

1. Inadequate Evangelism
   “They do not believe because they have not heard!” Maybe the nature of people who get a buzz from seaside are just not the type to market there ideas well. (Actually its an interesting point as to whether seasiders want to evangelise this stuff - maybe there is some kind of inherently gnostic view that this is for the special chosen ones and would be too powerful in the hands of the masses.)
2. A Poor Image
   In a post modern world Image is everything. Thirty years ago we might have been able to argue the relative technical merits of different solutions and draw locigal conclusions. Not so now. Image is king. Java does the whole coffee (beans, jars etc) thing really well it’s image says “This is cool cafe culture programming”. Squeak Aubergines really don’t give the same message. Add to that the “child’s play” look and feel (and name) of Squeak and the secular Javarists will snort at our childish and unsophisticated beliefs.
3. The Lack of a Sacred Text.
   I’m sat in bed with my copy of “Programming the Ruby Way” knowing that this is a mere shadow of what a “holy book” should look like but hey some Ruby evangelist gave it me on a street mission in our town and I guess I ought to read it.
4. False Religion
   There are just so many “Annointed Languages” out there and “denominational frameworks”. And of course in a world of no absolutes they must all be true. Is it possible to declare that we have found “the truth that sets you free”. Does it make us arrogant “we know better than you” sorts or are we merely errant software developers who have accepted our failure to deliver, repented of it and found our coding salvation in Seaside. (For my part I feel a little like the prodigal son who eventually realised he was eating Java pig-swill and returned home)
5. Old Time Religion
   Smalltalk - yes I remember that. Didn’t they used to believe that everything was created from Object and there were no types. Still no-one really believes that anymore do they! Didn’t that chap prove that all things began with a Java Applet that evolved into a Servlet then a JSP that got cross-bred with some HTML - And I’m sure there was something about an infinite number of monkey’s typing it.

To complete our application we will allow our users to upload a picture of the contact so that it appears on the details drop down.

Got the Picture?

OK first we need to be able to upload a picture.

We will return to our MyContactEditor and modify the #renderContentOn: method to make the form a multipart form and add a file upload field.

renderContentOn: html
html heading: ‘Contact Details’.
html form
multipart;
with:
[
self renderLabel: 'First Name: ' withInput: [html textInput on: #firstName of: contact] on: html.
self renderLabel: ‘Surname: ‘ withInput: [html textInput on: #surname of: contact] on: html.
self renderLabel: ‘Date of Birth: ‘ withInput: [html dateInput on: #dateOfBirth of: contact] on: html.
self renderLabel: ‘Telephone: ‘ withInput: [html textInput on: #telephoneNumber of: contact] on: html.
self renderLabel: ‘Email: ‘ withInput: [html textInput on: #emailAddress of: contact] on: html.
self renderLabel: ‘Photograph ‘ withInput: [html fileUpload callback: [:file | self attachPhotograph: file]] on: html.
html span class: ‘button’;
with: [html submitButton on: #save of: self].
html span class: ‘button’;
with: [html submitButton on: #cancel of: self].
]

Now we need to code the #attachPhotograph: method that the uploaded file gets passed to.

attachPhotograph: aFile
| form sizedForm fileName tempStream|
aFile ifNotNil:[
tempStream := RWBinaryOrTextStream with: aFile contents.
tempStream binary.
form := ImageReadWriter formFromStream: tempStream.
sizedForm := form scaledToSize: 100@100.
fileName := contact identifier, '-photo.gif'.
GIFReadWriter putForm: sizedForm onOverwritableFileNamed: 'FileRoot', FileDirectory slash, fileName.]

This method takes the binary input stream and uses ImageReadWriter to obtain the “form” i.e. the picture. We then resize the picture to 100px by 100px and save it as a gif name fredbloggs-photo.gif (where fredbloggs is my contact’s identifier). I save the file in the directory FileRoot which I declared as my Document Root directory for my application.

Let’s see it Then

Now the final step is to amend the #renderDetailsDiv:on: method in MyContactDetailView so that it includes the image from our document root.

renderDetailsDiv: aString on: html
html div id: aString;
style: ‘display: none’;
with: [
html div
style: 'clear:both';
with: [

html image
style: 'float: left; margin-right:10px';
altText: ('Picture of ', contact fullName);
resourceUrl: '/', contact identifier, '-photo.gif' .
].
html render: ‘Name: ‘, contact fullName.
html break.
html render: ‘Birthday: ‘, contact dateOfBirth printString.
html break.
html render: ‘Telephone: ‘, contact telephoneNumber.
html break.
html render: ‘Email: ‘. contact emailAddress.
html break.
]

Job done! (Apart from getting a good CCS/Graphic designer to make it look super cool - If anyone wishes to contribute one I’d be more than happy to replace my rather basic one in session 3.)

If you stuck with me all the way to the end then I hope you found it worthwhile. And if your just starting out on Seaside I’d just like to encourage you to blog your progress. It really helps to crystallize your thinking and their are others out there who can add new insights as you go.

OK if you’ve stuck with me so far you should have a functioning application with a Scriptaculous effect that you have achieved with very few keystrokes (very few indeed if you just copied my code!). We are nearly at the end of our journey - just 2 more sessions to go. So for today’s session we will look at taking that “Toggle Details” link and make it more context sensitive - “Show Details” to show the details and “Hide Details” to hide them.

Finding a Replacement

This simple requirement was a little trickier than I first thought it would be. My searching through the Scriptaculous classes lead me to SUElement which had a very convenient #update: method. All I had to do was get it to change the text of my anchor text from “Show Detail” to “Hide Detail” when I clicked it. However once this was working I hit the problem of how to toggle it back again afterwards. I didn’t want to call back to the server and I didn’t want to write any Javascript so here’s what I did.

In my #renderContentOn: method in MyContactDetailsView I altered my “Toggle Detail” anchor to read “Show Detail” and added another anchor, “Hide Detail, like so…

renderContentOn: html
html anchor
id: (contact identifier, ’show’);
onClick: (html effect
id: (contact identifier);
toggleBlind);
with: ‘Show Detail’.
html anchor
id: (contact identifier, ‘hide’);
onClick: (html effect
id: (contact identifier);
toggleBlind);
with: ‘Hide Detail’.

Note here that I also gave the anchors unique id attributes which we will use in a few moments.

If you try this code you will see that you now have 2 links next to the Contact’s name. But they both work for showing or hiding!! What we need to do is hide the “Show Details” link when the details are open and reinstate it when they are closed.

So since we know that our details will start off closed we know we should start with our “Hide Details” link not showing. So do this with a simple style attribute…

...
html anchor
id: (player firstName, ‘anchor’);
style: ‘display: none’;
onClick: (html effect…

Now we need to toggle the anchors.

The Scriptaculous effect looks great on our big drop-down details box but is probably overkill for hiding and showing a link text. Instead of using SUEffect we are going to use the SUElement I mentioned earlier. We concatenate our element toggle actions into the #onClick: of both our anchors…

html anchor
id: (contact identifier, ’show’);
onClick: (html effect
id: (contact identifier);
toggleBlind),
(html element
id:(contact identifier, ’show’);
toggle ),
(html element
id:(contact identifier, ‘hide’) ;
toggle);
with: ‘Show Detail’.

(NB be sure to apply this to the “Hide Details” anchor too).

(NB2 the #toggle on SUElement appears to be superfluous as it toggles by default)

Now our links toggle the text correctly and that should be good enough (you might want to add a little CSS to get some space between the Link and our Contact’s name). But there’s one last goodie on the SUEffect that we can use that will add another little bit of wow to our app - the methods #onBeforeStart: and onAfterFinish:.

With these two methods we can make our links hide and appear either side of the opening of the details box. So our finished method looks like this…

renderContentOn: html
html anchor
id: (contact identifier, ’show’);
style: ‘margin-left:40px’;
onClick: (html effect
id: (contact identifier);
toggleBlind;
onBeforeStart: (html element
id:(contact identifier, ’show’));
onAfterFinish:(html element
id:(contact identifier, ‘hide’)));
with: ‘Show Detail’.
html anchor
id: (contact identifier, ‘hide’);
style: ‘margin-left:40px;display:none’;
onClick: (html effect
id: (contact identifier);
toggleBlind;
onBeforeStart: (html element
id:(contact identifier, ‘hide’));
onAfterFinish:(html element
id:(contact identifier, ’show’)));
with: ‘Hide Detail’.
self renderDetailsDiv: contact identifier on: html

Last part tomorrow.

Its time to get our little Contact List application into the Web2.0 era by adding a funky Scriptaculous dropdown on our contact list. The really cool thing is that we are going to do all this without writing a single line of Javascript (Lukas Renggli has already done that for us.  Much respect Lukas!) - it’s Smalltalk all the way for us!

Full Contact

Before we get on to dealing with our views I want to add a couple of methods to MyContact. First I want to add a #fullName method like so.

fullName
^firstName, ‘ ‘, surname

…we have already coded something like this when we rendered the list in MyAddressBookView but as we are going to use it again it makes sense to create a method for it. (You can go back and make the list view use it if you like). You may already have encountered some errors in concatenating a nil object to a string. We can prevent that with some defensive code in #fullName if we wish which is another good reason to create it as a separate method. (I’ll leave the defensive code up to you!).

Secondly iwant to add an #identifier method to act as a key to my contact. I will do this very crudely like this…

identifier
^self fullName asLowercase onlyLetters

…we’re going to use this identifier later as an id attribute on a div in our HTML.

Down to Details

We are now going to create a new class to show our Contact’s details.

1. Create the class MyContactDetailsView as a subclass of WAComponent and give it an instance variable of contact.
2. We need to create a convenience constructor #on: as a class method MyContactDetailsView. We’ve already done this for MyContactEditor so I’m going let you figure this step for yourself.
3. As we mentioned in an earlier session Seaside allows you to refactor your html into smaller more useable chunks. So before we dive into our #renderContentOn: method we will create another method #renderDetailsDiv:on: that it will call.
   

   renderDetailsDiv: aString on: html
html div id: aString;
with: [ html render: 'Name: ', contact fullName.
html break.
html render: 'Birthday: ', contact dateOfBirth printString.
html break.
html render: 'Telephone: ', contact telephoneNumber.
html break.
html render: 'Email: '. contact emailAddress.
html break.
]

   …this very simply creates a new div with an id attribute containing our contact’s identifier. This id attribute will be used by the Scriptaculous Javascript later on to hide and show the div.

4. Now we need to create our #renderContentOn: method and make it call #renderDetailsDiv:on:…
   

   renderContentOn: html
self renderDetailsDiv: contact identifier on: html

   …this is not the finished article yet but its good enough to let us test that all is well, so we’ll leave it here and come back shortly.

5. The last thing that we need to do before we can give our code a quick test is to add a line of code into the #renderContentOn: method in MyAddressBookView. Remember the #inject:into: call we coded last time? Well now we need to modify it so it looks like this…
   

   self addressBook contacts inject: 1 into: [:index :contact |
html div class: ('row', (index\\2) printString );
with: [
html anchor
callback: [self showContact: contact];
with: (contact firstName , ‘ ‘, contact surname ).
html render: (MyContactDetailView on: contact).
].
index + 1.
].

Before we move on let’s just give our code a quick test. We should see that for each Conact in our list we are displaying their details under their name.

Getting Animated
Now we are going to animate our details div so it toggles smoothly in and out of view.

Open up that one line #renderContentOn: method in MyContactDetailsView and add the following lines at the top of the method…

html anchor
style: ‘margin-left: 40px’;
onClick: (html effect
id: (contact identifier);
perform: #toggleBlind);
with: ‘Toggle Detail’.

What we’ve done here is added a new hyperlink “Toggle Detail” which when clicked will call a Scriptaculous #toggleBlind effect on the div who’s id attribute is the contacts identifier.

Test your app again and see what happens. Nothing eh!?

We have one last thing to do. We need to include the Scriptaculous library for our application. From the browser select “Configure” from the Seaside toolbar at the bottom of the screen (If you’ve got my CSS installed you might struggle to see it - sorry!). Add the SULibrary to your Application and save the configuration. Now test your Application again - how cool is that!

Just before we close for today we will just do one more thing. Our Contact list would look much better if the details started off hidden. So lets make it happen by modifying our #renderDetailsDiv:on: method in MyContactDetailsView like so…

renderDetailsDiv: aString on: html
html div id: aString;
style: ‘display: none’;
with: [ html render: 'Name: ', contact fullName.
html break.
html render: 'Birthday: ', contact dateOfBirth printString.
html break.
html render: 'Telephone: ', contact telephoneNumber.
html break.
html render: 'Email: '. contact emailAddress.
html break.
]

Homework
Before the next session open up a Class Browser on SUEffect and play around with the other things it can do.

Time’s tight today so I will just introduce my technique for creating alternating rows into our contact list.

Injecting a Little Class

Last time we added a CSS to improve the look of our application but our list needs a little something extra. It is very common when presenting a list to make each row appear in alternating colors. Today we will acheive this effect with our contact list.

The principal is simple and makes use of the class attributes and our CSS. All we need to do is display a row with a class attribute of “row0″ then display the next with “row1″, the next with “row0″, then “row1″ again and so on.

So here’s my solution using a Collection’s clever and often ignored #inject:into: method.

Select the #renderContentOn: method in MyAddressBookView and replace the following code…

self addressBook contacts do: [:contact |
html div class: ('row');
with: [
html anchor
callback: [self showContact: contact];
with: (contact firstName , ‘ ‘, contact surname ).
].
].

…with …

self addressBook contacts inject: 1 into: [:index :contact |
html div class: ('row', (index\\2) printString );
with: [
html anchor
callback: [self showContact: contact];
with: (contact firstName , ‘ ‘, contact surname ).
].
index + 1.
].

What we have done here is injected a counter into the loop and used a bit of modulo arithmetic to calculate the remainder of our index when divided by 2. At the end of the loop we increment the index so the new value can be injected back in next time.

Hopefully the .row0 and .row1 definitions are already in the stylesheet from last time.

You can easily extend this technique to alternate over more than 2 styles.

Next time we will get into Scriptaculous to make our little app look really cool!

So we’ve got a simple Contact List working but there are two big problems.

1. When I’m editing the contact the data changes even if I click “Cancel”.
2. It doesn’t look very pretty.

Today we are going to fix this…

A Little Memento

Our problem with the data changing even when we click cancel is a common one in “pass by reference” object oriented languages. In the editor view you are working with exactly the same object as you were looking at in the list view.

We can solve this with a Design Pattern called “Memento”. There are a few different ways of implementing Memento in Smalltalk (including the use of #become:, which I love to show to Java programmers but generally don’t recommend implementing in real systems). What I will present here is a use of Memento that goes like this.

1. From the list view the user selects an Contact to edit.
2. The System takes a copy of the Contact’s current state (a memento).
3. The System opens an editor on the original Contact
4. If the user clicks “Save” the system simply returns to the list view as all the data changes happened in the editor.
5. If the user clicks “Cancel” then we copy back the stored data from our memento into our Contact

(NB Some people prefer to let the editor work on the copy rather than the original object and then do nothing if Canceled or copy the new state if Saved)

So on to the code. First we need replace #showContact: in MyAddressBookView with…

showContact: aContact
| contactEditor memento|
memento := aContact copy.
contactEditor := MyContactEditor on: aContact.
(self call: contactEditor) ifFalse: [aContact resetFromMemento: memento]

Then we need to create a new #resetFromMemento: method in MyContact…

resetFromMemento: aMemento
dateOfBirth := aMemento dateOfBirth.
emailAddress := aMemento emailAddress.
firstName := aMemento firstName.
surname := aMemento surname.
telephoneNumber := aMemento telephoneNumber.

…and that’s all there is to it.

Improving my Looks

Before we can really show off our new app we need to get rid of that clunky browser default font and make it look a bit nicer. We will do this by adding a very simple CSS stylesheet. (I’m not a graphic artist or css expert so please don’t expect too much of this).

Seaside lets you code your CSS in a number of different ways but I concur with Ramon Leon’s conclusions that externalising CSS to a file is best. So here’s our CSS…

body { background-color: #fff;
font-family: “Trebuchet MS”}
div{
padding: 2px;
}
.row1 {
background-color: #99d ;
color: #fff;
}
.row0 {
background-color: #67d ;
color: #fff;
}
.row {
background-color: #67d ;
color: #fff;
}
a{
color: #ccf;
font-weight: bold;
text-decoration: none;
}
h1{
color: orange;
}
.field{
margin-left:30px
}

…which we need to save as “main.css” on the document root of our application. (This is most probably in the directory from which you startup squeak unless you have reconfigured your web server. See David Shaffer’s tutorial for more on configuring the web server)

We now need to make our web pages include a link to the CSS. We can achieve this by overriding the #updateRoot: method on our MyAddressBookView and our MyContactEditor as follows…

updateRoot: aRoot
super updateRoot: aRoot.
aRoot linkToStyle: ‘/main.css’

…but since you are adding the same method to two classes you really should refactor the hierarchy here by introducing a MyAddressBookBaseView class as a subclass of WAComponent. You can then make MyAddressBookView and MyContactEditor subclass this new class and move #updateRoot: into it.

Homework  !

So we now have an application that works and looks good too! (Well it will if you put a bit more effort int the CSS :-)).

Your homework for today is to grab the nearest Java or .Net developer and challenge them to build the same app as quickly as you have done!

So we’ve got our first cut domain model and now its time to add our views. Today we are going to add another two classes MyAddressBookView and MyContactEditor…

MyAddressBookView

1. We begin by creating MyAddressBookView as a sublcass of WAComponent with an instance variable of addressBook. (NB by using an instance variable it will mean that your address book gets reset for every session. If you’re not happy with that you can use a class variable instead)
2. Once again we will lazy initialize our variable
   

   addressBook
^addressBook ifNil: [addressBook := MyAddressBook new]


3. Now we will create our rendering method. We start simple by coding a heading…
   

   renderContentOn: html
html heading: ‘Contacts’ level: 1.

4. Then we add some more lines that will iterate over our collection of contacts and for each one display their name as a hyperlink to a page where their details can be edited…
   

   self addressBook
contacts do: [:contact |
html div class: ('row');
with: [
html anchor
callback: [self showContact: contact];
with: (contact firstName , ‘ ‘, contact surname )]]

5. Lastly we will add a few lines to create a button which will allow us to create a new Contact…
   

   html form: [
html span class: 'button';
with: [html submitButton on: #addContact of: self]]

   (Note here the the on: aSymbol of: anObject is a convenience method that uses aSymbol to derive a label for the button and the method to perform. Neat eh!)

6. Before this code can run we need to define the two methods that called in the renderContentOn: method above. First we will define the addContact: method
   

   addContact
| contactEditor contact |
contact := MyContact new.
contactEditor := MyContactEditor on: contact.
(self call: contactEditor) ifTrue: [self addressBook addContact: contact]

   …this is all pretty straightforward except to point out that we will only add our new contact if the editor replies true (as a result of clicking save)

7. Finally for this class we will add our showContact: method…
   

   showContact: aContact
self call: (MyContactEditor on: aContact)

   …managing save and cancel for new contacts is easy. For editing it is a little more involved. Next time we will alter this method to implement a memento for the contact

MyContactEditor

1. Now we need to create the editor for our contacts. Again we create MyContactEditor as a subclass of WAComponent this time with an instance variable of contact.
2. Now create the accessors for the contact variable like we did for the variables in our domain classes last time.
3. We are now going to create a class method that will deliver us a new Editor with the contact already populated…
   

   on: aContact
^self new
contact: aContact ;
yourself

4. One of the most powerful things about seaside is the ability to factor your html into small callable methods. When creating a form I often repeat the same pattern for each input field; I create a div; I put a label for the field inside a “label” span; I put an input field inside a “field” span. So lets create a method that will do that for us…
   

   renderLabel: aLabel withInput: anInputFieldBlock on: html
html div class: ‘row’;
with: [
html span
class: 'label';
with: aLabel .
html span
class: 'field';
with: anInputFieldBlock].

5. Now we can use this in our rendering…
   

   renderContentOn: html
html heading: ‘Contact Details’.
html form
with:
[
self renderLabel: 'First Name: ' withInput: [html textInput on: #firstName of: contact] on: html.
self renderLabel: ‘Surname: ‘ withInput: [html textInput on: #surname of: contact] on: html.
self renderLabel: ‘Date of Birth: ‘ withInput: [html dateInput on: #dateOfBirth of: contact] on: html.
self renderLabel: ‘Telephone: ‘ withInput: [html textInput on: #telephoneNumber of: contact] on: html.
self renderLabel: ‘Email: ‘ withInput: [html textInput on: #emailAddress of: contact] on: html.
html span class: ‘button’;
with: [html submitButton on: #save of: self].
html span class: ‘button’;
with: [html submitButton on: #cancel of: self].
]

6. Finally we need to create the save and cancel methods called by our buttons…
   

   save
self answer: true

   cancel
self answer: false

If you got through all that OK then open up a workspace and evaluate MyAddressBookView registerAsApplication: 'AddressBook' and hopefully you can then try out your app (most probably on http://localhost:8080/seaside/AddressBook)

Learning Seaside is fun and there are a number of good tutorials out there (but beware that some don’t use the latest Seaside 2.7 release) and a number of good blogs (I especially recommend Ramon Leon’s Blog). But it can still be a bit tricky to find examples of exactly what you want. What I’d like to do over the next couple of posts is provide a worked example of a commonly used presentation technique with an extra Scriptaculous twist.

The Big Picture

One of the first things I look to do in a web framework is to create a page showing a list of items with each item having a hyperlink to a maintenance page for the item. It’s a pattern I use again and again in web applications but nothing does it as well as Seaside.

So I’ll whet your appetite today by showing you the screens we will build over the next few days.

The application is a simple Contact List. So first we have a page for editing contact details…

We then want a list of all our contacts looking something like…

Finally we will add a nice scriptaculous effect to show and hide contact details in-line…

Getting Started

So for a simple start today we’ll create our domain model in Squeak. We will create two classes MyAddressBook and MyContact…

1. Create a new category for your classes, say, MyContacts
2. In your category create a new class MyAddressBook (for now you can simply subclass Object) with an instance variable contacts
3. Create a getter for contacts that lazy initializes to an empty OrderedCollection…
   

   
contacts
^contacts ifNil: [contacts := OrderedCollection new]


4. We will also create an instance method to add a contact to the address book (We won’t bother with deleting contacts - you never know when they will come in useful ;-))
   

   addContact: aContact
self contacts add: aContact

5. Now create another new class MyContact with instance variables firstName, surname, dateOfBirth, telephoneNumber and emailAddress
6. Create a setter and getter method for each variable. E.g.
   

   firstName: aString
firstName:= aString


   firstName
^firstName

7. For simplicity we will lazy initialize dateOfBirth to be today’s date.
   

   dateOfBirth
^dateOfBirth ifNil: [dateOfBirth:= Date today]


That will probably do for starters - no Seaside yet just everyday Smalltalk . We will pick up here later.

So I sat down last night with my 9 year old boy who’s got in his head some ideas about a game he wants to write. We open up Scratch and I start to show him what it can do.

First I animate my cat and get him walking around.

“But it has to be a monkey Dad, not a cat”

“OK we’ll make him a monkey” - we select the cat and change his costume. Cool.

“But the monkey has to go into the tree house, Dad.”

“OK. Lets create a background with a tree house.” - we build our stage and add a tree house with a ladder. When the monkey gets to the ladder he climbs it and gets to the house.

“Now he needs to go through the door and be in the lounge”

We make it happen. I smile smuggly at what we’ve acheived and tell him that’s it for tonight.

“OK but tomorrow I want to get my friends on the internet to come and join me with their monkeys in the lounge”

I swallow hard and explain how I can’t do that with Scratch.

The kids of today just want it all! Maybe tomorrow I’ll show him Croquet.