Development
What’s new in the repository
You can subscribe to the RSS of our repository at:
Recent Commits
- Pier-Seaside-NickAger.526.mcz 23 January 2012fix 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.
- Pier-Seaside-NickAger.525.mcz 19 January 2012extracted #exampleDocumentationKernel from PRPierFrame>>#exampleDocument
- Pier-Book-NickAger.155.mcz 20 December 2011Aggregate view only displays children which answer true to #isPublication.Fixes a bug when there is a comment on a book portion
- Pier-Model-NickAger.421.mcz 16 December 2011merge
- Pier-Model-NickAger.420.mcz 16 December 2011changed PROrderCommand label changed from "order" to "re-order children" to be more intension revealing.
- Pier-Model-lr.420.mcz 7 December 2011merged
- Pier-Model-lr.417.mcz 7 December 2011- throw an error if accept method is not implemented
- Pier-Book-NickAger.154.mcz 6 December 2011changed BOAggregateView label to: 'Aggregate View'
- Pier-Book-NickAger.153.mcz 6 December 2011only display edit if user has editing permissions
- Pier-Book-NickAger.152.mcz 5 December 2011added 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.
- Pier-Model-NickAger.419.mcz 5 December 2011added additional information about value structure links
- ConfigurationOfPier2-NickAger.41.mcz 5 December 2011upaded:package: 'Pier-Seaside' with: 'Pier-Seaside-NickAger.524';
- Pier-Seaside-NickAger.524.mcz 5 December 2011multiple 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.
- ConfigurationOfPier2-NickAger.40.mcz 3 December 2011updated: package: 'Pier-Model' with: 'Pier-Model-NickAger.418';
- Pier-Model-NickAger.418.mcz 3 December 2011refactoring 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:
- Pier-Seaside-NickAger.523.mcz 3 December 2011added comment to PRFileView
- ConfigurationOfPier2-NickAger.39.mcz 2 December 2011updated: package: 'Pier-Model' with: 'Pier-Model-NickAger.417'; package: 'Pier-Seaside' with: 'Pier-Seaside-NickAger.522';
- Pier-Seaside-NickAger.522.mcz 2 December 2011more 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 "*/*"
- Pier-Seaside-NickAger.521.mcz 2 December 2011extra fixes for Pier-Seaside-NickAger.520
- Pier-Seaside-NickAger.520.mcz 2 December 2011change 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.