Glorp Session

We will use one of Ramón’s classes: MGGlorpSession.

MGGlorpSession subclass: #MyPostgresSession
    instanceVariableNames: ''
    classVariableNames: ''
    poolDictionaries: ''
    category: 'LearnGlorpSession'

And add an instance method that returns your Glorp Descriptor:

glorpDescriptionClass
    ^MyGlorpDescriptor

You can read more code about Glorp and PostgreSQL in Mapping Seaside Blog To PostgreSQL With Glorp.

Configurations

Using Rails you have several places to include configuration code for your application, you use database.yml, config.rb, environment.rb, environments/development.rb, environment/production.rb, etc. In those files you can set variables that your application code will use, execute code and basically, anything you need in order to provide the required parameters to your application.

If you use Django you have a settings file for your all your configuration needs.

Seaside is no exception, it provides a very powerful, flexible and versatile mechanism to configure a web application.

A Seaside configuration class provides more than just a set of keyed values, it defines the type of the values and it can provide a list of options that an administrator can change through the administrative interface of Seaside, it also provides some kind of ‘inheritance’.

Before getting into database connections with its user, password and other parameters, I will use a configuration class for those parameters. For an introduction about configurations you should read the following pages:

1. Configuration and Preferences
2. David Shaffer’s tutorial: Custom application configuration parameters.

Now back to our business. We will use a configuration class for all the required Glorp parameters:

WASystemConfiguration subclass: #GlorpSessionConfiguration
    instanceVariableNames: ''
    classVariableNames: ''
    poolDictionaries: ''
    category: 'LearnGlorpSession'

With these methods:

ancestors
    ^ Array with: WASessionConfiguration new

attributes
    ^ Array
        with: (WAStringAttribute key: #sessionClass) 
        with: (WAStringAttribute key: #glorpServer group:#database)
        with: (WAStringAttribute key: #database group:#database)
        with: (WAStringAttribute key: #glorpUserName group:#database)
        with: (WAStringAttribute key: #glorpPassword group:#database)

glorpDatabase
    ^'You need to provide a database'

glorpPassword
    ^''

glorpServer
    ^'localhost'

glorpUserName
    ^'postgres'

sessionClass
    ^MyPostgresSession

sessionClasses
    ^MyPostgresSession withAllSubclasses

Root component

I will assume you don’t have a Seaside root component yet so let’s write one:

WAComponent subclass: #GlorpExampleComponent
    instanceVariableNames: ''
    classVariableNames: ''
    poolDictionaries: ''
    category: 'GlorpExample'

renderContentOn: html
    html text: 'Glorp example - Add here calls to classes querying the database'

And with a class method:

canBeRoot
    ^ true

( You can read more about the root component here )

Then load this url in your browser (using the port you told SSKom to use): http://localhost:9091/seaside/config and enter the user and password ( defaults: admin/seaside ).

Under “Add entry point” define a name for our testing application, for the example I will use: glorpexample. Then select the Root component from the combo ‘GlorpExampleComponent’.

And now, pay attention to the options provided in the combo list named ‘Ancestry’. Your configuration class is listed there! Select it and click the Add button.

Now save the changes.

What do we have so far?

We have a Seaside application with our configuration class that provides a custom Seaside session that supplies connections to PostgreSQL.

If you load again the configuration page for our glorpexample application you can appreciate a separated section for the database! You can change the field values or revert to the previous ones.

That’s it! With these, all you need to do now to execute a query using Glorp is:

WACurrentSession value execute: query.

Installation

1. I will use Ramón Leon's Squeak image. It has a customized UI, much better than the default Squeak interface and comes with all we need ( Postgres access, Glorp, Seaside ).

2. Download and install the corresponding Squeak version for that image (check León's page).

3. Launch the Squeak image.

4. If you are on OSX change the port change the port SSKom port to some number greater than 1024, like: SSKom startOn: 9091 and execute ('Do it') that line.

Now you have Seaside running from that image and we can begin writing some code.

As a complete Smalltalk newbie one of my main concerns about writing a web application for the company I work for using Seaside was how to use database connections in a correct and scalable way.

After writing a couple of configuration pages in Seaside for a current internal application written in Rails a few months ago, I was ready to write something 'real'. Worried about how to get that done, I avoided the risks and kept working at other stuff.

Well, now I was getting again into the mood to trying it out and found a blog post about using Glorp and Seaside. The author, Ramon León, directed me to his MagritteGlorp package that provides connection pooling and integration with the Seaside session management code.

Well, after digging into it for a few hours I got it working and will be posting soon a basic guide/example of how to use it.

I have lost count of how many times in the last 12 months Costa Rica have been experiencing problems with the international links.

Today we are experiencing slowness again, which makes me think about the risks of relying too much on online services like Gmail and 37 Signals products, just to mention a couple of them.

Web applications are really useful but at least for some of us in this world, we should really think about the risks of having too much important information online and find a way of accessing the data without being connected.

Gmail provides POP access to all your email which at least gives you an alternative that you could frequently use to download your emails to your computer, Yahoo requires a payed account to make that happen. In the case of more sophisticated applications like Basecamp, it could get a little more complicated.

A couple of years ago when I began playing with the idea of coding my own future, I thought about implementing a couple of applications for the web but then I thought a little more about it: if an application can be used locally without requiring online access it should be written in that way. Why force the risks, scaling and security nightmares and many other things present in online applications, just for the sake of it?

If an application can work offline, that should be the preferred mode.