Login

Dynamic Web Development with Seaside PDF Available for Purchase

Reposted from Lukas Renggli blog:

The PDF version of the book Dynamic Web Development with Seaside is available to download now.

At the end of the payment process (PayPal) you will be redirected to the download area where you are able to get the latest builds of the PDF version of the book. If you bookmark the page you will be able to download fixes and extra chapters as we integrate them into the online version. By buying the PDF version you support our hard work on the book.

We wish to thank the European Smalltalk User Group, inceptive.be, Cincom Smalltalk and GemStone Smalltalk for generously sponsoring this book. We are looking for additional sponsors. If you are interested, please contact us. If you are a publisher and interested in publishing this material, please let us know.

So please, support the Seaside community and buy the book, I know I will.

SandstoneDb GOODS adaptor

SandstoneDb was written mostly as a rails'ish API for a simple object database for use in small office and prototype applications (plus I needed a db for this blog). Which object database wasn't really important to me at the time, it was the API that I wanted, so I made the actual object store backing it pluggable and initially wrote two different store adaptors for it. The first was a memory store which was little more than a dictionary of dictionaries against which I wrote all the unit tests. The second was a prevayler style file based store that used SmartRefStream serialization and loaded everything from disk on startup; this provided a crash proof Squeak images which wouldn't lose data.

I figured eventually, for fun I might get around to writing adaptors for some of the other object database back-ends that are in use: GOODS and Omnibase. I never really got around to it; however, Nico Schwarz has written a GOODS adaptor for SandstoneDb. This will let you hook up multiple squeak images to a single store and should scale better than the file store that SandstoneDb defaults to.

Go check it out and let him know what you think of it. This is just the kind of project that'll help programmers new to Seaside get going and get accustomed to using an object database rather than a relational one. It looks like his first blog post as well, so swing by and leave a comment to encourage more posts, we need more bloggers spreading the word!

On Twitter

OK, so I'm finally going to try out this Twitter thing. I still don't see why everyone is so obsessed about it but what the heck, they are, so maybe it is cool. Maybe some micro blogging will get me back in the mood to do some real blogging. If any of you guys are twitterers, come follow me so I have someone to tweet to.

Started working on a GLASS project, so maybe I'll tweet about that, and eventually blog about it as well (so far it fracking rocks).

Stateless Sitemap in Seaside

Originally I generated the sitemap for onsmalltalk as a file on disk and let Apache serve it up. There's nothing wrong with this approach but it'd be cooler if I had Seaside generate and render it on demand and serve as a good excuse to talk about serving up content statelessly in Seaside.

Seaside is a session based web framework, but there's nothing really session specific about a sitemap and I really don't want a new session created when a request for a sitemap is made. There's a lot of overhead in doing that and sometimes you just want to serve up stuff statelessly. When a request comes in, the application mounted on the base URL handles the request by plucking the session id out of the cookie or the URL and either creates a new session or finds the existing one needed to handle the current request. Once found, the request is pumped through the current session which runs through a similar procedure looking for a continuation to invoke.

Since I want to avoid all that and just handle the request at the application level I'll override #handleRequest: in my custom WAApplication subclass, check the URL of the current request and either render the sitemap and end the request by immediately returning a response, or allow processing to continue normally into the session lookup done by the call to super.

handleRequest: aRequest 
    (aRequest url endsWith: '/sitemap.xml') ifTrue: 
        [ ^WAResponse new
              beXML;
              cacheFor: 1 hour;
              contents: (self siteMapFrom: aRequest) asString readStream;
              yourself ]
    ^super handleRequest: aRequest

siteMapFrom: aRequest 
    ^ (SBSiteMapGenerator blogRoot: ('http://{1}/' format: {  (aRequest host)  })) 
        generateFromItems: {  (SBPost new)  } , (SBBlog onSmalltalk publicPosts) , SBTag findAll.

If you have things in your application that can be done statelessly, this is a good place to hook into the framework and take care of that stuff at the application level. Sometimes you don't need all that fancy Seaside stuff and you just want to work directly with HTTP requests and responses.

Two small methods and the sitemap is now generated dynamically, and statelessly directly from Seaside, removing the need to manually invoke the sitemap generation as I had previously been doing to the file system.

Oh, one small extension that I've put on WAResponse and use occasionally...

cacheFor: aDuration 
    self headerAt: 'Expires' put: (TimeStamp now + aDuration) httpFormat

1 February 2009 > Squeak Image Updated... To Pharo!

Just a quick notification that I updated my pharo image.

It's based on Damien Cassou's latest Pharo Dev Image. I switched to Pharo a couple of months ago and so far it rocks. Best Squeak image I've had to date and it's really nice to see the cleanup and UI work they're doing that Squeak was so desperately in need of.

Keep up the great work guys! Pharo is coming along nicely and looks more and more professional every day.

<< 1 2 3 4 5 6 7 8 9 10 >>
my pharo image|about me|good books|popular posts|atom|rss