fix to cookie link issue Sergio raised on the Pier mailing list:* http://permalink.gmane.org/gmane.comp.lang.smalltalk.smallwiki/5271* http://permalink.gmane.org/gmane.comp.lang.smalltalk.smallwiki/5275Caused by a change I made to "fix" multiple PRContextFilters on the session.

extracted #exampleDocumentationKernel from PRPierFrame>>#exampleDocument

Aggregate view only displays children which answer true to #isPublication.Fixes a bug when there is a comment on a book portion

merge

changed PROrderCommand label changed from "order" to "re-order children" to be more intension revealing.

merged

- throw an error if accept method is not implemented

changed BOAggregateView label to: 'Aggregate View'

only display edit if user has editing permissions

added an aggregated view. From the class comments for BOAggregatedView:I display my own structure and all my child structures if I answer true to #isPublication. I format publication numbers as the default book template. I provide an edit link for each child structure.

added additional information about value structure links

upaded:package: 'Pier-Seaside' with: 'Pier-Seaside-NickAger.524';

multiple refactorings:PREmbeddedRenderer>>#visitFileImagenow retrieves the url from the PRFile structure rather than the embedded file. This allows the PRFile through PRFileView to serve the file directly.PRFileView extracted #isHtmlRequest: from #initialRequest:PRPierFrame>>#initialRequest: modified so that only one PRContextFilter can be added for a session.

updated: package: 'Pier-Model' with: 'Pier-Model-NickAger.418';

refactoring from previous check-in.Clearly I wasn't thinking straight; I added #url: which looks like a setter, so I renamed the method to a more intention revealing: #urlFromFileStructure:

added comment to PRFileView

updated: package: 'Pier-Model' with: 'Pier-Model-NickAger.417'; package: 'Pier-Seaside' with: 'Pier-Seaside-NickAger.522';

more fixes for change described in: Pier-Seaside-NickAger.519PRFileView now assumes a #isFullResponse if the request isn't a mime-type of WAMimeType textHtml.It no longer compares against the mime-type of the file as I found that stylesheet requests for files are unhelpfully for mime-type "*/*"

extra fixes for Pier-Seaside-NickAger.520

change described in mail to Pier mailing list: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: handlerWhich 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=PRDownloadViewHowever 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=PRDownloadViewFrom Lukas:The problem is that like this you cannot easily navigate to theresource anymore.Answer:PRFileView>#isFullResponse only returns true if 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.