how to remove '/seaside/someApp'

Hi,

I have a little problem. How do I remove '/seaside/someApp'  such that I could have: 'http://someDomain.com/' instead of ' http://someDomain.com/seaside/someApp'. Help anyone?

Ching

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/7/19, Ching de la Serna <[hidden email]>:
> Hi,
>
> I have a little problem. How do I remove '/seaside/someApp'  such that I
> could have: 'http://someDomain.com/' instead of '
> http://someDomain.com/seaside/someApp'. Help anyone?

The short answer is you can't. The long answer is if you run behind
Apache 2 (which is a good idea) you can use mod_rewrite to hide it.

A quick googling turned out the following:
http://onsmalltalk.com/programming/smalltalk/running-seaside-apache-and-iis-on-windowsxp/
http://osdir.com/ml/lang.smalltalk.smallwiki/2006-03/msg00017.html

You'll have to adapt it to your situation. There were also examples
posted for lighty.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Thanks Philippe,

Alas, Apache mod_rewrite is too strong for my taste. I have a small proxy server at my front end but I'd hate to get my hands dirty on something I dont fully understand so, I'm looking for something from Seaside and luckily,
David Shaffer shared this method with me and when I tried it a while ago, it has worked for me.

WADispatcher default setName: ''.
WADispatcher default defaultName: 'yourApp'

You need 2.7 for this to work.

I now have another problem which is regarding photos (*.jpg). I have a few photos rendering nicely but new additions have failed to render at all. I wonder if you know of a fix for this.

Cheers,

Ching



_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Philippe Marschall a écrit : Whether I prefer using Apache, I once twicked/hacked the WADispatcher to
remove '/seaside/' from the path...
WADispatcher default setName: ''    this work for 2.8... [1] but
probably not to use...

So I'm wondering for a long time if there a (technical) reason for
adding such a path (and seaside/go/ in vw) ?... just out of curiosity...
Is it to make different web services lives together ?



Thanks

Cédrick

[1] :  I did accept the following code to modify the existing instances
of Dispatcher, but don't really know if useful (I think my problem was
related to Pier). Pier will raise a dispatcher error (just skip the test
and it works fine).
| origin |
WADispatcher allInstancesDo: [:ea | ea parent ifNil: [ea setName: ''.
origin := ea] ifNotNil: [ea setParent: origin ]].

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> So I'm wondering for a long time if there a (technical)
> reason for adding such a path (and seaside/go/ in vw) ?...
> just out of curiosity...

This is (was) for a technical reason.

When Seaside is integrated to VW via WebToolkit, we have to
play by WebToolkit rules.

In <a href="http://host:port/seaside/go/app">http://host:port/seaside/go/app, "seaside" represents
the "seaside" site, "go" is a "logical" that represents
the SeasideServlet and "app" represents the Seaside
application. With this construct, it is possible to serve
static files with urls like
<a href="http://host:port/seaside/folder/file.name">http://host:port/seaside/folder/file.name where the static
files belongs to the same site as the Seaside application.

If you load the SeasideShortPath parcel on top of
SeasideForWebToolkit, then urls like <a href="http://host:port/app">http://host:port/app 
are transparently processedas <a href="http://host:port/seaside/go/app">http://host:port/seaside/go/app,
unless "app" happens to be the name of a WebToolkit site.

In Seaside 2.7, following a suggestion that was made on
vwnc by Mark Roberts, there is a new option where you can
hook Seaside to the default WebToolkit site rather than
its dedicated named "seaside" site.
See the vwnc thread
http://www.parcplace.net/list/vwnc-archive/0702/msg00195.html 
http://www.parcplace.net/list/vwnc-archive/0702/msg00200.html

You can select this option in the dialog that pops up while
loading Seaside. If you do so, then in
<a href="http://host:port/seaside/app">http://host:port/seaside/app, "seaside" represents the
SeasideServlet and "app" represents the Seaside application.
As a result VW urls are similar to Squeak urls. With this
setup, you can still use the SeasideShortPath parcel to
reduce the urls further.

HTH,
Michel.




_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Fri, Jul 20, 2007 at 11:09:50AM +0200, [hidden email] wrote:
If you're behind a router/firewall you can hide it there so you only
have the /seaside/someApp internally.

Stephan
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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?

Cheers,
Michael

Stephan Eggermont wrote:
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

It appears that in seaside 2.8 config, the header style has been used to
display the logo. However the walkback borrows this stylesheet creating
some interesting effects if a component displays a walkback and the
other components have header level1 items displayed.

Keith
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/7/20, Michael Lucas-Smith <[hidden email]>:
> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>>
>> If we change this - will anyone have a problem?
>
> You mean besides updating all the tutorials ever written and all the
> server configurations?
>
... Right. Besides the Sanitation, medicine, education, wine, public
order, irrigation, roads, a fresh water system, public health, what has
the /seaside/ url path part ever done for us?

Michael
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Michael Lucas-Smith wrote: More seriously though - if the answer is to stick apache in front and
write rewrite rules - surely you can see that's a bit of a barrier to
deployment. Especially when you can just set the root to be '' and move
along. It may as well start like that.

Michael
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/7/20, Michael Lucas-Smith <[hidden email]>:
Kinda depends who is your target. For anything serious or commercial
is setting up and Apache a really an issue? Srsly?

The more serious deployment barrier I see is how do you deploy static
resources like images and pictures? How do you manage dependencies?
How do you continuously integrate?

Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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 ] ].


?  Looks quite easy to change to me.

Philippe Marschall wrote: _______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Jason Johnson wrote: 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
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Michael Lucas-Smith wrote:
But we are talking about deploying a production application here, no?  
In that case the person is going to need to know how their system
works.  But yes, the web servers themselves should provide a
configuration web page in a standard location for setting this sort of
thing up.


But the thing is, they will probably want *something*, and as soon as
you want that you are talking about configuration.  But again, I point
back to the fact that if you are deploying then someone has to know how
to deploy with your chosen web server, whether that be Apache,
Webtoolkit, Commanche, whatever.  And knowing how to rewrite URLs is
part of knowing your deployment.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> But the thing is, they will probably want *something*, and as soon as
> you want that you are talking about configuration.  But again, I point
> back to the fact that if you are deploying then someone has to know
> how to deploy with your chosen web server, whether that be Apache,
> Webtoolkit, Commanche, whatever.  And knowing how to rewrite URLs is
> part of knowing your deployment.
That's a fair argument. I still think you'll turn away some pedants by
having the URL there in the default image, but it is a nice advert. I'll
just note it as something to be document for VisualWorks.

Michael
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Michael Lucas-Smith wrote:
Does Swazoo run on all platforms?  If so, then maybe the plan should
just be to create all the tutorials to work with Swazoo and basically
adopt it as the platform of choice for Seaside.  It seems like everyone
has expectations that the "Seaside Solution" contain a web server [1]
anyway, so this might be the approach of least pain. :)

[1] And this is, of course, reasonable.  I had just thought that it was
also reasonable to say that Seaside is a "module" to your web server of
choice and you will need to consult your servers documentation on how to
set it up.  How does Rails handle this?
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Michael Lucas-Smith wrote:
Actually you "in the default image" gave me an idea.  Can't the people
making the packages for the various platforms have the install pop up a
box asking where the user wants the URL?  In fact, doesn't it already on
Squeak?
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Jason Johnson wrote:

> Does Swazoo run on all platforms?  If so, then maybe the plan should
> just be to create all the tutorials to work with Swazoo and basically
> adopt it as the platform of choice for Seaside.  It seems like everyone
> has expectations that the "Seaside Solution" contain a web server [1]
> anyway, so this might be the approach of least pain. :)

Swazoo currently runs on Squeak, VW, Dolphin and it will soon on ST/X.
It could soon also on VA Smalltalk (Sport port is on the way). Is there
any more dialect to port Swazoo on?

It is also a goal of forthcoming Swazoo 2.0 to be as same as possible on
all supported dialects and for sure on API level.

Swazoo is therefore definitively a right choice for all portable web
frameworks.

Best regards
Janko

> [1] And this is, of course, reasonable.  I had just thought that it was
> also reasonable to say that Seaside is a "module" to your web server of
> choice and you will need to consult your servers documentation on how to
> set it up.  How does Rails handle this?
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi All,

I actually was able to do this but only through a major hack!  (on 2.7 also)

I subclassed

WADispatcher to override #default
WAFileHandler to override #registerAsHandler:
WAFileLibrary to override #urlOf:
WAKom to override #default

Then
Changed WALibrary #urlOf: to use new subclass.

I was considering refactoring all this to make this easier for others but
havn't had time yet.  It would be nice to have.

The path really should be read from the path of the dispatcher instead since
the dispatcher appears capable of supporting multiple root paths.

Happy Coding!!

Ron Teitelbaum
President / Principal Software Engineer
US Medical Record Specialists
www.USMedRec.com

________________________________________
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Ching de la
Serna
Sent: Friday, July 20, 2007 3:50 AM
To: Seaside - general discussion
Subject: Re: [Seaside] how to remove '/seaside/someApp'

Thanks Philippe,

Alas, Apache mod_rewrite is too strong for my taste. I have a small proxy
server at my front end but I'd hate to get my hands dirty on something I
dont fully understand so, I'm looking for something from Seaside and
luckily,
David Shaffer shared this method with me and when I tried it a while ago, it
has worked for me.

WADispatcher default setName: ''.
WADispatcher default defaultName: 'yourApp'

You need 2.7 for this to work.

I now have another problem which is regarding photos (*.jpg). I have a few
photos rendering nicely but new additions have failed to render at all. I
wonder if you know of a fix for this.

Cheers,

Ching
On 7/20/07, Philippe Marschall <[hidden email]> wrote:
2007/7/19, Ching de la Serna <[hidden email] >:
> Hi,
>
> I have a little problem. How do I remove '/seaside/someApp'  such that I
> could have: 'http://someDomain.com/' instead of '
> http://someDomain.com/seaside/someApp'. Help anyone?

The short answer is you can't. The long answer is if you run behind
Apache 2 (which is a good idea) you can use mod_rewrite to hide it.

A quick googling turned out the following:
http://onsmalltalk.com/programming/smalltalk/running-seaside-apache-and-iis-
on-windowsxp/
http://osdir.com/ml/lang.smalltalk.smallwiki/2006-03/msg00017.html

You'll have to adapt it to your situation. There were also examples
posted for lighty.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside