[Seaside] Re: What's the (technical) purpose of adding t/seaside/
to the path
Michael Lucas-Smith
mlucas-smith at cincom.com
Fri Jul 20 12:49:10 UTC 2007
Jason Johnson wrote:
> I think I'm a little confused here. /seaside is only in the path
> because that's the location you configured Seaside to live on the web
> server no? If you want it somewhere else can't you just do something
> like:
>
> ma := ModuleAssembly core.
> seaside := WAKom default.
> ma alias: '/my/other/location' to: [ma addPlug: [:request | seaside
> process: request ] ].
>
It's different for every web server - WebToolKit, Swazoo, Kom,
Opentalk-HTTP, Whatever Dolphin has. So it's kinda hard to write a
tutorial for it that covers all the Seaside versions out there.
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.
>
> 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.
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
>
> ? Looks quite easy to change to me.
>
> Philippe Marschall wrote:
>> 2007/7/20, Michael Lucas-Smith <mlucas-smith at cincom.com>:
>>> Is the general consensus that people would rather the /seaside/ wasn't
>>> part of the default URL?
>>>
>>> If we change this - will anyone have a problem?
>>
>> You mean besides updating all the tutorials ever written and all the
>> server configurations?
>>
>> Philippe
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
More information about the Seaside
mailing list