seaside 3.0 pier image loading problem

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

seaside 3.0 pier image loading problem

Nick
When I merged the latest Pier code with the Pier for Seaside 3.0 branch I noticed that the Pier logo wasn't appearing on the initial screen, although it appeared on the 3.0 branch prior to the merge.

I traced the difference in behaviour down to a code change in PRViewCommand>>initialRequest

the pre-merge version:
initialRequest: aRequest
| viewClass |
super initialRequest: aRequest.
viewClass := PRPierFrame 
classFromRequest: aRequest
name: 'view'
base: PRViewComponent.
(viewClass isNil and: [ self structure isFile ])
ifTrue: [ viewClass := PRDownloadView ].
(viewClass notNil and: [ viewClass isValidIn: self context ])
ifTrue: [ self viewComponentClass: viewClass ].
self viewComponent visiblePresentersDo: [ :each | each initialRequest: aRequest ].
(self viewComponent isFullResponse)
ifTrue: [ self viewComponent handle: WACurrentRequestContext value ]

post-merge version:
initialRequest: aRequest
| viewClass |
super initialRequest: aRequest.
viewClass := PRPierFrame
classFromRequest: aRequest
name: 'view'
base: PRViewComponent.
(viewClass notNil and: [ viewClass isValidIn: self context ])
ifTrue: [ self viewComponentClass: viewClass ].
self viewComponent visiblePresentersDo: [ :each | each initialRequest: aRequest ].
(self viewComponent isFullResponse)
ifTrue: [ self viewComponent handle: WACurrentRequestContext value ]

the pre-merge version has the addition of the code: (viewClass isNil and: [ self structure isFile ]) ifTrue: [ viewClass := PRDownloadView ].

However this code isn't present in the main 2.8 code-base. The problem is more subtle. The pier environment stylesheet requests an image from: '/seaside/pier/environment/pier.png?view=PRDownloadView' this is trapped by the code in WAOldPathComptibilityRequestHandler which issues a 301 moved permanently redirect to '/pier/environment/pier.png'. The problem is that during the redirection the url parameters have been lost. I've fixed the problem locally by changing WAOldPathComptibilityRequestHandler>>handleFiltered: from:

handleFiltered: aRequestContext
| url |
url := aRequestContext request url copy.
url path removeFirst.
aRequestContext response
movedPermanently;
location: url.
aRequestContext respond 

to:
handleFiltered: aRequestContext
| url |
url := aRequestContext request url copy.
url path removeFirst.
url parameters: aRequestContext request fields.
aRequestContext response
movedPermanently;
location: url.
aRequestContext respond

I copy the parameters from the request to the url. Should I save this change into seaside 3.0 repositories? Or is there something else that needs fixing higher up the call stack to account for why the parameters haven't been added to the WAUrl object?

Hope this all makes sense

Nick

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: seaside 3.0 pier image loading problem

Julian Fitzell-2
Sigh...

Can you just fix the stylesheet to drop the /seaside for now?

I'm generally unhappy with how WARequest/WAUrl are working in this
regard at the moment... I'll bring it up with the Seaside team and see
what we can do about it.

Julian

On Sun, Jan 10, 2010 at 12:25 PM, Nick Ager <[hidden email]> wrote:

> When I merged the latest Pier code with the Pier for Seaside 3.0 branch I
> noticed that the Pier logo wasn't appearing on the initial screen, although
> it appeared on the 3.0 branch prior to the merge.
> I traced the difference in behaviour down to a code change in
> PRViewCommand>>initialRequest
> the pre-merge version:
> initialRequest: aRequest
> | viewClass |
> super initialRequest: aRequest.
> viewClass := PRPierFrame
> classFromRequest: aRequest
> name: 'view'
> base: PRViewComponent.
> (viewClass isNil and: [ self structure isFile ])
> ifTrue: [ viewClass := PRDownloadView ].
> (viewClass notNil and: [ viewClass isValidIn: self context ])
> ifTrue: [ self viewComponentClass: viewClass ].
> self viewComponent visiblePresentersDo: [ :each | each initialRequest:
> aRequest ].
> (self viewComponent isFullResponse)
> ifTrue: [ self viewComponent handle: WACurrentRequestContext value ]
> post-merge version:
> initialRequest: aRequest
> | viewClass |
> super initialRequest: aRequest.
> viewClass := PRPierFrame
> classFromRequest: aRequest
> name: 'view'
> base: PRViewComponent.
> (viewClass notNil and: [ viewClass isValidIn: self context ])
> ifTrue: [ self viewComponentClass: viewClass ].
> self viewComponent visiblePresentersDo: [ :each | each initialRequest:
> aRequest ].
> (self viewComponent isFullResponse)
> ifTrue: [ self viewComponent handle: WACurrentRequestContext value ]
> the pre-merge version has the addition of the code: (viewClass isNil and: [
> self structure isFile ]) ifTrue: [ viewClass := PRDownloadView ].
> However this code isn't present in the main 2.8 code-base. The problem is
> more subtle. The pier environment stylesheet requests an image from:
> '/seaside/pier/environment/pier.png?view=PRDownloadView' this is trapped by
> the code in WAOldPathComptibilityRequestHandler which issues a 301 moved
> permanently redirect to '/pier/environment/pier.png'. The problem is that
> during the redirection the url parameters have been lost. I've fixed the
> problem locally by changing
> WAOldPathComptibilityRequestHandler>>handleFiltered: from:
> handleFiltered: aRequestContext
> | url |
> url := aRequestContext request url copy.
> url path removeFirst.
> aRequestContext response
> movedPermanently;
> location: url.
> aRequestContext respond
> to:
> handleFiltered: aRequestContext
> | url |
> url := aRequestContext request url copy.
> url path removeFirst.
> url parameters: aRequestContext request fields.
> aRequestContext response
> movedPermanently;
> location: url.
> aRequestContext respond
> I copy the parameters from the request to the url. Should I save this change
> into seaside 3.0 repositories? Or is there something else that needs fixing
> higher up the call stack to account for why the parameters haven't been
> added to the WAUrl object?
> Hope this all makes sense
> Nick
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: seaside 3.0 pier image loading problem

Nick
OK style sheet path changed, image now appears. Changes in: Pier-Seaside-NickAger.466

Should I add an issue to the bug tracker about loosing url parameters during redirection?

BTW I've noticed that WAOldPathComptibilityRequestHandler has been renamed WALegacyRedirectionHandler in the latest code.

2010/1/10 Julian Fitzell <[hidden email]>
Sigh...

Can you just fix the stylesheet to drop the /seaside for now?

I'm generally unhappy with how WARequest/WAUrl are working in this
regard at the moment... I'll bring it up with the Seaside team and see
what we can do about it.

Julian

On Sun, Jan 10, 2010 at 12:25 PM, Nick Ager <[hidden email]> wrote:
> When I merged the latest Pier code with the Pier for Seaside 3.0 branch I
> noticed that the Pier logo wasn't appearing on the initial screen, although
> it appeared on the 3.0 branch prior to the merge.
> I traced the difference in behaviour down to a code change in
> PRViewCommand>>initialRequest
> the pre-merge version:
> initialRequest: aRequest
> | viewClass |
> super initialRequest: aRequest.
> viewClass := PRPierFrame
> classFromRequest: aRequest
> name: 'view'
> base: PRViewComponent.
> (viewClass isNil and: [ self structure isFile ])
> ifTrue: [ viewClass := PRDownloadView ].
> (viewClass notNil and: [ viewClass isValidIn: self context ])
> ifTrue: [ self viewComponentClass: viewClass ].
> self viewComponent visiblePresentersDo: [ :each | each initialRequest:
> aRequest ].
> (self viewComponent isFullResponse)
> ifTrue: [ self viewComponent handle: WACurrentRequestContext value ]
> post-merge version:
> initialRequest: aRequest
> | viewClass |
> super initialRequest: aRequest.
> viewClass := PRPierFrame
> classFromRequest: aRequest
> name: 'view'
> base: PRViewComponent.
> (viewClass notNil and: [ viewClass isValidIn: self context ])
> ifTrue: [ self viewComponentClass: viewClass ].
> self viewComponent visiblePresentersDo: [ :each | each initialRequest:
> aRequest ].
> (self viewComponent isFullResponse)
> ifTrue: [ self viewComponent handle: WACurrentRequestContext value ]
> the pre-merge version has the addition of the code: (viewClass isNil and: [
> self structure isFile ]) ifTrue: [ viewClass := PRDownloadView ].
> However this code isn't present in the main 2.8 code-base. The problem is
> more subtle. The pier environment stylesheet requests an image from:
> '/seaside/pier/environment/pier.png?view=PRDownloadView' this is trapped by
> the code in WAOldPathComptibilityRequestHandler which issues a 301 moved
> permanently redirect to '/pier/environment/pier.png'. The problem is that
> during the redirection the url parameters have been lost. I've fixed the
> problem locally by changing
> WAOldPathComptibilityRequestHandler>>handleFiltered: from:
> handleFiltered: aRequestContext
> | url |
> url := aRequestContext request url copy.
> url path removeFirst.
> aRequestContext response
> movedPermanently;
> location: url.
> aRequestContext respond
> to:
> handleFiltered: aRequestContext
> | url |
> url := aRequestContext request url copy.
> url path removeFirst.
> url parameters: aRequestContext request fields.
> aRequestContext response
> movedPermanently;
> location: url.
> aRequestContext respond
> I copy the parameters from the request to the url. Should I save this change
> into seaside 3.0 repositories? Or is there something else that needs fixing
> higher up the call stack to account for why the parameters haven't been
> added to the WAUrl object?
> Hope this all makes sense
> Nick
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki


_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: seaside 3.0 pier image loading problem

Julian Fitzell-2
Sure, file and issue for Seaside, if you don't mind.

Julian

On Mon, Jan 11, 2010 at 4:37 AM, Nick Ager <[hidden email]> wrote:

> OK style sheet path changed, image now appears. Changes in:
> Pier-Seaside-NickAger.466
> Should I add an issue to the bug tracker about loosing url parameters
> during redirection?
> BTW I've noticed that WAOldPathComptibilityRequestHandler has been
> renamed WALegacyRedirectionHandler in the latest code.
>
> 2010/1/10 Julian Fitzell <[hidden email]>
>>
>> Sigh...
>>
>> Can you just fix the stylesheet to drop the /seaside for now?
>>
>> I'm generally unhappy with how WARequest/WAUrl are working in this
>> regard at the moment... I'll bring it up with the Seaside team and see
>> what we can do about it.
>>
>> Julian
>>
>> On Sun, Jan 10, 2010 at 12:25 PM, Nick Ager <[hidden email]> wrote:
>> > When I merged the latest Pier code with the Pier for Seaside 3.0 branch
>> > I
>> > noticed that the Pier logo wasn't appearing on the initial screen,
>> > although
>> > it appeared on the 3.0 branch prior to the merge.
>> > I traced the difference in behaviour down to a code change in
>> > PRViewCommand>>initialRequest
>> > the pre-merge version:
>> > initialRequest: aRequest
>> > | viewClass |
>> > super initialRequest: aRequest.
>> > viewClass := PRPierFrame
>> > classFromRequest: aRequest
>> > name: 'view'
>> > base: PRViewComponent.
>> > (viewClass isNil and: [ self structure isFile ])
>> > ifTrue: [ viewClass := PRDownloadView ].
>> > (viewClass notNil and: [ viewClass isValidIn: self context ])
>> > ifTrue: [ self viewComponentClass: viewClass ].
>> > self viewComponent visiblePresentersDo: [ :each | each initialRequest:
>> > aRequest ].
>> > (self viewComponent isFullResponse)
>> > ifTrue: [ self viewComponent handle: WACurrentRequestContext value ]
>> > post-merge version:
>> > initialRequest: aRequest
>> > | viewClass |
>> > super initialRequest: aRequest.
>> > viewClass := PRPierFrame
>> > classFromRequest: aRequest
>> > name: 'view'
>> > base: PRViewComponent.
>> > (viewClass notNil and: [ viewClass isValidIn: self context ])
>> > ifTrue: [ self viewComponentClass: viewClass ].
>> > self viewComponent visiblePresentersDo: [ :each | each initialRequest:
>> > aRequest ].
>> > (self viewComponent isFullResponse)
>> > ifTrue: [ self viewComponent handle: WACurrentRequestContext value ]
>> > the pre-merge version has the addition of the code: (viewClass isNil
>> > and: [
>> > self structure isFile ]) ifTrue: [ viewClass := PRDownloadView ].
>> > However this code isn't present in the main 2.8 code-base. The problem
>> > is
>> > more subtle. The pier environment stylesheet requests an image from:
>> > '/seaside/pier/environment/pier.png?view=PRDownloadView' this is trapped
>> > by
>> > the code in WAOldPathComptibilityRequestHandler which issues a 301 moved
>> > permanently redirect to '/pier/environment/pier.png'. The problem is
>> > that
>> > during the redirection the url parameters have been lost. I've fixed the
>> > problem locally by changing
>> > WAOldPathComptibilityRequestHandler>>handleFiltered: from:
>> > handleFiltered: aRequestContext
>> > | url |
>> > url := aRequestContext request url copy.
>> > url path removeFirst.
>> > aRequestContext response
>> > movedPermanently;
>> > location: url.
>> > aRequestContext respond
>> > to:
>> > handleFiltered: aRequestContext
>> > | url |
>> > url := aRequestContext request url copy.
>> > url path removeFirst.
>> > url parameters: aRequestContext request fields.
>> > aRequestContext response
>> > movedPermanently;
>> > location: url.
>> > aRequestContext respond
>> > I copy the parameters from the request to the url. Should I save this
>> > change
>> > into seaside 3.0 repositories? Or is there something else that needs
>> > fixing
>> > higher up the call stack to account for why the parameters haven't been
>> > added to the WAUrl object?
>> > Hope this all makes sense
>> > Nick
>> > _______________________________________________
>> > Magritte, Pier and Related Tools ...
>> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>> >
>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
Reply | Threaded
Open this post in threaded view
|

Re: seaside 3.0 pier image loading problem

Nick
filed: http://code.google.com/p/seaside/issues/detail?id=525

2010/1/11 Julian Fitzell <[hidden email]>
Sure, file and issue for Seaside, if you don't mind.

Julian

On Mon, Jan 11, 2010 at 4:37 AM, Nick Ager <[hidden email]> wrote:
> OK style sheet path changed, image now appears. Changes in:
> Pier-Seaside-NickAger.466
> Should I add an issue to the bug tracker about loosing url parameters
> during redirection?
> BTW I've noticed that WAOldPathComptibilityRequestHandler has been
> renamed WALegacyRedirectionHandler in the latest code.
>
> 2010/1/10 Julian Fitzell <[hidden email]>
>>
>> Sigh...
>>
>> Can you just fix the stylesheet to drop the /seaside for now?
>>
>> I'm generally unhappy with how WARequest/WAUrl are working in this
>> regard at the moment... I'll bring it up with the Seaside team and see
>> what we can do about it.
>>
>> Julian
>>
>> On Sun, Jan 10, 2010 at 12:25 PM, Nick Ager <[hidden email]> wrote:
>> > When I merged the latest Pier code with the Pier for Seaside 3.0 branch
>> > I
>> > noticed that the Pier logo wasn't appearing on the initial screen,
>> > although
>> > it appeared on the 3.0 branch prior to the merge.
>> > I traced the difference in behaviour down to a code change in
>> > PRViewCommand>>initialRequest
>> > the pre-merge version:
>> > initialRequest: aRequest
>> > | viewClass |
>> > super initialRequest: aRequest.
>> > viewClass := PRPierFrame
>> > classFromRequest: aRequest
>> > name: 'view'
>> > base: PRViewComponent.
>> > (viewClass isNil and: [ self structure isFile ])
>> > ifTrue: [ viewClass := PRDownloadView ].
>> > (viewClass notNil and: [ viewClass isValidIn: self context ])
>> > ifTrue: [ self viewComponentClass: viewClass ].
>> > self viewComponent visiblePresentersDo: [ :each | each initialRequest:
>> > aRequest ].
>> > (self viewComponent isFullResponse)
>> > ifTrue: [ self viewComponent handle: WACurrentRequestContext value ]
>> > post-merge version:
>> > initialRequest: aRequest
>> > | viewClass |
>> > super initialRequest: aRequest.
>> > viewClass := PRPierFrame
>> > classFromRequest: aRequest
>> > name: 'view'
>> > base: PRViewComponent.
>> > (viewClass notNil and: [ viewClass isValidIn: self context ])
>> > ifTrue: [ self viewComponentClass: viewClass ].
>> > self viewComponent visiblePresentersDo: [ :each | each initialRequest:
>> > aRequest ].
>> > (self viewComponent isFullResponse)
>> > ifTrue: [ self viewComponent handle: WACurrentRequestContext value ]
>> > the pre-merge version has the addition of the code: (viewClass isNil
>> > and: [
>> > self structure isFile ]) ifTrue: [ viewClass := PRDownloadView ].
>> > However this code isn't present in the main 2.8 code-base. The problem
>> > is
>> > more subtle. The pier environment stylesheet requests an image from:
>> > '/seaside/pier/environment/pier.png?view=PRDownloadView' this is trapped
>> > by
>> > the code in WAOldPathComptibilityRequestHandler which issues a 301 moved
>> > permanently redirect to '/pier/environment/pier.png'. The problem is
>> > that
>> > during the redirection the url parameters have been lost. I've fixed the
>> > problem locally by changing
>> > WAOldPathComptibilityRequestHandler>>handleFiltered: from:
>> > handleFiltered: aRequestContext
>> > | url |
>> > url := aRequestContext request url copy.
>> > url path removeFirst.
>> > aRequestContext response
>> > movedPermanently;
>> > location: url.
>> > aRequestContext respond
>> > to:
>> > handleFiltered: aRequestContext
>> > | url |
>> > url := aRequestContext request url copy.
>> > url path removeFirst.
>> > url parameters: aRequestContext request fields.
>> > aRequestContext response
>> > movedPermanently;
>> > location: url.
>> > aRequestContext respond
>> > I copy the parameters from the request to the url. Should I save this
>> > change
>> > into seaside 3.0 repositories? Or is there something else that needs
>> > fixing
>> > higher up the call stack to account for why the parameters haven't been
>> > added to the WAUrl object?
>> > Hope this all makes sense
>> > Nick
>> > _______________________________________________
>> > Magritte, Pier and Related Tools ...
>> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>> >
>>
>> _______________________________________________
>> Magritte, Pier and Related Tools ...
>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki


_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki