[Seaside] state of the aubergine

[Nevin Pratt]

Avi Bryant wrote:

>Since there's not a huge amount of activity on this list, it's somewhat
>hard to gauge just what's going on out there, seaside-wise.  So I thought
>I'd throw some questions out that might help me figure out, as I amass
>little bits of time here and there to work on this stuff, what I should be
>doing.
>
>First of all, how many of you are actively using Seaside?  There are 35 or
>so people on this list, but Kamil and Alain are the only ones that I know
>have gone much further than looking through the tutorials.  It would be
>good to have a better idea of where you guys are at, how interested you
>are, what's holding you back from using it more, etc.
>

Well, maybe I'll talk a bit about what I have so far.  First, I am using 
Squeak to serve my site: http://www.smalltalkpro.com.  Now, I'll admit 
that most of the rhetoric on my site is specifically addressed as a 
propoganda piece for the employees at my current gig (a *cough* Java 
gig).  In other words, I don't really talk about Smalltalk or Squeak at 
my current gig-- I just point people to my site.  I update my site to 
suit the conversations that are taking place at work.  So, it is just a 
propoganda piece-- what I call a part of my "propoganda machine", whose 
propoganda is specifically tailored to my current (*cough*) Java gig.

As a propoganda machine, it is important to be able to showcase a 
*Smalltalk only* solution (with the exception of the html generation). 
 Thus, I won't tolerate Apache, Tomcat, or anything else.  It must be 
Squeak *only*-- otherwise it loses it's propoganda effect.

As a propoganda piece, it is also important to be able to separate the 
work done by a Graphics Designer from the work done by a Smalltalk 
Programmer.  Furthermore, the Graphics Designer needs to be able to use 
any tool of his/her choice (Dreamweaver, FrontPage, or whatever), and 
the Programmer can take the html created from that tool and wire it to 
the backend.  This is an *absolute* unnegotiable requirement at my Java 
gig, and thus it will also be an *absolute* unnegotiable requirement for 
my Smalltalk propoganda machine.

My wife's site (http://www.bountifulbaby.com) is also being served by 
the same server as my site.  Besides it being a good sideline business 
for her, it is also actually part of my propoganda machine.  At my 
current (cough) Java gig, they have several people working on an online 
catalog ordering system.  My wife's site is also going to be expanded 
into roughly the same kind of catalog ordering system we are doing at 
work. The goal is to stay slightly ahead (functionality-wise) of what 
they have developed at work.  And, do it with a 12 year old boy (my son 
Adam) working on it part time after school (but with my guidance).

If Adam can work part-time, and yet produce more functionality that they 
have at any given time on the project at work (thus keeping ahead of the 
expensive "professional Java team" at work), it will have a "slam-dunk" 
effect on the project at work when management gets wind of it.

That's what I am doing, and so far it is working.  And, it is already 
beginning to stir some interest at work.  And, I'm enjoying the effect 
immensely.  It is a source of pride for me watching it actually happen.

OK, from this description, there are a number of things that become evident.

First, we *have* to be able to support virtual hosts (the gig at work 
likewise does).  Thus, if you check the IP for "smalltalkpro.com" as 
well as "bountifulbaby.com", you will see they both point to the same 
machine--my server machine.  The squeak server therefore must be able to 
synthesize a different "document Root" based on the incoming URL.  This 
is how I've done that:

docRootForRequest: aRequest 
	"For virtual domain support, we need to map a host to a local directory.  
	This is how. There are numerous other ways this could have been done, 
	but doing it this way means I don't have to update the map when I add 
	another host. All I have to do is make sure the appropriate directory  
	exists in '/home' (smalltalkpro, bountifulbaby, or whatever  
	matches the host portion of the URL just before the .com or .org), plus  
	make sure that directory has an htdocs directory."
	| tok domainDir |
	tok _ aRequest host findTokens: '.'.
	domainDir _ tok size > 1
				ifTrue: [tok at: tok size - 1]
				ifFalse: [tok at: tok size].
	^ '/home/' , domainDir , '/htdocs'


I am using a Comanche/Seaside interface very similar to IAKom, and thus 
the #process: method knows the request argument, which in turn is passed 
into the method above.  In this way, a web URL of, say, 
http://www.smalltalkpro.com will result in a document root of 
"/home/smalltalkpro/htdocs", and a web URL of 
http://www.bountifulbaby.com will result in a document root of 
"/home/bountifulbaby/htdocs".

Now on to the next thing:

I absolutely *must* be able to support allowing a Graphics Design person 
to use Dreamweaver to generate the html pages.  If I don't do this, I 
lose a big chunk of my propoganda machine, because that is the strategy 
they are using at work.  Fortunately, my son knows (and likes) 
Dreamweaver.  Thus, all of the bountifulbaby.com pages were created with 
Dreamweaver.  However, the requirement of using Dreamweaver for the html 
code severely limits my ability to use the html templating scheme that 
Seaside uses.

Now look at the "Past Work" page at: 
http://www.bountifulbaby.com/pastwork.ssp.  This page was originally a 
"pastwork.html" static page created via Dreamweaver, but it is now a 
dynamic page that looks in a "pastwork" directory (under the doc root) 
for any jpg images in that directory, and serves those images.  It gives 
each picture the baby name of the jpg filename that it found.  Thus, to 
add to the list of babies on this page, all that Adam (or my wife, 
Denise) must do is drop the picture in the "pastwork" directory, and it 
is automatically served on this page.

OK, but how exactly was that done?

Our "IAKom" class (well, actually we've called it something else, and 
left the original IAKom intact) has the following #process: method:

process: aRequest 
	"This is the required Comanche method that kicks everything off.  
	Nothing else works until this method is properly run, and it will  
	automatically be run by Comanche."
	| str |
	str _ self processStaticPage: aRequest.
	str notNil
		ifTrue: [^ str].
	^ self processSeasidePage: aRequest

The #processSeasidePage: is essentially the same as the original IAKom 
#process: method, but with a minor mod where we hardwired it to the 
"seaside" URL.  Look at, for example, 
http://www.bountifulbaby.com/seaside/calc to see it in action, or any of 
the other example Seaside apps (minesweeper, whatever).  You'll see 'em 
work.

But for the SSP side of things, the relevant portion of 
#processStaticPage: that handles the SSP stuff is this:

(file name endsWith: 'ssp')
		ifTrue: [str _ HTMLformatter evalEmbedded: file contents with: httpRequest]
		ifFalse: [str _ file contents]

Notice in this code snippet that the file being served by our custom 
"IAKom " (in the #processStaticPage: method) is checked to see if it 
ends in "ssp", and if it does, it passes it to the HTMLformatter (the 
same one that PWS uses for SSP) to process the SSP code.

Thus, to make the "pastwork.ssp" page work, Adam stripped out the html 
from his Dreamweaver code that generated the pictures, and replaced it 
with a single SSP call to a method we wrote together that walked the 
"pastwork" directory as described.  We in turn stole his html from the 
original "pastwork.html" page and used it as a "guide" for the new 
method, so it's not like his original html was wasted work.

OK, so far, so good.  But, there's no real Seaside involvement yet 
(besides the standard example Seaside apps that nobody really knows 
about that visits the site).  So, what's next?  I want to use Seaside, 
but you can see we haven't really used it yet.  But I plan to as we move 
forward.

One thing we need is a clean way to grab modified Dreamweaver html and 
use it in a Seaside app.  Some minor manual modifications (edits) to the 
html are OK, but we need to keep the required editing down to a minimum. 
 If we have to extensively hack the Dreamweaver html to make it work, we 
lose our propoganda effect.

Yes, I realize I can use IAFileTemplate to have a file-based template, 
and have it load in the Dreamweaver html, and this is actually a good 
start.  But, one of the immediate problems hit is how to serve the 
static content found in the Dreamweaver html-- JPG and GIF images, for 
example.  We don't want to have to code an absolute path for these 
static images.  Absolute paths suck-- what if you want to host the site 
somewhere else?  This limitation would also be jumped on by the hounds 
at work.

We also don't want to have to write a bunch of bogus action methods in 
our Seaside IAApplication subclass to serve the images dynamically.  We 
need true static content serving from a standard Dreamweaver html file 
well-integrated into a Seaside app.  This bugs me.

What I am thinking of doing right now is intercepting the static file 
requests in our "IAKom" class, and munging the path to remove the 
"/seaside/app/5/top/1/view" stuff from the URL so that our custom IAKom 
class can serve it before it gets to the Seaside app.  That way static 
resources (images and pictures) can be served before it gets to the 
Seaside side of things.  But I don't see a clean way of doing this when 
the Seaside app served the original html that referenced the static 
resources.  The only way I see (off hand) is by having my "IAKom" class 
detect the static resource in the URL, and then munge the URL to make it 
look purely static for Comanche.

But then, I'm not exactly a world-class pro with Squeak, Comanche, or 
Seaside right now, so we're both learning the tools.  I'm primarily a 
VisualWorks person.  The reason for grabbing these tools was also part 
of my propoganda machine-- the gig I'm at now thinks they want a purely 
open-source solution, without tying to any vendor, and they haven't 
figured out yet that Java is not open source and ties them squarely to 
Sun.  That's actually addressed by my propoganda machine via the 
rhetoric at the bottom of my home page at: http://www.smalltalkpro.com. 
 Management at my current gig has made a big-deal about not tying to any 
vendor, and yet simultaneously selected Java to develop with.  They 
don't realize what they've done (how those two statements are so 
mutually exclusive), but when they do realize it, I want a strong 
example available using purely open source tools.  It's all part of the 
propoganda machine.

And, my wife is actually making money with her site, too.  So, no matter 
what the outcome of the propoganda machine, it's still a win for us. 
 And, as a propoganda machine, we are further along (i.e., we have more 
functionality) than the Java team has at work.  And, I'm confident we 
can keep it that way.

Anyway, you can see what we are up to.  Any suggestions along these 
lines, to help fascilitate our goals, would surely be considered, and 
appreciated.

Nevin