Some things I learned working with Seaside

Hi,

Here are some things I learned working with Seaside.  I don't consider myself an expert in Seaside or HTML or CSS but here are a few things that I learned working with Seaside that may be of interest to others.

Move as much of the style defining things (color, size, spacing, etc.) out of Seaside and the HTML code it generates, into CSS (Cascading Style Sheet) files as you can.  This is done by specifying a class (class:) for everything you want to set style settings for and then defining the CSS class in your CSS file.  This allows you to make changes to how things look without modifying code and re-packaging.

Define your CSS classes in a pool dictionary via a PRAGMA.  This puts them all in one place and you don't have a lot of strings all over your code, that are harder to track down.  Also, VA Smalltalk's source coloring makes the pool values look better than strings.  I have a workspace script that links these CSS classes and the component they are used in that I will share if anyone is interested.

I also found it useful to put HTML element ids in a pool dictionary.  This makes it easier to use them in any JavaScript code you may be generating.

Back to CSS classes.  Try not to use the HTML #space or #space: to create space between things.  Use a CSS class with margin-left: and friends or what ever you like to space things.  

I'm using "pt" for the units in my CSS classes.  I'm open to someone who knows more about CSSs than I do to correct me on this but it seems better to define web pages in terms of "points" (1 pt is the same as 1/72 inch).  I think this gives a more consistent result across varying monitor resolutions and if you want to go from your HTML to PDF (more about that later).

Try not to use the HTML #break too much as in multiple times in a row.  It is hard to eliminate them all together but two (or more) in a row can be reduced to one break and margin-top: in a CSS class.

Use the Seaside #cancelButton.  HTML doesn't have a cancel button but Seaside does.  It is really a submit button with a special callback, that gets processed before all the callbacks that copy the values from the web page into your objects and then prevents that coping.  In this way you can connect live objects (without copying them) to a web page without fear of them being changed when the user click cancel.  Copying the objects may be a little safer but requires a lot more work when you want to copy the changed values back to the original object.  I have also extended Seaside a little to handle the case where you want to cancel an action when the user clicked submit but things have changed on the server and you don't want the changes applied.  It is more involved than I want to go into here but I will share if anyone is interested.

If you have a need to create PDF files, take a look at wkhtmltopdf. It is a program that creates PDF files from an HTML file (and the CSS files it points to). It can be found here: http://code.google.com/p/wkhtmltopdf/. I think it is based on Safari.  There are Windows and Linux versions.  I have it working on both.

I have reports that are viewed from the Seaside web app and can be downloaded as PDF files.  I run through the same Seaside code that creates the report for the web page but with an additional printer friendly CSS file that shrinks logos, page width and such.  The result is diverted from going to the web browser to a file.  Then wkhtmltopdf is run on the html file, creating a PDF file.  I then read in the PDF file and download it to the web browser.

Let Apache (or equivalent) handle normal file downloads, like images and CSS files.  Dynamically generated files, like the PDF files above, are better handled by Seaside.  Apache is much easier to setup with Seaside than IIS, so use Apache if you can.  Consider this a loose rule of thumb.

I think this is enough for now.  Questions are welcome.

Lou