Smalltalk › Frameworks & Tools › Seaside › Seaside General

how to remove '/seaside/someApp'

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

37 messages Options

Jason Johnson-3

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

Janko Mivšek wrote:

> 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

Cool. Can it do all the things Commache can? I come from an Apache
background, so the aliasing, installing modules to handle parts of the
URL and add functionality, etc. make sense to me. How does Swazoo
handle things like this [1]? When you announced it before I went and
tried to figure it out from the documentation, but I wasn't able to find
out.

Thanks,
Jason

[1] Some use cases:

I want to install Seaside at the location: /seaside, and another
framework at the location /notseaside
I want / to refer to a specific directory I specify and serve the files
there and all subdirectories of it, except /myapp which should be
forwarded to my Pier site (note: if there was a directory myapp under my
specific directory it can't be accessed from the web server anymore
since Pier is there)
I want / to refer to a specific directory on my server, but /images
should be an alias that actually internally forwards to
http://some.server.com/resources/images
I want to write a module (if the functionality isn't there already) to
allow me to password protect some links under my site

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

Janko Mivšek

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

Hi Jason,

Jason Johnson wrote:

> Janko Mivšek wrote:
>> 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.
>
> Cool. Can it do all the things Commache can? I come from an Apache
> background, so the aliasing, installing modules to handle parts of the
> URL and add functionality, etc. make sense to me. How does Swazoo
> handle things like this [1]? When you announced it before I went and
> tried to figure it out from the documentation, but I wasn't able to find
> out.

Well, it doesn't have everything as Apache have, but goal of Swazoo is
to stay simple and to delegate more demanding tasks to web frameworks.

Swazoo can serve one or many websites (virtual serving), each site have
its hostname and can have aliases. About docs, yes, lacking, I know. I
hope that with increased interest I would easily put together at least a
FAQ. Maybe someone else is willing to help here?

> [1] Some use cases:
>
> I want to install Seaside at the location: /seaside, and another
> framework at the location /notseaside

VW Seaside on Swazoo is already implemented that way. You have a
SeasideSite to which a hierarchy of resources is added. Each such
resource has an uriPattern. The last one is SeasideResource.

UriPattern determines part of url this resource resolves. For instance,
for default url of VW Seaside:

http://localhost:8008/seaside/go/browse

you have following resource hierarchy and uri patterns:

SeasideSite localhost:8008
CompositeResource '/'
CompositeResource 'seaside'
SeasideResource 'go'

You can therefore easily add your own resource wherever you want in that
hierarchy. Not to mention that you can run a site with one framework and
another site with other one. For instance, it is already possible to run
Seaside and Aida/Web together on the same Swazoo server.

> I want / to refer to a specific directory I specify and serve the files
> there and all subdirectories of it, except /myapp which should be
> forwarded to my Pier site (note: if there was a directory myapp under my
> specific directory it can't be accessed from the web server anymore
> since Pier is there)

This is maybe already possible with correct order of Resources
(urlPattern search is ordered), otherwise it can be added easily.

> I want / to refer to a specific directory on my server, but /images
> should be an alias that actually internally forwards to
> http://some.server.com/resources/images

Same as above.

> I want to write a module (if the functionality isn't there already) to
> allow me to password protect some links under my site

We had a big debate back in 2000 when developing Swazoo, how to do that.
And we were too much apart to agree with a common solution of security
and session management in Swazoo. There were some tries to have a
wrapper resource for that but that is depreciated currently. It seems
that best way is that web frameworks deal with security, because they
know much more about it than Swazoo alone.

I hope I answered you a bit your questions

Best regards
Janko

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

Ramon Leon-5

RE: how to remove '/seaside/someApp'

In reply to this post by Philippe Marschall

> 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-a
> pache-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

As well as

http://onsmalltalk.com/programming/smalltalk/scaling-seaside-redux-enter-the
-penguin/

Where a linux solution is presented.

Ramon Leon
http://onsmalltalk.com

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

Carl Gundel

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

In reply to this post by Michael Lucas-Smith-3

For this Boris pointed me at the SeasideShortPath parcel that comes with VW.
My paths went from http://mydomain.com/seaside/go/myapp to
http://mydomain.com/myapp. Much better. However I do agree that it should
not require a patch. It should be easy to configure out of the box and easy
to reconfigure when the need arises.

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com

----- Original Message -----
From: "Michael Lucas-Smith" <[hidden email]>
To: "Seaside - general discussion" <[hidden email]>
Sent: Friday, July 20, 2007 9:05 AM
Subject: Re: [Seaside] Re: What's the (technical) purpose of adding
t/seaside/to the path

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

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

Blake-5

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

In reply to this post by Michael Lucas-Smith-3

On Fri, 20 Jul 2007 05:22:17 -0700, Michael Lucas-Smith
<[hidden email]> wrote:

>
>>>
>>> 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?

Brought peace?

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

Philippe Marschall

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

In reply to this post by Michael Lucas-Smith-3

2007/7/20, Michael Lucas-Smith <[hidden email]>:

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

Yeah right. I'll tell that to the next person who wants to load
PierBlog and tries to figure out what version of Pier, Magritte,
Seaside, RSRSS and whatever libraries else she needs and where to get
all this stuff if she wants to run on Seaside 2.7.

> > How do you continuously integrate?
> Same as you always do.

So between how many open source continuous integration servers, that
automatically build images, run tests and send out notifications can I
exactly choose? That build minimal production images and development
images with all the browser enhancements continuously? How do I
automatically deploy code to multiple servers (no, opening an
X-session and hitting in load for every image is not a solution)?

Philippe

> 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 <[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
>
> _______________________________________________
> 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

ching

Re: how to remove '/seaside/someApp'

In reply to this post by Ramon Leon-5

Thanks all,

I did read those posts and I think I will have to read and reread those as I think that those posts point to directions that I could take. I am especially interested in strategies for scaling seaside.

Cheers,

Ching

On 7/21/07, Ramon Leon <[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-a
> pache-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

As well as

http://onsmalltalk.com/programming/smalltalk/scaling-seaside-redux-enter-the
-penguin/

Where a linux solution is presented.

Ramon Leon
http://onsmalltalk.com

_______________________________________________
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

Jason Johnson-3

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

In reply to this post by Janko Mivšek

Janko Mivšek wrote:
> Well, it doesn't have everything as Apache have, but goal of Swazoo is
> to stay simple and to delegate more demanding tasks to web frameworks.

I think that is a big part of the goal of Apache as well actually.

> Swazoo can serve one or many websites (virtual serving), each site
> have its hostname and can have aliases. About docs, yes, lacking, I
> know. I hope that with increased interest I would easily put together
> at least a FAQ. Maybe someone else is willing to help here?

I wasn't trying to beat you up about Documentation. In fact I wasn't
even implying that it wasn't there. Just that I was not able to find
it, which could have been my own fault.

> VW Seaside on Swazoo is already implemented that way. You have a
> SeasideSite to which a hierarchy of resources is added. Each such
> resource has an uriPattern. The last one is SeasideResource.
>
> UriPattern determines part of url this resource resolves. For
> instance, for default url of VW Seaside:
>
> http://localhost:8008/seaside/go/browse
>
> you have following resource hierarchy and uri patterns:
>
> SeasideSite localhost:8008
> CompositeResource '/'
> CompositeResource 'seaside'
> SeasideResource 'go'
>
> You can therefore easily add your own resource wherever you want in
> that hierarchy. Not to mention that you can run a site with one
> framework and another site with other one. For instance, it is already
> possible to run Seaside and Aida/Web together on the same Swazoo server.

Cool. Is it documented anywhere how to set these up and what kinds of
arguments they can take?

>> I want to write a module (if the functionality isn't there already)
>> to allow me to password protect some links under my site
>
> We had a big debate back in 2000 when developing Swazoo, how to do
> that. And we were too much apart to agree with a common solution of
> security and session management in Swazoo. There were some tries to
> have a wrapper resource for that but that is depreciated currently. It
> seems that best way is that web frameworks deal with security, because
> they know much more about it than Swazoo alone.

Well, what I would say here is, I don't think your goal should be just
to support frame works. I would like to see Squeak/Smalltalk in general
have it's own web server that people would be interested in serving
their sites in, like Erlang has. That doesn't mean Swazoo needs to
support everything, but Apache doesn't either. It gains it's power by
allowing modules to control the various stages of serving resources.
Security is just a module in Apache, and you can put in anything you
want in there. I think that would be a good approach for Swazoo as
well. I don't expect Swazoo to handle it, but it should be possible for
someone to make a module that does handle it the way they think best.
In my opinion anyway. :)

> I hope I answered you a bit your questions
>
> Best regards
> Janko

Of course. Thanks for taking the time to answer.

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

Jason Johnson-3

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

In reply to this post by Philippe Marschall

Philippe Marschall wrote:
> Yeah right. I'll tell that to the next person who wants to load
> PierBlog and tries to figure out what version of Pier, Magritte,
> Seaside, RSRSS and whatever libraries else she needs and where to get
> all this stuff if she wants to run on Seaside 2.7.

Hrm, if I am not mistaken, I believe you can literally tell them to
download Damien's web-dev 3.9 (and that part is important I think)
image, open the Universe browser and select PierBlog -> install and it
should get everything.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

ching

Re: What's the (technical) purpose of adding t/seaside/ to the path (was: Re: how to remove '/seaside/someApp')

In reply to this post by Stephan Eggermont-3

I suppose this might depend on the router that you have. On my router, I only set port forwarding to redirect port 80 to my proxy server. There are firewall settings which I don't think is relevant to the problem at hand. I do not see anywhere I can append '/seaside/myApp' so that my proxy will do the right re-direction. A problem might arise when I have another application that uses the same router and backend servers. Would I be able to do stuff on the router side to get the same results?

Ching

On 7/20/07, Stephan Eggermont <[hidden email]> wrote:

On Fri, Jul 20, 2007 at 11:09:50AM +0200, [hidden email] wrote:

> From: "Philippe Marschall" <[hidden email]>
> 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.

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

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

Carl Gundel

Re: What's the (technical) purpose of adding t/seaside/ to the path(was: Re: how to remove '/seaside/someApp')

I host my site behind Apache, but not every developer wants or needs to use
Apache or any other front-end, and there's absolutely no good deployment
reason to not permit the developer to specify a short path. Let the
developer determine the requirement one way or the other. If adding this
capability involves difficult development work, well then that's a different
matter.

So while I do use Apache and URL rewriting for my public site, I have a need
for the short path option with a version of my Seaside based software which
I plan to distribute.

-Carl Gundel
http://www.runbasic.com

----- Original Message -----
From: "Ching de la Serna" <[hidden email]

>I suppose this might depend on the router that you have. On my router, I
> only set port forwarding to redirect port 80 to my proxy server. There
> are
> firewall settings which I don't think is relevant to the problem at hand.
> I
> do not see anywhere I can append '/seaside/myApp' so that my proxy will do
> the right re-direction. A problem might arise when I have another
> application that uses the same router and backend servers. Would I be able
> to do stuff on the router side to get the same results?
>
> Ching
>
> On 7/20/07, Stephan Eggermont <[hidden email]> wrote:
>>
>> On Fri, Jul 20, 2007 at 11:09:50AM +0200,
>> [hidden email] wrote:
>> > From: "Philippe Marschall" <[hidden email]>
>> > 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.
>>
>> 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
>>
>

--------------------------------------------------------------------------------

> _______________________________________________
> 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

Jason Johnson-3

Re: What's the (technical) purpose of adding t/seaside/ to the path(was: Re: how to remove '/seaside/someApp')

Again, Seaside is an application that is running under a web server. No
new functionality needs to be added to Seaside, you just need to
configure the web server that serves it to have what ever path you want.

NOTE: I am talking about your *smalltalk* web server, not apache or any
of that kind of stuff. Kommanche, Swazoo, something like that.

Carl Gundel wrote:

> I host my site behind Apache, but not every developer wants or needs
> to use Apache or any other front-end, and there's absolutely no good
> deployment reason to not permit the developer to specify a short
> path. Let the developer determine the requirement one way or the
> other. If adding this capability involves difficult development work,
> well then that's a different matter.
>
> So while I do use Apache and URL rewriting for my public site, I have
> a need for the short path option with a version of my Seaside based
> software which I plan to distribute.
>
> -Carl Gundel
> http://www.runbasic.com
>
> ----- Original Message ----- From: "Ching de la Serna"
> <[hidden email]
>> I suppose this might depend on the router that you have. On my router, I
>> only set port forwarding to redirect port 80 to my proxy server.
>> There are
>> firewall settings which I don't think is relevant to the problem at
>> hand. I
>> do not see anywhere I can append '/seaside/myApp' so that my proxy
>> will do
>> the right re-direction. A problem might arise when I have another
>> application that uses the same router and backend servers. Would I be
>> able
>> to do stuff on the router side to get the same results?
>>
>> Ching
>>
>> On 7/20/07, Stephan Eggermont <[hidden email]> wrote:
>>>
>>> On Fri, Jul 20, 2007 at 11:09:50AM +0200,
>>> [hidden email] wrote:
>>> > From: "Philippe Marschall" <[hidden email]>
>>> > 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.
>>>
>>> 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
>>>
>>
>
>
> --------------------------------------------------------------------------------
>
>
>
>> _______________________________________________
>> 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
>

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

Chris Cunnington-5

Parasol quarterly, issue 1.2 the Seaside database issue is now available

The second issue of Parasol quarterly is now available. The guest authors
and topics include:

Dale Henrichs -- GemStone's Free Seaside Database

James Robertson -- Cincom's Seaside Database Plans

Jon Hylands -- Homebuilt Smalltalk Robot

Tim Johnson -- Making Better Cocoa With Squeak

http://www.seasideparasol.com/store.html

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

Boris Popov, DeepCove Labs (SNN)

RE: Parasol quarterly, issue 1.2 - the Seaside database issue - is now available

Chris,

Don't get me wrong, this all sounds very interesting, but I don't know
if I'd shell out hard earned cash for something that is typically posted
online in form of a transcript or recorded podcast these days. Today's
expectations of free content are just so hard to get over, but I know
that time and effort goes into these things, so perhaps corporate STIC
members should look at sponsoring some independent journalism like this?

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: [hidden email] [mailto:seaside-
> [hidden email]] On Behalf Of Chris Cunnington
> Sent: Wednesday, July 25, 2007 10:27 AM
> To: Seaside - general discussion
> Subject: [Seaside] Parasol quarterly, issue 1.2 the Seaside database
> issue is now available
>
>
> The second issue of Parasol quarterly is now available. The guest

authors

> and topics include:
>
> Dale Henrichs -- GemStone's Free Seaside Database
>
> James Robertson -- Cincom's Seaside Database Plans
>
> Jon Hylands -- Homebuilt Smalltalk Robot
>
> Tim Johnson -- Making Better Cocoa With Squeak
>
> http://www.seasideparasol.com/store.html
>
> _______________________________________________
> 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

Sebastian Sastre-2

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

In reply to this post by Michael Lucas-Smith-3

> 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

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

DF-sas.3.mcz (4K) Download Attachment

Sebastian Sastre-2

RE: What's the (technical) purpose of adding t/seaside/ to thepath(was: Re: how to remove '/seaside/someApp')

In reply to this post by Carl Gundel

ONLY SQUEAK WITH COMANCHE:
here I sending the hack described by Ron Teitelbaum in 07/20/2007 in the
form of a monticello package.
Take it as what it is: a hack
I'm testing it myself, so I don't know anythig yet about to have it in
production

Cheers,

Sebastian Sastre

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de Carl Gundel
> Enviado el: Sábado, 21 de Julio de 2007 22:10
> Para: Seaside - general discussion
> Asunto: Re: What's the (technical) purpose of adding
> t/seaside/ to thepath(was: Re: [Seaside] how to remove
> '/seaside/someApp')
>
> I host my site behind Apache, but not every developer wants
> or needs to use Apache or any other front-end, and there's
> absolutely no good deployment reason to not permit the
> developer to specify a short path. Let the developer
> determine the requirement one way or the other. If adding
> this capability involves difficult development work, well
> then that's a different matter.
>
> So while I do use Apache and URL rewriting for my public
> site, I have a need for the short path option with a version
> of my Seaside based software which I plan to distribute.
>
> -Carl Gundel
> http://www.runbasic.com
>
> ----- Original Message -----
> From: "Ching de la Serna" <[hidden email]
> >I suppose this might depend on the router that you have. On
> my router,
> >I only set port forwarding to redirect port 80 to my proxy server.
> >There are firewall settings which I don't think is relevant to the
> >problem at hand.
> > I
> > do not see anywhere I can append '/seaside/myApp' so that my proxy
> >will do the right re-direction. A problem might arise when I have
> >another application that uses the same router and backend servers.
> >Would I be able to do stuff on the router side to get the
> same results?
> >
> > Ching
> >
> > On 7/20/07, Stephan Eggermont <[hidden email]> wrote:
> >>
> >> On Fri, Jul 20, 2007 at 11:09:50AM +0200,
> >> [hidden email] wrote:
> >> > From: "Philippe Marschall" <[hidden email]>
> >> > 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.
> >>
> >> 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
> >>
> >
>
>
> --------------------------------------------------------------
> ------------------
>
>
> > _______________________________________________
> > 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

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

SP-sas.2.mcz (1K) Download Attachment

Sebastian Sastre-2

RE: What's the (technical) purpose of adding t/seaside/ tothepath(was: Re: how to remove '/seaside/someApp')

Sorry about 2 mails for this but I've forgot to mention that it start to
work after you evaluate:

WADispatcher resetAll

cheers,

Sebastian Sastre

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de Sebastian Sastre
> Enviado el: Jueves, 16 de Agosto de 2007 16:47
> Para: 'Seaside - general discussion'
> Asunto: RE: What's the (technical) purpose of adding
> t/seaside/ tothepath(was: Re: [Seaside] how to remove
> '/seaside/someApp')
>
> ONLY SQUEAK WITH COMANCHE:
> here I sending the hack described by Ron Teitelbaum in
> 07/20/2007 in the form of a monticello package.
> Take it as what it is: a hack
> I'm testing it myself, so I don't know anythig yet about to
> have it in production
>
> Cheers,
>
> Sebastian Sastre
>
> > -----Mensaje original-----
> > De: [hidden email]
> > [mailto:[hidden email]] En
> nombre de Carl
> > Gundel Enviado el: Sábado, 21 de Julio de 2007 22:10
> > Para: Seaside - general discussion
> > Asunto: Re: What's the (technical) purpose of adding t/seaside/ to
> > thepath(was: Re: [Seaside] how to remove
> > '/seaside/someApp')
> >
> > I host my site behind Apache, but not every developer wants
> or needs
> > to use Apache or any other front-end, and there's
> absolutely no good
> > deployment reason to not permit the developer to specify a
> short path.
> > Let the developer determine the requirement one way or the
> other. If
> > adding this capability involves difficult development work,
> well then
> > that's a different matter.
> >
> > So while I do use Apache and URL rewriting for my public
> site, I have
> > a need for the short path option with a version of my Seaside based
> > software which I plan to distribute.
> >
> > -Carl Gundel
> > http://www.runbasic.com
> >
> > ----- Original Message -----
> > From: "Ching de la Serna" <[hidden email]
> > >I suppose this might depend on the router that you have. On
> > my router,
> > >I only set port forwarding to redirect port 80 to my
> proxy server.
> > >There are firewall settings which I don't think is
> relevant to the
> > >problem at hand.
> > > I
> > > do not see anywhere I can append '/seaside/myApp' so that
> my proxy
> > >will do the right re-direction. A problem might arise when I have
> > >another application that uses the same router and backend servers.
> > >Would I be able to do stuff on the router side to get the
> > same results?
> > >
> > > Ching
> > >
> > > On 7/20/07, Stephan Eggermont <[hidden email]> wrote:
> > >>
> > >> On Fri, Jul 20, 2007 at 11:09:50AM +0200,
> > >> [hidden email] wrote:
> > >> > From: "Philippe Marschall" <[hidden email]>
> > >> > 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.
> > >>
> > >> 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
> > >>
> > >
> >
> >
> > --------------------------------------------------------------
> > ------------------
> >
> >
> > > _______________________________________________
> > > 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
>

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

how to remove '/seaside/someApp'

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

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

RE: how to remove '/seaside/someApp'

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

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

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

Re: how to remove '/seaside/someApp'

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

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

Re: What's the (technical) purpose of adding t/seaside/ to the path (was: Re: how to remove '/seaside/someApp')

Re: What's the (technical) purpose of adding t/seaside/ to the path(was: Re: how to remove '/seaside/someApp')

Re: What's the (technical) purpose of adding t/seaside/ to the path(was: Re: how to remove '/seaside/someApp')

Parasol quarterly, issue 1.2 ­ the Seaside database issue ­ is now available

RE: Parasol quarterly, issue 1.2 - the Seaside database issue - is now available

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

RE: What's the (technical) purpose of adding t/seaside/ to thepath(was: Re: how to remove '/seaside/someApp')

RE: What's the (technical) purpose of adding t/seaside/ tothepath(was: Re: how to remove '/seaside/someApp')

Parasol quarterly, issue 1.2 the Seaside database issue is now available