Wrong URLs with Internet Explorer (again)

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

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:

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

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 <[hidden email]>:

--
Germán S. Arduino
http://www.arsol.biz
http://www.arsol.net
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I appear to be having this problem, of course a re install will probably
fix it, but I would like to know what is going on.

Keith

               
___________________________________________________________
All New Yahoo! Mail – Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

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 got two excellent answers.

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?

Dan Shafer


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

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

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

It looks like NetworkHost nameString fails if the name is an unqualified
numeric ip address, i.e. an ordered collection of 4 bytes.

Keith
 

       
       
               
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I do something similar to Todd's approach...

One time in generic lib that all my apps share
 * Subclass WAComponent (SSComponent), modify default renderer
 * Subclass SSComponent (SSApp), add canBeRoot on class side
 * Subclass WASession (SSSession), added some mods for SSL and a dictionary
in config for application scope hashing, I don't like using the Session
class side because that's image scope not app scope.

Each time I do a seaside app
 * Subclass SSApp for root component
 * Subclass SSComponent for other components
 * Subclass SSSession for app specific session vars
 * Visit seaside/config to create a new Seaside app, choosing session class
for session and home page class for base component.  I don't like the class
initialize approach because it assumes there's only one instance of the app
running, this may not be true.


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

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

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

Keith Hodges wrote:
> I just tried loading Seaside 2.6b1-mb36 into my image and got an error
> that I do not think is related.
>
> It looks like NetworkHost nameString fails if the name is an
> unqualified numeric ip address, i.e. an ordered collection of 4 bytes.
>
> Keith
I am not sure if it was on loading the package or not, I think it was
handling an http request at the time. Sorry but I was on a university
computer, and in their infinite wisdom they decided to reboot various
servers at 5pm in the middle of my 2 hour demo session!

My feeling is that it is not to do with your package because the bug is
in Komanche code. I fixed it with

by changing

nameString
    ^ String streamContents: [ :str |
            self name do: [:nm | str nextPutAll: nm] separatedBy: [str
nextPut: $.] ]

to
nameString
    ^ String streamContents: [ :str |
            self name do: [:nm | str nextPutAll: nm asString ]
separatedBy: [str nextPut: $.] ]

I find this curious because the original code is obviously expecting to
join some items together with some dots, and I would have thought that
the most common item would be a SmallInteger.

When the error occured NetworkHost-fullName was already equal to the ip
address in string form, and name was in OrderedCollection of 4 bytes form.

Keith

       
       
               
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside