Ciao,
i test the Pier 3.0 into a Gemstone 3.1.0.1 environment. I load the 3.0.3 [ConfigurationOfPier3AddOns] and all seems loaded properly. I configured the default pier instance adding the NAFileUploadConfiguration and setup the relative to the directory on the server for save the image. After login in the pier instance in the traditional mode ( not with pier-admin ) i can update one pier page. When i work with the image support the system don't work fine. I need to change the: PRFileUploadWysiwygEditorBase createUploadedFilepath: method with the code between ****** createUploadedFilepath: filename
| pathroot currentStructure structurePath destinationDirectory pathRootNoTrailingSlash |
pathroot := self application fileuploadPathRoot.
currentStructure := self context structure.
structurePath := currentStructure absolutePath copyReplaceAll: '/' with: GRPlatform current pathSeparator .
pathRootNoTrailingSlash := (FileDirectory on: pathroot) pathName.
destinationDirectory := FileDirectory on: (pathRootNoTrailingSlash, structurePath).
NAExternalFile ensureDirectoryExists: destinationDirectory pathName.
******** "^ (destinationDirectory / filename) pathName"
^( FileDirectory on: (destinationDirectory fullNameFor: filename)) pathName ********* With this change the image is save in the specific directory on the server. Anyone ( if this change are considered right ) can update the relative package ? I have some problem relative to the web request for the image. For now the request <img alt="Pizzaflash.jpg" src="/pier/about/pizzaflash.jpg"> don't work. My thoughts, my goal is that the image is manage directly by the Lighttpd or Apache web server not read by Gemstone environment and response with: PRFileView respondUsing: aResponse | file | file := self context structure file. aResponse binary; cacheForever; contentType: file mimetype seasideMimeType; headerAt: 'Content-Disposition' put: 'inline; filename="' , file filename , '"'; nextPutAll: file contents; respond Any consideration is welcome. Thank, Dario _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Ciao,
I change the: NAExternalFile contents method to: | contents | (FileDirectory on: self filepath )readOnlyFileNamed: self filepath do: [ :stream | stream binary. contents := stream contents ]. ^ contents Now it work fine. Anyone ( if this change are considered right ) can update the relative package ? But my thoughts:
remain live. Any considerations ? Dario _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
In reply to this post by dtrussardi@tiscali.it
Regarding the FileDirectory-related changes it looks like some FileSystem code is sneaking into the Pier-FileUpload-Common-Wysiwyg .. I wouldn't think that FileSsystem code would be considered "Common" ... if it _is_ considered common, then I guess we will have to make a gemstone specific branch of the package ...
Nick, what do you think? Dario, I'm looking into your final issue now ... Dale ----- Original Message ----- | From: [hidden email] | To: "magritte-wiki" <[hidden email]> | Sent: Wednesday, September 26, 2012 8:17:22 AM | Subject: Upload file image for Pier 3.0 into Gemstone 3.1.0.1 environment | | | Ciao, | | | i test the Pier 3.0 into a Gemstone 3.1.0.1 environment. | | | I load the 3.0.3 [ConfigurationOfPier3AddOns] and all seems loaded | properly. | | | I configured the default pier instance adding the | NAFileUploadConfiguration | | | | | and setup the relative Uploaded files path root | | | to the directory on the server for save the image. | | | | | After login in the pier instance in the traditional mode ( not with | pier-admin ) | | | i can update one pier page. | | | When i work with the image support the system don't work fine. | | | I need to change the: | | | PRFileUploadWysiwygEditorBase createUploadedFilepath : method with | the code between ****** | | | | createUploadedFilepath: filename | pathroot currentStructure | structurePath destinationDirectory pathRootNoTrailingSlash | | pathroot := self application fileuploadPathRoot. currentStructure := | self context structure. structurePath := currentStructure | absolutePath copyReplaceAll: '/' with: GRPlatform current | pathSeparator . pathRootNoTrailingSlash := (FileDirectory on: | pathroot) pathName. destinationDirectory := FileDirectory on: | (pathRootNoTrailingSlash, structurePath). NAExternalFile | ensureDirectoryExists: destinationDirectory pathName. | ******** | "^ (destinationDirectory / filename) pathName" | ^( FileDirectory on: (destinationDirectory fullNameFor: filename)) | pathName | | | ********* | | | With this change the image is save in the specific directory on the | server. | | | Anyone ( if this change are considered right ) can update the | relative package ? | | | | | | | I have some problem relative to the web request for the image. | | | For now the request | | | <img alt="Pizzaflash.jpg" src="/pier/about/pizzaflash.jpg"> | | | don't work. | | | My thoughts, my goal is that the image is manage directly by the | Lighttpd or Apache web server | | | not read by Gemstone environment and response with: | | | PRFileView | | | | respondUsing: aResponse | | file | | file := self context structure file. | | aResponse | binary; | cacheForever; | contentType: file mimetype seasideMimeType; | headerAt: 'Content-Disposition' put: 'inline; filename="' , file | filename , '"'; | nextPutAll: file contents; | respond | | | Any consideration is welcome. | | Thank, | | | Dario | | | | | | | _______________________________________________ | 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 |
In reply to this post by dtrussardi@tiscali.it
Dario,
I'm not sure what the problem is here. If I can't add a template correctly, you must understand that I need a little more information to reproduce the problem:) Dale ----- Original Message ----- | From: [hidden email] | To: "Pier and Related Tools Magritte ..." <[hidden email]> | Sent: Wednesday, September 26, 2012 9:29:08 AM | Subject: Re: Upload file image for Pier 3.0 into Gemstone 3.1.0.1 environment | | My thoughts, my goal is that the image is manage directly by the | Lighttpd or Apache web server | | | not read by Gemstone environment and response with: | | | PRFileView >> respondUsing: aResponse | | file | | file := self context structure file. | | aResponse | binary; | cacheForever; | contentType: file mimetype seasideMimeType; | headerAt: 'Content-Disposition' put: 'inline; filename="' , file | filename , '"'; | nextPutAll: file contents; | respond _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
In reply to this post by Dale Henrichs
Hmm, I'm happy to look at this - what do you think the approach should be:
* Create separate Gemstone and Pharo packages isolating file handling differences in each * Use a cross platform file API, if so which one?
* something else I haven't thought of? Thoughts? Nick On 1 October 2012 23:21, Dale Henrichs <[hidden email]> wrote: Regarding the FileDirectory-related changes it looks like some FileSystem code is sneaking into the Pier-FileUpload-Common-Wysiwyg .. I wouldn't think that FileSsystem code would be considered "Common" ... if it _is_ considered common, then I guess we will have to make a gemstone specific branch of the package ... _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Nick,
If you want Pier-FileUpload-Common-Wysiwyg to be truly cross-platform, then I would think a case could be made to add the needed functionality to Grease ... Pier isn't the first project that is facing this issue and it won't be the last ... If for some reason it can't be added to Grease, then it should be split out separately similar to the approach take by Zinc[1][2] and FileTree[3][4]. Another alternative is to continue using FileDirectory and avoid this split altogether. It seems a shame to have to create a bunch of extra indirection for 2 or 3 calls in the code, although if you want to be truly cross-platform then Grease would be the route to go... I will eventually port FileSystem to GemStone, but I am frankly waiting for the api/implementation to settle down... Dale [1] https://github.com/svenvc/zinc/tree/master/repository/Zinc-FileSystem-Legacy.package [2] https://github.com/svenvc/zinc/tree/master/repository/Zinc-FileSystem.package [3] https://github.com/dalehenrich/filetree/tree/pharo2.0/repository/MonticelloFileTree-FileDirectory-Utilities.package [4] https://github.com/dalehenrich/filetree/tree/pharo2.0/repository/MonticelloFileTree-FileSystem-Utilities.package ----- Original Message ----- | From: "Nick Ager" <[hidden email]> | To: "Pier and Related Tools Magritte ..." <[hidden email]> | Sent: Monday, October 1, 2012 11:10:43 PM | Subject: Re: Upload file image for Pier 3.0 into Gemstone 3.1.0.1 environment | | | Hmm, I'm happy to look at this - what do you think the approach | should be: | * Create separate Gemstone and Pharo packages isolating file handling | differences in each | * Use a cross platform file API, if so which one? | * something else I haven't thought of? | | | Thoughts? | | | Nick | | | On 1 October 2012 23:21, Dale Henrichs < [hidden email] > wrote: | | | Regarding the FileDirectory-related changes it looks like some | FileSystem code is sneaking into the Pier-FileUpload-Common-Wysiwyg | .. I wouldn't think that FileSsystem code would be considered | "Common" ... if it _is_ considered common, then I guess we will have | to make a gemstone specific branch of the package ... | | Nick, what do you think? | | | Dario, I'm looking into your final issue now ... | | Dale | | | | ----- Original Message ----- | | From: [hidden email] | | To: "magritte-wiki" < [hidden email] > | | Sent: Wednesday, September 26, 2012 8:17:22 AM | | Subject: Upload file image for Pier 3.0 into Gemstone 3.1.0.1 | | environment | | | | | | Ciao, | | | | | | i test the Pier 3.0 into a Gemstone 3.1.0.1 environment. | | | | | | I load the 3.0.3 [ConfigurationOfPier3AddOns] and all seems loaded | | properly. | | | | | | I configured the default pier instance adding the | | NAFileUploadConfiguration | | | | | | | | | | and setup the relative Uploaded files path root | | | | | | to the directory on the server for save the image. | | | | | | | | | | After login in the pier instance in the traditional mode ( not with | | pier-admin ) | | | | | | i can update one pier page. | | | | | | When i work with the image support the system don't work fine. | | | | | | I need to change the: | | | | | | PRFileUploadWysiwygEditorBase createUploadedFilepath : method with | | the code between ****** | | | | | | | | createUploadedFilepath: filename | pathroot currentStructure | | structurePath destinationDirectory pathRootNoTrailingSlash | | | pathroot := self application fileuploadPathRoot. currentStructure | | := | | self context structure. structurePath := currentStructure | | absolutePath copyReplaceAll: '/' with: GRPlatform current | | pathSeparator . pathRootNoTrailingSlash := (FileDirectory on: | | pathroot) pathName. destinationDirectory := FileDirectory on: | | (pathRootNoTrailingSlash, structurePath). NAExternalFile | | ensureDirectoryExists: destinationDirectory pathName. | | ******** | | "^ (destinationDirectory / filename) pathName" | | ^( FileDirectory on: (destinationDirectory fullNameFor: filename)) | | pathName | | | | | | ********* | | | | | | With this change the image is save in the specific directory on the | | server. | | | | | | Anyone ( if this change are considered right ) can update the | | relative package ? | | | | | | | | | | | | | | I have some problem relative to the web request for the image. | | | | | | For now the request | | | | | | <img alt="Pizzaflash.jpg" src="/pier/about/pizzaflash.jpg"> | | | | | | don't work. | | | | | | My thoughts, my goal is that the image is manage directly by the | | Lighttpd or Apache web server | | | | | | not read by Gemstone environment and response with: | | | | | | PRFileView | | | | | | | | respondUsing: aResponse | | | file | | | file := self context structure file. | | | | aResponse | | binary; | | cacheForever; | | contentType: file mimetype seasideMimeType; | | headerAt: 'Content-Disposition' put: 'inline; filename="' , file | | filename , '"'; | | nextPutAll: file contents; | | respond | | | | | | Any consideration is welcome. | | | | Thank, | | | | | | Dario | | | | | | | | | | | | | | _______________________________________________ | | 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 |
Hi Dale,
Of course Grease is the way to go - wasn't thinking straight - I'll try to look at it in the next few days Cheers Nick
On 2 October 2012 15:18, Dale Henrichs <[hidden email]> wrote: Nick, _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Free forum by Nabble | Edit this page |