serving stylesheets

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

serving stylesheets

Nick
Hi,

For all the Pier distribution I've checked I've noticed that for each request the stylesheet was being served from a new Url. The relevant implementation is:

MAFileModel>>url
"Answer a link to a request handler for the given file."
| handler |
handler := MAFileModelHandler on: self.
^ WACurrentRequestContext value registry
register: handler;
urlFor: handler


Which means that for every request for a file model's url, a new MAFileModelHandler is being created and registered.

The result is:
* The browser never caches the stylesheet
* Each page request unnecessarily adds to the application's collection of handlers.

Note: This is a generic Pier issue for PRFile requests, unless the url includes the query ?view=PRDownloadView OR MAExternalFileModel class baseUrl: has been defined).

One solution would be to add ?view=PRDownloadView to the url for stylesheet requests or possibly for all file requests (modify MAExternalFileModel>>url to add ?view=PRDownloadView).

However pondering the problem I've prototyped a solution in which PRFile have a custom view component "PRFileView" which responds with it's associated PRFile file directly, rather than delegating to MAFileModelHandler. The logic is that, by default, PRFile>>#url responds with a fully qualified path to itself within the pier structure e.g. /pier/template/style.css then PRFileView>>#initialRequest checks the request to see if it matches the mime-type of it's associated PRFile's mime-type, if so it will respond true to  PRFileView>#isFullResponse and serve the file directly in  PRFileView>#respondUsing:

MAExternalFileModel class>>#baseUrl still works as intended and MAFileModel>>#url (and friends) remains unchanged.

The result appears to be a neater solution than modify MAExternalFileModel>>url to add ?view=PRDownloadView, but I might be suffering from implementors bias :-)

I thought I should check that:

1) people think it looks like a sensible fix and improvement
2) if (1) then whether I should delete  MAFileModel>>#url (and friends), deprecate them, or leave them as is.

Thanks

Nick

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

Re: serving stylesheets

Lukas Renggli
> However pondering the problem I've prototyped a solution in which PRFile
> have a custom view component "PRFileView" which responds with it's
> associated PRFile file directly, rather than delegating
> to MAFileModelHandler. The logic is that, by default, PRFile>>#url responds
> with a fully qualified path to itself within the pier structure
> e.g. /pier/template/style.css then PRFileView>>#initialRequest checks the
> request to see if it matches the mime-type of it's associated PRFile's
> mime-type, if so it will respond true to  PRFileView>#isFullResponse and
> serve the file directly in  PRFileView>#respondUsing:

The problem is that like this you cannot easily navigate to the
resource anymore.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

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

Re: serving stylesheets

Nick
The problem is that like this you cannot easily navigate to the
resource anymore.

 PRFileView>#isFullResponse only returns true is the mime-types match. So you can navigate to an image through the web interface as normal as the request mime-type will be text/html and not match the file's mime-type

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

Re: serving stylesheets

Lukas Renggli
Aha, that sounds like a cool trick. Didn't think of that. So go for it.

Lukas

On 2 December 2011 19:49, Nick Ager <[hidden email]> wrote:

>> The problem is that like this you cannot easily navigate to the
>> resource anymore.
>
>
>  PRFileView>#isFullResponse only returns true is the mime-types match. So
> you can navigate to an image through the web interface as normal as the
> request mime-type will be text/html and not match the file's mime-type
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki



--
Lukas Renggli
www.lukas-renggli.ch

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

Re: serving stylesheets

Nick
I've checked in the changes. After some more testing more I found that stylesheet requests for files are unhelpfully for mime-type "*/*" so I modified PRFileView to  assume a #isFullResponse by default unless the request is a mime-type of WAMimeType textHtml.

On 2 December 2011 19:07, Lukas Renggli <[hidden email]> wrote:
Aha, that sounds like a cool trick. Didn't think of that. So go for it.

Lukas

On 2 December 2011 19:49, Nick Ager <[hidden email]> wrote:
>> The problem is that like this you cannot easily navigate to the
>> resource anymore.
>
>
>  PRFileView>#isFullResponse only returns true is the mime-types match. So
> you can navigate to an image through the web interface as normal as the
> request mime-type will be text/html and not match the file's mime-type
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki



--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
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