ESUG and Keychain integration for Firefox

I arrived this afternoon in Brest, France for the ESUG 2009 conference. I didn't write much Smalltalk but got caught up with a few people and had a couple of interesting discussions.

There will be much Seaside to come but, taking a break from that over the past few days, I also managed to get a beta version released of my Keychain Services Integration extension for Firefox that allows OS X users to store their logins and passwords in Apple's keychain. This allows the passwords to be shared with other browsers like Safari and Camino and also lets you take advantage of features like Keychain locking to protect your stored passwords. If you use Firefox 3.x on OS X, give it a try and let me know how it goes - it's scratching an itch for me anyway.

Through the eyes of a child

On a whim, while walking in London yesterday, I popped into the Tate Modern gallery. I'm not a huge modern art fan, but a few pieces caught my attention. Two of the most interesting were No Title (Table and Four Chairs) and Red Room, which I've just discovered are both by Robert Therrien.

Red Room is, as the title suggests, a room where every single object (except the single white light bulb in the ceiling) is practically the same shade of red. The room is packed with stuff and it's surprisingly compelling to look at. The collection of objects screams that there's some hidden story here waiting to be deciphered.

No Title (Table and Four Chairs) is a large scale (3.5 times normal) dining table and four chairs. On first glance, I thought, "ok, a big table". But the more I studied it, the more I was almost unable to walk out of the room. I began to contemplate the effect of looking up at the underside of a table, of standing barely higher than the seat of a chair. Obviously, as children, we all saw the world from exactly this position, but I found the situation almost impossible to fathom, let alone to recall. Very interesting.

Check out photos of both or if you're in London drop by the gallery and see them for yourself.

Web Velocity released

Big news from Cincom on the Seaside mailing list today: they've made an evaluation version of their commercial Seaside-based Web Velocity environment available for download. In case you've missed the buzz, Web Velocity takes Seaside running in VisualWorks Smalltalk, adds ActiveRecord integration and a web-based development environment (written in Seaside, of course). If you're curious, head over and download a copy.

London

I'll be in London (UK) on Wednesday June 24 for 10 days or so. If anyone around there wants to meet up for a beer and talk Seaside, Smalltalk, or something else, send me an email or add a comment. Or if there are any good tech meetups during that time I'd be happy for a pointer.

Seaside 2.9 on VisualWorks

Good news from Cincom: it seems they have Seaside 2.9 ported to VisualWorks with all tests passing. They didn't start very long ago and I haven't heard the sounds of much struggling coming from that direction so it seems like porting wasn't too difficult. I'll give myself and the rest of the development team a pat on the back for that one!

Meanwhile, we're eyeing another alpha release and trying to stare down a few remaining rough edges that are preventing a reasonable attempt at a beta. If anyone feels like tackling an improved set of configuration/administration/development tools, let us know!

BC-STV

I am becoming increasingly fed up with the fear-mongering and misleading statistics being used by the campaign against the BC-STV electoral system being voted on next week in British Columbia.

I'm voting yes to STV for one very simple reason: it removes the fear of vote splitting, allowing me to indicate my true preferences. Period.

Have you ever heard any of the following statements?

• "This is an NDP riding, there's no point even voting for someone else."
• "This could be a close battle. Voting for the Green party might help the Liberal party get in."
• "I like this party but I don't like their candidate in my riding."

With STV, you'll never have to hear those again. You can indicate your true first preference and, if they don't get elected, your vote gets counted for your next choice. No more vote splitting. And voting is dead simple: you write a "1" next to your first preference, a "2" next to your second preference, and so on.

Any electoral system is a complex balance between individual and group freedoms, degree of proportionality, cost, and many other factors. There is no "perfect" system. BC-STV may get tweaked over time but, in the meantime, the freedom to vote the way I want is reason enough to support it.

It's a shame that our province doesn't seem able to manage a real debate about this significant and important issue but don't be fooled by the mudslinging from either side. If you find the pro and con sites for STV in BC a little too heated, the Wikipedia articles on STV and FPTP (as well as on other voting systems) at least list both pros and cons for each. I also found the website of the Electoral Reform Society in the UK had useful and interesting reading (including pros and cons) on many different electoral systems. Although their stated preference for STV may bias their assessments of other systems, the site is much more balanced than any of the BC sites.

When to use a Seaside Component?

A recent StackOverflow question asked "When to use Seaside components, and when to use simple render objects?". This is a common challenge for new Seaside users (with the additional wrinkle of whether they should be implement a Brush thrown in for extra confusion).

To some extent these decision end up being subjective design decisions but there are some pretty compelling reasons why you might need to use a Component. I took a crack at answering the question but I encourage you to post or look for alternate answers there if you think mine is wrong in some way. I think the question is an excellent one so I'd also encourage you to upvote the question and/or answer if you think it is appropriate.

While we're on the topic, asking and answering Seaside questions on StackOverflow might help gain us some exposure and legitimacy. I actively monitor the RSS feed for Seaside questions and I'm guessing a few other developers do as well.

The main content of my answer was:

First of all, you are correct that you do not need to use a Component in order to access the Session. Seaside 2.9 moves #session up to a new class WAObject which makes it accessible to almost all Seaside objects (including Components) but you can definitely refer to WACurrentSession yourself for now in 2.8.

Components provide roughly the following functionality in 2.8:

1. #renderContentOn: is called with an instance of whatever renderer class you specify in #rendererClass (instead of whatever renderer is in use when your object is asked to render itself)
2. A hook (#updateUrl:) to allow updating the URL used by the renderer to generate links
3. Hooks (#updateRoot:, #style, #script) to allow updating the HEAD section of the HTML document
4. The ability to be the root of an Application
5. Hooks (#updateStates:, #states) to make state backtracking easier
6. A hook (#initialRequest:) to allow initialization based on the request that caused the Session to be created
7. A facility (#children) to make sure all components below you will also have the above hooks called on them
8. The ability to add Decorations
9. The ability to show/answer/call (uses Decorations)
10. Some convenience methods (#inform:, #isolate:, etc)

If you don't need any of the above, you don't need a Component. If you need any of the above, you pretty much do need a Component unless you want to implement the equivalent functionality on your own class.

The simplest metric is probably: if you intend to keep the object around between HTTP requests it should be a Component; if you intend to throw the object away and create it on each rendering pass it probably doesn't need to be. If you imagine an application that was displaying blog pages, you'd probably have Components for a menu, a blog roll, the blog body, each comment, and so on. You might want to factor out the reading of the blog's markup and generation of its HTML so that you could support different markups or different renderers and so that the comment Components could support the same markup. This could be done with a non-Component class that implements #renderOn: and could be created and used by other Components as needed.

Seaside 2.9 currently splits up the above functionality by making WAPresenter concrete and introducing WAPainter as its superclass. 1-3 above are implemented on WAPainter and 4-7 on WAPresenter so you have your choice of what to subclass depending on your needs. It also removes a lot of methods from WAPresenter and WAComponent in an effort to make them easier for end users to understand.