Oddness with #lightbox: in VW

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Oddness with #lightbox: in VW

Yann Monclair-2
Hi all,

I've been playing around with Scriptaculous in VisualWorks, creating  
a sample application as a demo for co-workers.
During the ajax-ication of my application, I came to use #lightbox:  
instead of #call:
Now this lead to an error in my page rendering ( a MNU) and after  
investigation I found out that, when you do

r:=self lightbox: (aComponent).
r will first have for value self , then when aComponent will answer,  
it will have for value the object answered by aComponent.

This is not the same behaviour as #lightbox: in Squeak! So I suspect  
it is a VW problem.

I put together a quick test case app, to reproduce the bug.  (attached)

Component1 calls component2. everytime it does a call (with #call: or  
#lightbox: ) it inspects the value or r. As you will see, with #call:,
r is inspected only once, and has the proper value. With #lightbox: r  
is inspected twice, first holding self , then holding the proper value.

I will try to look into the problem myself, but any help is  
appreciated :)

Thanks,

Yann Monclair

PS: for the lucky people coming to Smalltalk Solutions 2007, I'll see  
you in Toronto!


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

LightboxBug.zip (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Oddness with #lightbox: in VW

Boris Popov, DeepCove Labs (SNN)
Which version of Seaside and SeasideScriptaculous are you using? There
was a change in the call/answer recently that I found in my YUI panel
use and myself and Lukas updated my implementation and his #lightbox: to
raise a render notification at the end to make it work properly again.
Its already part of the most recent version in public repository, but
here's a relevant method that you need,

lightbox: aComponent
        ^ AnswerContinuation currentDo: [ :cc |
                self
                        show: aComponent
                        onAnswer: cc
                        delegation: (Seaside.SULightbox new
                                delegate: aComponent;
                                yourself).
                WARenderNotification raiseSignal ]

By the way, this #lightbox has nothing to do with AJAX per se; it's just
a fancy way to render a modal component ;)

Hope this helps,

-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 Yann Monclair
> Sent: Thursday, April 26, 2007 9:57 AM
> To: The Squeak Enterprise Aubergines Server - general discussion.
> Subject: [Seaside] Oddness with #lightbox: in VW
>
> Hi all,
>
> I've been playing around with Scriptaculous in VisualWorks, creating
> a sample application as a demo for co-workers.
> During the ajax-ication of my application, I came to use #lightbox:
> instead of #call:
> Now this lead to an error in my page rendering ( a MNU) and after
> investigation I found out that, when you do
>
> r:=self lightbox: (aComponent).
> r will first have for value self , then when aComponent will answer,
> it will have for value the object answered by aComponent.
>
> This is not the same behaviour as #lightbox: in Squeak! So I suspect
> it is a VW problem.
>
> I put together a quick test case app, to reproduce the bug.
(attached)
>
> Component1 calls component2. everytime it does a call (with #call: or
> #lightbox: ) it inspects the value or r. As you will see, with #call:,
> r is inspected only once, and has the proper value. With #lightbox: r
> is inspected twice, first holding self , then holding the proper
value.

>
> I will try to look into the problem myself, but any help is
> appreciated :)
>
> Thanks,
>
> Yann Monclair
>
> PS: for the lucky people coming to Smalltalk Solutions 2007, I'll see
> you in Toronto!
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Oddness with #lightbox: in VW

Yann Monclair-2
Thanks Boris,

I can't say on the top of my head which version of scriptaculous we  
run, but I remember that that WARenderNotification raiseSignal isn't  
there, but it is in the #call: implementation.

Yes the lightbox isn't ajax, but it's eye candy that makes your app  
look more impressive ;)

Thanks,

Yann

On Apr 26, 2007, at 6:22 PM, Boris Popov wrote:

> Which version of Seaside and SeasideScriptaculous are you using? There
> was a change in the call/answer recently that I found in my YUI panel
> use and myself and Lukas updated my implementation and his  
> #lightbox: to
> raise a render notification at the end to make it work properly again.
> Its already part of the most recent version in public repository, but
> here's a relevant method that you need,
>
> lightbox: aComponent
> ^ AnswerContinuation currentDo: [ :cc |
> self
> show: aComponent
> onAnswer: cc
> delegation: (Seaside.SULightbox new
> delegate: aComponent;
> yourself).
> WARenderNotification raiseSignal ]
>
> By the way, this #lightbox has nothing to do with AJAX per se; it's  
> just
> a fancy way to render a modal component ;)
>
> Hope this helps,
>
> -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 Yann Monclair
>> Sent: Thursday, April 26, 2007 9:57 AM
>> To: The Squeak Enterprise Aubergines Server - general discussion.
>> Subject: [Seaside] Oddness with #lightbox: in VW
>>
>> Hi all,
>>
>> I've been playing around with Scriptaculous in VisualWorks, creating
>> a sample application as a demo for co-workers.
>> During the ajax-ication of my application, I came to use #lightbox:
>> instead of #call:
>> Now this lead to an error in my page rendering ( a MNU) and after
>> investigation I found out that, when you do
>>
>> r:=self lightbox: (aComponent).
>> r will first have for value self , then when aComponent will answer,
>> it will have for value the object answered by aComponent.
>>
>> This is not the same behaviour as #lightbox: in Squeak! So I suspect
>> it is a VW problem.
>>
>> I put together a quick test case app, to reproduce the bug.
> (attached)
>>
>> Component1 calls component2. everytime it does a call (with #call: or
>> #lightbox: ) it inspects the value or r. As you will see, with  
>> #call:,
>> r is inspected only once, and has the proper value. With #lightbox: r
>> is inspected twice, first holding self , then holding the proper
> value.
>>
>> I will try to look into the problem myself, but any help is
>> appreciated :)
>>
>> Thanks,
>>
>> Yann Monclair
>>
>> PS: for the lucky people coming to Smalltalk Solutions 2007, I'll see
>> you in Toronto!
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

RE: Oddness with #lightbox: in VW

Boris Popov, DeepCove Labs (SNN)
Yes, so you can either upgrade or add the signal to the lightbox
implementation.

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 Yann Monclair
> Sent: Thursday, April 26, 2007 10:36 AM
> To: Seaside - general discussion
> Subject: Re: [Seaside] Oddness with #lightbox: in VW
>
> Thanks Boris,
>
> I can't say on the top of my head which version of scriptaculous we
> run, but I remember that that WARenderNotification raiseSignal isn't
> there, but it is in the #call: implementation.
>
> Yes the lightbox isn't ajax, but it's eye candy that makes your app
> look more impressive ;)
>
> Thanks,
>
> Yann
>
> On Apr 26, 2007, at 6:22 PM, Boris Popov wrote:
>
> > Which version of Seaside and SeasideScriptaculous are you using?
There
> > was a change in the call/answer recently that I found in my YUI
panel
> > use and myself and Lukas updated my implementation and his
> > #lightbox: to
> > raise a render notification at the end to make it work properly
again.
> > Its already part of the most recent version in public repository,
but

> > here's a relevant method that you need,
> >
> > lightbox: aComponent
> > ^ AnswerContinuation currentDo: [ :cc |
> > self
> > show: aComponent
> > onAnswer: cc
> > delegation: (Seaside.SULightbox new
> > delegate: aComponent;
> > yourself).
> > WARenderNotification raiseSignal ]
> >
> > By the way, this #lightbox has nothing to do with AJAX per se; it's
> > just
> > a fancy way to render a modal component ;)
> >
> > Hope this helps,
> >
> > -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 Yann Monclair
> >> Sent: Thursday, April 26, 2007 9:57 AM
> >> To: The Squeak Enterprise Aubergines Server - general discussion.
> >> Subject: [Seaside] Oddness with #lightbox: in VW
> >>
> >> Hi all,
> >>
> >> I've been playing around with Scriptaculous in VisualWorks,
creating
> >> a sample application as a demo for co-workers.
> >> During the ajax-ication of my application, I came to use #lightbox:
> >> instead of #call:
> >> Now this lead to an error in my page rendering ( a MNU) and after
> >> investigation I found out that, when you do
> >>
> >> r:=self lightbox: (aComponent).
> >> r will first have for value self , then when aComponent will
answer,
> >> it will have for value the object answered by aComponent.
> >>
> >> This is not the same behaviour as #lightbox: in Squeak! So I
suspect
> >> it is a VW problem.
> >>
> >> I put together a quick test case app, to reproduce the bug.
> > (attached)
> >>
> >> Component1 calls component2. everytime it does a call (with #call:
or
> >> #lightbox: ) it inspects the value or r. As you will see, with
> >> #call:,
> >> r is inspected only once, and has the proper value. With #lightbox:
r

> >> is inspected twice, first holding self , then holding the proper
> > value.
> >>
> >> I will try to look into the problem myself, but any help is
> >> appreciated :)
> >>
> >> Thanks,
> >>
> >> Yann Monclair
> >>
> >> PS: for the lucky people coming to Smalltalk Solutions 2007, I'll
see

> >> you in Toronto!
> > _______________________________________________
> > 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
Reply | Threaded
Open this post in threaded view
|

Re: Oddness with #lightbox: in VW

Michel Bany-3
In reply to this post by Yann Monclair-2
Yann Monclair a écrit :
> Thanks Boris,
>
> I can't say on the top of my head which version of scriptaculous we
> run, but I remember that that WARenderNotification raiseSignal isn't
> there, but it is in the #call: implementation.
Yann, you are most probably on SeasideScriptaculous 2.6b2.6.x (or older)
together with Seaside 2.6b1.136.x. This combination is what you would
get if you loaded parcels from a recent VW 7.5 beta.

The issue you are describing is fixed in SeasideScriptaculous 2.6b2.7.x,
available on the public store. So you just need to grab the latest
SeasideScriptaculous from the public store.

In case you loaded the SeasideScriptaculous parcel, I suggest you unload
the parcel before loading the bundle from the public store.

Since I have not gotten the final VW 7.5 media yet, I'm not sure :-( if
this latest version of SeasideScriptaculous could make it for the final
VW7.5 build. Sorry.

Cheers,
Michel.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Oddness with #lightbox: in VW

Sau Sheong
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Hi,

This has nothing to do with this post beyond a curious behavior i  
noticed in the lightbox behavior when implemented with Seaside/
Squeak. if I call lightbox with a component as a parameter, it will  
render the component as a lightbox, which can be prettied up with  
some CSS. Tthe lightbox that is returned doesn't center in the middle  
of the screen. It centers vertically but not horizontally, in fact it  
veers to the left on popup. However If I resize the window, the  
lightbox corrects itself and centers in the middle of screen. I tried  
this with Firefox under OS X and Windows XP and it behaves the same way.

After some mucking around the code, I discovered that if I change  
this method in SULightbox:

SULightbox>>lighter
        ^ 'updateLightbox();window.onresize=function(){updateLightbox();};'

to this

SULightbox>>lighter
        ^ 'updateLightbox();updateLightbox();window.onresize=function()
{updateLightbox();};'


the problem goes away. I know it's a bit hackish and I was wondering  
if there is a better fix for this?

--
Sau Sheong

http://blog.saush.com - brain dump




On 27 Apr 2007, at 1:22 AM, Boris Popov wrote:

> Which version of Seaside and SeasideScriptaculous are you using? There
> was a change in the call/answer recently that I found in my YUI panel
> use and myself and Lukas updated my implementation and his  
> #lightbox: to
> raise a render notification at the end to make it work properly again.
> Its already part of the most recent version in public repository, but
> here's a relevant method that you need,
>
> lightbox: aComponent
> ^ AnswerContinuation currentDo: [ :cc |
> self
> show: aComponent
> onAnswer: cc
> delegation: (Seaside.SULightbox new
> delegate: aComponent;
> yourself).
> WARenderNotification raiseSignal ]
>
> By the way, this #lightbox has nothing to do with AJAX per se; it's  
> just
> a fancy way to render a modal component ;)
>
> Hope this helps,
>
> -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 Yann Monclair
>> Sent: Thursday, April 26, 2007 9:57 AM
>> To: The Squeak Enterprise Aubergines Server - general discussion.
>> Subject: [Seaside] Oddness with #lightbox: in VW
>>
>> Hi all,
>>
>> I've been playing around with Scriptaculous in VisualWorks, creating
>> a sample application as a demo for co-workers.
>> During the ajax-ication of my application, I came to use #lightbox:
>> instead of #call:
>> Now this lead to an error in my page rendering ( a MNU) and after
>> investigation I found out that, when you do
>>
>> r:=self lightbox: (aComponent).
>> r will first have for value self , then when aComponent will answer,
>> it will have for value the object answered by aComponent.
>>
>> This is not the same behaviour as #lightbox: in Squeak! So I suspect
>> it is a VW problem.
>>
>> I put together a quick test case app, to reproduce the bug.
> (attached)
>>
>> Component1 calls component2. everytime it does a call (with #call: or
>> #lightbox: ) it inspects the value or r. As you will see, with  
>> #call:,
>> r is inspected only once, and has the proper value. With #lightbox: r
>> is inspected twice, first holding self , then holding the proper
> value.
>>
>> I will try to look into the problem myself, but any help is
>> appreciated :)
>>
>> Thanks,
>>
>> Yann Monclair
>>
>> PS: for the lucky people coming to Smalltalk Solutions 2007, I'll see
>> you in Toronto!
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Short path question

Carl Gundel
In reply to this post by Michel Bany-3
I am using the short path modification from the public repository.  It sort
of works.  The trouble is that I'm using it with Seaside2.6b1-mb.108.mcz.
At least I'm assuming that this is not a supported configuation.

What works?  The application does return and a page is rendered in the
browser.

What doesn't work?  No other files are served up like images, css files,
etc.  Perhaps Seaside is just now looking in the wrong place for the files?

So, can this be tweaked to work?  Is there a version of the short path mod
that works for Seaside v2.6?

Thanks for any help.

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


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Short path question

ching
get 2.7 and:

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

David Shaffer pointed this out to me and it worked. 2.6 does not support #defaultName so you need 2.7.

Ching

On 7/22/07, Carl Gundel <[hidden email]> wrote:
I am using the short path modification from the public repository.  It sort
of works.  The trouble is that I'm using it with Seaside2.6b1-mb.108.mcz.
At least I'm assuming that this is not a supported configuation.

What works?  The application does return and a page is rendered in the
browser.

What doesn't work?  No other files are served up like images, css files,
etc.  Perhaps Seaside is just now looking in the wrong place for the files?

So, can this be tweaked to work?  Is there a version of the short path mod
that works for Seaside v2.6?

Thanks for any help.

-Carl Gundel
http://www.runbasic.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
Reply | Threaded
Open this post in threaded view
|

Re: Short path question

Carl Gundel
Okay, but if that's all you need to do for v2.7 then why is there a short
patch patch?  How does your tip differ from the short path patch in terms of
what it delivers?

-Carl

From: "Ching de la Serna" <[hidden email]>

> get 2.7 and:
>
> WADispatcher default setName: ''.
> WADispatcher default defaultName: 'yourApp'
>
> David Shaffer pointed this out to me and it worked. 2.6 does not support
> #defaultName so you need 2.7.
>
> Ching
>
> On 7/22/07, Carl Gundel <[hidden email]> wrote:
>>
>> I am using the short path modification from the public repository.  It
>> sort
>> of works.  The trouble is that I'm using it with Seaside2.6b1-mb.108.mcz.
>> At least I'm assuming that this is not a supported configuation.
>>
>> What works?  The application does return and a page is rendered in the
>> browser.
>>
>> What doesn't work?  No other files are served up like images, css files,
>> etc.  Perhaps Seaside is just now looking in the wrong place for the
>> files?
>>
>> So, can this be tweaked to work?  Is there a version of the short path
>> mod
>> that works for Seaside v2.6?
>>
>> Thanks for any help.
>>
>> -Carl Gundel
>> http://www.runbasic.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
>


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Short path question

ching
sorry Carl, I am not aware of the short path patch. I use Squeak. Perhaps you might be using VW?

Ching

On 7/22/07, Carl Gundel <[hidden email]> wrote:
Okay, but if that's all you need to do for v2.7 then why is there a short
patch patch?  How does your tip differ from the short path patch in terms of
what it delivers?

-Carl

From: "Ching de la Serna" <[hidden email]>

> get 2.7 and:
>
> WADispatcher default setName: ''.
> WADispatcher default defaultName: 'yourApp'
>
> David Shaffer pointed this out to me and it worked. 2.6 does not support
> #defaultName so you need 2.7.
>
> Ching
>
> On 7/22/07, Carl Gundel <[hidden email]> wrote:
>>
>> I am using the short path modification from the public repository.  It
>> sort
>> of works.  The trouble is that I'm using it with Seaside2.6b1-mb.108.mcz.
>> At least I'm assuming that this is not a supported configuation.
>>
>> What works?  The application does return and a page is rendered in the
>> browser.
>>
>> What doesn't work?  No other files are served up like images, css files,
>> etc.  Perhaps Seaside is just now looking in the wrong place for the
>> files?
>>
>> So, can this be tweaked to work?  Is there a version of the short path
>> mod
>> that works for Seaside v2.6?
>>
>> Thanks for any help.
>>
>> -Carl Gundel
>> http://www.runbasic.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
>


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Short path question

Carl Gundel
Yes.  VisualWorks.  That's why I mentioned the public repository.  I should
have been clearer.

-Carl

From: "Ching de la Serna" <[hidden email]>

> sorry Carl, I am not aware of the short path patch. I use Squeak. Perhaps
> you might be using VW?
>
> Ching
>
> On 7/22/07, Carl Gundel <[hidden email]> wrote:
>>
>> Okay, but if that's all you need to do for v2.7 then why is there a short
>> patch patch?  How does your tip differ from the short path patch in terms
>> of
>> what it delivers?
>>
>> -Carl
>>
>> From: "Ching de la Serna" <[hidden email]>
>> > get 2.7 and:
>> >
>> > WADispatcher default setName: ''.
>> > WADispatcher default defaultName: 'yourApp'
>> >
>> > David Shaffer pointed this out to me and it worked. 2.6 does not
>> > support
>> > #defaultName so you need 2.7.
>> >
>> > Ching
>> >
>> > On 7/22/07, Carl Gundel <[hidden email]> wrote:
>> >>
>> >> I am using the short path modification from the public repository.  It
>> >> sort
>> >> of works.  The trouble is that I'm using it with
>> Seaside2.6b1-mb.108.mcz.
>> >> At least I'm assuming that this is not a supported configuation.
>> >>
>> >> What works?  The application does return and a page is rendered in the
>> >> browser.
>> >>
>> >> What doesn't work?  No other files are served up like images, css
>> files,
>> >> etc.  Perhaps Seaside is just now looking in the wrong place for the
>> >> files?
>> >>
>> >> So, can this be tweaked to work?  Is there a version of the short path
>> >> mod
>> >> that works for Seaside v2.6?
>> >>
>> >> Thanks for any help.
>> >>
>> >> -Carl Gundel
>> >> http://www.runbasic.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
>> >
>>
>>
>> _______________________________________________
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Short path question

Michael Lucas-Smith-3
I think the ShortPath patch is defunct with the 2.7 options.

Carl Gundel wrote:

> Yes.  VisualWorks.  That's why I mentioned the public repository.  I
> should have been clearer.
>
> -Carl
>
> From: "Ching de la Serna" <[hidden email]>
>> sorry Carl, I am not aware of the short path patch. I use Squeak.
>> Perhaps
>> you might be using VW?
>>
>> Ching
>>
>> On 7/22/07, Carl Gundel <[hidden email]> wrote:
>>>
>>> Okay, but if that's all you need to do for v2.7 then why is there a
>>> short
>>> patch patch?  How does your tip differ from the short path patch in
>>> terms
>>> of
>>> what it delivers?
>>>
>>> -Carl
>>>
>>> From: "Ching de la Serna" <[hidden email]>
>>> > get 2.7 and:
>>> >
>>> > WADispatcher default setName: ''.
>>> > WADispatcher default defaultName: 'yourApp'
>>> >
>>> > David Shaffer pointed this out to me and it worked. 2.6 does not >
>>> support
>>> > #defaultName so you need 2.7.
>>> >
>>> > Ching
>>> >
>>> > On 7/22/07, Carl Gundel <[hidden email]> wrote:
>>> >>
>>> >> I am using the short path modification from the public
>>> repository.  It
>>> >> sort
>>> >> of works.  The trouble is that I'm using it with
>>> Seaside2.6b1-mb.108.mcz.
>>> >> At least I'm assuming that this is not a supported configuation.
>>> >>
>>> >> What works?  The application does return and a page is rendered
>>> in the
>>> >> browser.
>>> >>
>>> >> What doesn't work?  No other files are served up like images, css
>>> files,
>>> >> etc.  Perhaps Seaside is just now looking in the wrong place for the
>>> >> files?
>>> >>
>>> >> So, can this be tweaked to work?  Is there a version of the short
>>> path
>>> >> mod
>>> >> that works for Seaside v2.6?
>>> >>
>>> >> Thanks for any help.
>>> >>
>>> >> -Carl Gundel
>>> >> http://www.runbasic.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
>>> >
>>>
>>>
>>> _______________________________________________
>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Short path question

Michel Bany
In reply to this post by Carl Gundel

On 22 Jul 2007, at 00:27 , Carl Gundel wrote:

> What doesn't work?  No other files are served up like images, css  
> files, etc.  Perhaps Seaside is just now looking in the wrong place  
> for the files?
>
> So, can this be tweaked to work?  Is there a version of the short  
> path mod that works for Seaside v2.6?

Hi Carl,

It is correct that this patch prevents WTK from serving static files  
from the default WTK site.

If you define you own WTK site (say a site named "foo"), then you can  
serve files from this site

        http//host:port/foo/bar.css

Regarding other versions of Seaside, I would say that Seaside-
ShortPath should work fine with 2.6, 2.7 and 2.8, including the  
technique explained above for serving static files.

HTH
Michel.


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