Hi Avi:

Thanks by your interest.

I've talked with Lukas, and seems that my problem was by an older version of Seaside.

Now installed a new one and seems that the problem is gone, but yet trying.....

If the problem occurs again, I will ask again here.

Cheers. gsa.

2006/4/6, Avi Bryant avi.bryant@gmail.com:

German,

Do you have a simple way to reproduce this, from a standard Squeak image and Seaside version? I've never seen this happen and I'd like to understand it better.

Avi

On Apr 1, 2006, at 1:54 PM, Germán Arduino wrote:

...

Hi:

This is a problem that I've found time ago. Then was not very important because I can manage to use only Firefox, but now I must to expose to Internet a customer application and works ok with Firefox, but when I try to access it using IE, all the urls look bad, as by example: http:///seaside/counter.

"Something" is removing the "localhost:port" or "IP:port" from the url, but I can't figure out what thing is generating this behavior.

Inside my applications also the "IP:port" look stripped from all the urls.

I've tried playing with Resource Base URL and Server Hostname from seaside configuration, but can't solve the problem. I must say also that I'm using ShoreComponents.

Any help will be appreciated.

Cheers. gsa. _______________________________________________ Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

---

Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

-- Germán S. Arduino http://www.arsol.biz http://www.arsol.net

Hi, I have a seaside application on a server, let say 'www.myhost.com'. When I type http://www.myhost.com/ in my navigator, my seaside app loads well, but the address bar shows the ip of the server (e.g. http://1.2.3.4/myapp). I would like it to shows the hostname (http://www.myhost.com/myapp). I set the 'Server Hostname' of my seaside application to 'www.myhost.com', so now the links use the right host for the urls. But the address bar still shows the ip... Any suggestion ?

Florian

Todd Blanchard's recipe, in summary, was:

1. Subclass WASession so I can manage app state.
2. Subclass WAComponent
3. Add rendererClass method to the WAComponent subclass.
4. Subclass this base component to create the home page component
5. Add a canBeRoot class method to this subclass of the base component
6. Visit seaside/config to create a new Seaside app, choosing session

class for sssion and home page class for base component

Mike Roberts' recipe, in summary, was:

1. Subclass WAComponent
2. Implement the method renderContentOn:
3. Implement canBeRoot on the class side
4. Implement initialize on the class side
5. Initialize the app
6. Point your browser at the app

I tried both and was successful using both approaches. Clearly Todd's approach is somewhat more complex, involving as it does three subclass operations. At Step 4 of his procedure, one would have to create the home page component, presumably, using renderContentOn: for that component.

Mike's approach brings quicker instant gratification but ultimately is one going to have to (or want to) subclass WASession anyway to allow the management of app state? WASession *seems* without a great deal of study to be fairly complicated.

So would you suggest I document Mike's, Todd's, or both? What are the advantages of each? Or do you have another way altogether to approach the problem?

I would suggest a mix that allows the user to use the new canvas API without subclassing the WASession that is not usefull for everybody.

1. Subclass WAComponent and add #rendererClass to answer the new canvas renderer 2. Subclass this class for each component you would like on your application 3. Add #canBeRoot on the class side of the main component 4. Visit seaside/config to create the Seaside app

Dan Shafer wrote:

Recently i queried the list about my idea of writing a Getting Started recipe for Seaside applications. My interest grew out of my inability to get a quick handle on the basic process of Seaside app creation.

I tried both and was successful using both approaches. Clearly Todd's approach is somewhat more complex, involving as it does three subclass operations. At Step 4 of his procedure, one would have to create the home page component, presumably, using renderContentOn: for that component.

Having a root component is pretty mandatory to be honest, so it isn't a big deal when you make it. The main difference is that my example doesn't use the canvas framework so I don't implement #rendererClass but you can stick that on your root component directly to start off with. If you feel you want to push that up to an abstract superclass then by all means but I'd refactor that only when you need to. You are essentially comparing the difference between speed and sophistication so it's not entirely comparable ;-).

but ultimately is one going to have to (or want to) subclass WASession anyway to allow the management of app state? WASession *seems* without a great deal of study to be fairly complicated.

I personally don't think you need to subclass the session until you have a reason to do so. Given that you were talking about 'getting started' I think that session customisation is slightly beyond the first stage. If all you want to do is manage some global state then you can do that with a singleton class or a global, for example. When you're ready to subclass the session, go for it. You can get quite far without it, so I didn't mention it.

So would you suggest I document Mike's, Todd's, or both? What are the advantages of each? Or do you have another way altogether to approach the problem?

By all means write some documentation! I'm not sure what problem you are approaching though? If you just want a recipe for getting started from scratch then I would probably take mine and add in the #rendererClass method and mention the config app along with the class side initialisation code.

Although for getting started, a quicker way is to just hack the counter application so I guess you need to be clear about what you want your recipe to achieve.

In a way both approaches are the same, at least mine is a subset of the other. Using the web based configuration app and writing class side methods achieve the same thing but have a different set of side-effects. If you write your initialization on the class then it has the advantage of being persisted and evaluated when you load the class into a fresh image. If your configuration is more complicated, however, you will need to search for the correct messages to use. The configuration app makes changing the configuration easy but the changes, afaik, are just local to the image. I'm not sure if there is a method to write the configuration out as an initialize method (I haven't looked) but that might be quite a useful feature.

Cheers,

Mike

I just tried loading Seaside 2.6b1-mb36 into my image and got an error that I do not think is related.

Keith, Can you be more specific? What was the error? Did it occur while loading the package? TIA, Michel.