[Seaside] Re: What's the (technical) purpose of adding t/seaside/to the path

[Sebastian Sastre]

> It's also a kind of random piece of voodoo for a beginner 
> coming on to the scene don't you think?
> > Kinda depends who is your target. For anything serious or 
> commercial 
> > is setting up and Apache a really an issue? Srsly?
> Well I know Cincom customers punished the previous web team 
> enough that they have a whole mapping and aliasing engine 
> built in to WebToolKit for exactly these issues - I agree, 
> using Apache is a nice way to avoid having to write the code 
> yourself, although not having to write it in the first place 
> is even better.
> >
I can barely imagine an integer large enough to represent the number of
times I prefer to develop that code in ST rather in Apache's configuration
files, rewrite rules and those friends. So.. after almost all day
configuring some rules for some apps I disagree with being that a desirable
thing to have, simultaneously I agree that would be wonderfully time saving
for seasiders not even have to write it in first place.

> > The more serious deployment barrier I see is how do you 
> deploy static 
> > resources like images and pictures?
> We set up a Resource class that had a base URL that was 
> pointing to Apache - in that respect, the Seaside program was 
> never mounted on a URL that it wasn't going to be on (except 
> for host:port) and the images could move around with a 
> Configuration parameter. It also meant that we could do what 
> Boris does - use resources in-image and then move them off to 
> another server when we deploy.
> > How do you manage dependencies?
> It's all Smalltalk code so the flick of a seaside 
> configuration variable is no biggy.
> > How do you continuously integrate? 
> Same as you always do.
> 
If you 1) freely develop your app asimilating anytime by evaluating 

	XXLibrary refreshResources

(that if you have the files under imagePath/XXLibrary) to develop with
guaranteed fresh versions of files, until you 2) want to deploy and let the
image to tell you wich files in which dir structure the app will expect by
evaluating:
 
	(WADispatcher default entryPointAt: 'applicationName') deployFiles
	
and 3) you copy the tree found at imagePath/files to the proper location,
then you only need some tuned rewrite rules to make apache preceed the
seaside image to serve them (in exactly the same version but slower).

I make this to be less error prone at deployment. Comparisions become
irrelevant syncrhonization instantaneously archieved (if files correctly
placed).

> I think the /seaside URL is a bit of a perception problem for 
> new users coming in. They expect to have control of the URL 
> mapping space - in fact, it looks pretty good when you see 
> that you can register your class with a name and that the URL 
> to invoke your application is that URL - except for this 
> /seaside thing on the front.
> 
> I like the advertising it gives the project - but I can't see 
> anyone wanting to ever deploy with /seaside in their URL for 
> a real app - which means just about everyone is going to want 
> to remap it or reconfigure it to not have it. So.. my 
> thoughts still point toward not having it in the first place 
> to remove the issue completely.
> 
> Michael
> >

I wanted to add that the /seaside/ issue adds no value to any project but
seaside itself. And sadly is kind of pain to take it out. We love/need
seaside so we most probably put a "powered by seaside" or some other
branding stuff like that (beside support/bugfixes/etc) which IMHO has a lot
more sense than a piece of anti-minimalistic URL.

My 2c

Sebastian
PS: sorry to spam you with another version. It's a little late arround here
to be working but I think this deserved documentation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DF-sas.3.mcz
Type: application/octet-stream
Size: 3290 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/seaside/attachments/20070813/c48b2278/DF-sas.3.obj