seaside 3.0 pier image loading problem

[Nick Ager]

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

2010/1/11 Julian Fitzell <jfitzell at gmail.com>

> Sure, file and issue for Seaside, if you don't mind.
>
> Julian
>
> On Mon, Jan 11, 2010 at 4:37 AM, Nick Ager <nick.ager at gmail.com> 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 <jfitzell at gmail.com>
> >>
> >> 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 <nick.ager at gmail.com>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20100111/0ed5fb05/attachment.html>