SBlog - Day 2 Implementation
Last updated at 11:51 am UTC on 17 January 2006
After the initial design was laid down and the initial base image assembled, the challenge team went to work on the actual implementation. Here is the code. At this point, conceptually the implementation splits into two different categories. The Weblog Server Model and the Web User Interface.
The Squeak Weblog Server application takes the familiar form of Model-View-Controller (MVC) with a few twists. This concept originated in the early Smalltalks of yore.
See Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC) for an in depth explanation of MVC. Also, see Model-View-Controller Pattern
The Weblog Server Model manages the behavior and data of the application domain, responds to requests for information about its state, and responds to instructions to change state. The server model is the natural repository for persistent data, and is naturally responsible for data management and validation.
The first implementation of the server model consisted of a few classes:
Each of the above classes may be stored persistently, so the are all derived from class BlogStorable. Presumably BlogStorable will provide the mechanism to store each of the derived class instances persistently. Another class within the model is BlogStore. Presumably it will be used to provide the physical interface to the data store.
The Power of Smalltalk:
Even at this early stage, there are some interesting code snippets in the model to point out. For example, on the instance side method of class Blog
^self entries select: [:eachEntry | eachEntry category = aString]
This method returns a collection of all of the posts that have a category named aString. The returned collection may be empty. Even at this early stage, when the programmers haven't even defined exactly what entries or categories are, a block iterator can "do the right thing". This is in major contrast to most other programming languages which would force the programmer to go through several more levels of definitions before such a thing could be attempted.
Another interesting method is on the instance side of class BlogAuthor
"return true if aString matches this author's password"
^ (self hashPassword: aString) = passwordHash
The programmers knew that they did not want to send passwords over the wire unencoded. Fortunately, Squeak has built in to the base image encode/decode functions for dealing with passwords in a standard way.
SBlog - Day 2 Web Interface
SBlog Challenge Participants Area
sblog top>Project SBlog - the Squeak Weblog Server