seaside November 2018

seaside@lists.squeakfoundation.org

16 participants
18 discussions

Re: [Seaside] (Case INST64237) Should WAFileLibrary convert files in #deployFiles?
by jtuchel＠objektfabrik.de 21 Nov '18

21 Nov '18

Hi Mariano, this looks really good - and *works like a charm*! It's already in my req maps structure. And it's much better than my half-baked approach. If this is accepted to go upstream into Seaside, I suggest that deployFiles delegates to this new method, in order to avoid typical DRY problems. deployFiles self deployFilesUsing: ("and here comes the trouble: GRCodec has no code to determine the current codepage/encoding in the image... so maybe utf-8 can be defined as a standard parameter here?") One little comment about method naming: deployFilesEncodingWhen:with: deployFilesUsing: I think the names should be somewhat closer to each other. Some suggestions for change: * deployFilesUsing: and deployFilesUsing:when: (note the changed order of parameters) * deployFilesEncoding: and deployFilesEncoding:when: * deployFilesUsingCodec: and deployFilesUsingCodec:when: I think these are better and make clear that the 2-parameter one is just a variant of the other one. Re: test files. The ones in our code are tons of javascript code with maybe 2 or three Umlauts in them. But they will be added to the DOM and thus are ugly. But for testing you'd have to search a lot of text to spot the umlaut(s)... I guess a good start for testing would be to implement something like this: MyFileLibrary>>umlautTest1Js ^'console.log("ÄÖÜäöüß")'; Once again: thanks a lot for your help and support! It is great having you as a "cleaner" (remember Jacques the cleaner from Nikita?) in the background ;-) Joachim Am 19.11.18 um 17:54 schrieb Instantiations Smalltalk Support: > > Hi Joachim, > > Please find attached a preview of what I have in mind (map > MMP-Incoming). I still need to add comments to every new method as > well as trying to add unit tests for that. But it will give you an > idea of what I did. You can at least browse changes with whatever you > have for 9.1. > > There are basically 2 new methods: #deployFilesUsing: aGRCodec which > automatically adds encoding to the selectors that are NOT binary. You > can use it like this: > > |MyFileLibrary deployFilesUsing: ( GRCodec forEncoding: 'utf8' )| > > In addition, I added #deployFilesEncodingWhen: aBlock with: aGRCodec > (which is called by the previous) in case you want to control when to > apply the encoding. Example: > > |MyFileLibrary | > > | deployFilesEncodingWhen: [:selector :fileLibrary | > (fileLibrary mimetypeOf: selector) isBinary not] > with: aGRCodec| > > There you can plug whatever closure you want that will be culled with > the selector and the file library. > > Thoughts? > > Mariano > > -- > Instantiations Smalltalk Support > vast-support(a)instantiations.com > > -----Original Message----- > From: "Joachim Tuchel" <jtuchel(a)objektfabrik.de> > Reply-To: "Joachim Tuchel" <jtuchel(a)objektfabrik.de> > Date: Mon, 19 Nov 2018 16:09:01 +0100 (CET) > To: "Instantiations Smalltalk Support" <vast-support(a)instantiations.com> > Cc: "Seaside - general discussion" <seaside(a)lists.squeakfoundation.org> > Subject: Re: (Case INST64237) Should WAFileLibrary convert files in > #deployFiles? > > >Hi Mariano, > > > >> Instantiations Smalltalk Support <vast-support(a)instantiations.com> > hat am 19. November 2018 um 14:55 geschrieben: > >> > >> > >> Hi Joachim, > >> > >> Thanks for keep finding and reporting encoding issues. > >> > > > >I keep enjoying them and like to share the goodness ;-) > > > >> > >> Hopefully we will have less and less :)ra > >> > >> > >> > > > >You are definitely on track. We've moved to our new server and most > of our special character issues are now a thing of the past... > Actually this one is the last I currently know of and I am glad about > it. I am also glad I know of at least two ways to solve this, even if > the fixes don't end up in any shipped product. > > > >> > >> I agree and I understand everything you said. > >> > > > >Please keep this sentence for later use. I like it ;-) > > > >> > >> > >> > >> The main problem here is what I said... as Pharo is UTF-8 by > default, Seaside has some assumptions that's the case for everybody > everywhere. I dare to say that if you use a different encoding in > Pharo (if that's even possible) Seaside will have troubles in there too. > >> > > > >I was guessing that this is not an issue for Pharo-Seasiders. Good > for them ;-) > > > >> > >> Anyway... the specific problem is that at the WAServerAdaptor level > we KNOW which encoding has been specified and so we delegate to the > specified encoder. The usage of the #deployFiles as you said, it's in > a completely different moment where you cannot guess anything. You > cannot guess which encoding you will specify in the external web > server. That's why I am against the change in #write:toFile:inFolder:. > >> > > > >Yes, this was my feeling as well. Not so much the place > (write:toFile:inFolder: is in Grease anyways), but because it misses a > parameter, namely the charset to convert to. I think we both agree > that converting EVERY file to UTF-8 is not a good idea, and there are > many imaginable reasons for even not every non-binary file. So my > suggestion is only covering my case, not a general case. I wouldn't > even dare to call my case an 80% case. > > > >> > >> What I propose (and this would work also for the VAST port if > upstream Seaside does not want to incorporate it) is to add a new > implementations: #write:toFile:inFolder:encoder: and > #deployFilesUsing: anEncoder. Of course, the later passes by the > encoder to the former. That way, the developer (that knows and decides > which encoding to use in the external web server) can do something > like this: > >> > >> MyFileLibrary deployFilesUsing: *GRCodec named: 'UTF-8') > >> > > > >Sounds much better, and still misses a way to give control over the > conversion up to #deployFiles: > > > >> > >> Again, we could add these new methods as extension methods of VAST > apps. > >> > >> What I don't like is the way to distinguish whether to encode or > not. The "isString" is weak because at that level of Grease I might > provide a text but as ByteArray and that I would like to encode it. I > guess I would prefer the FileLibrary to determine wether to encode or > not based on the type of file being served. For example, imagine if in > #deployFilesUsing: we can do something like this: > >> > >> deployFiles > >> "Write to disk the files that the receiver use to serve as methods. > >> The files are stored in a subfolder named like the classname of the > receiver in a subfolder of Smalltalk image folder." > >> GRPlatform current ensureExistenceOfFolder: self name. > >> self fileSelectors do: [ :each | > >> GRPlatform current > >> write: (self perform: each) > >> toFile: (self asFilename: each) > >> inFolder: self name > >> encoding: (( self mimetypeOf: each ) isBinary ifTrue: [nil] > ifFalse: [ GRCodec named: 'UTF-8' ]) > >> ] > >> > >> > >> > > > >man, the mimetypeOf: was what I was actually looking for. It still > wildly guesses on the mimetype and all it has available for it is the > filename extension, but that's much better than isString. Absolutely > agreed. > > > >> > >> That way, on Grease level, if we receive a nil encoding we do > nothing. If we receive non nil, we do encode. And we let the caller to > decide whether to encode or not rather than deciding on a "isString". > >> > >> Thoughts? > >> > > > >My gut feeling says we're at the end of the road, because nobody else > will care. I would love to see your suggested implementation > incorporated in VAST, but don't think it will be accepted by the > Seaside devs. OTOH, maybe my assumptioons about this are wrong. > > > >Do you have a channel for pushing changes back? I haven't heard > anything about this from anybody on my blog or the mailing list... > > > >Joachim > > > >> > >> Mariano > >> > >> -- > >> Instantiations Smalltalk Support > >> vast-support(a)instantiations.com > >> > >> >

1 0

Seaside One-Click Experience 3.1 – crashes on macOS
by Jiri R. 20 Nov '18

20 Nov '18

Hi, Is there another way to run Seaside on mac than the One-Click Experience? 1. Download: http://files.pharo.org/seaside/Seaside-3.1-portable.zip Seaside One-Click Experience 3.1 2. Open "Seaside-3.1-portable" –> A window titled "Pharo 4.0 ... <something>" filled with black briefly appears than disappears and there is no sign (i.e. dock icon) of Seaside running. Jiri

2 3

Re: [Seaside] (Case INST64237) Should WAFileLibrary convert files in #deployFiles?
by Joachim Tuchel 19 Nov '18

19 Nov '18

Hi Mariano, > Instantiations Smalltalk Support <vast-support(a)instantiations.com> hat am 19. November 2018 um 14:55 geschrieben: > > > Hi Joachim, > > Thanks for keep finding and reporting encoding issues. > I keep enjoying them and like to share the goodness ;-) > > Hopefully we will have less and less :)ra > > > You are definitely on track. We've moved to our new server and most of our special character issues are now a thing of the past... Actually this one is the last I currently know of and I am glad about it. I am also glad I know of at least two ways to solve this, even if the fixes don't end up in any shipped product. > > I agree and I understand everything you said. > Please keep this sentence for later use. I like it ;-) > > > > The main problem here is what I said... as Pharo is UTF-8 by default, Seaside has some assumptions that's the case for everybody everywhere. I dare to say that if you use a different encoding in Pharo (if that's even possible) Seaside will have troubles in there too. > I was guessing that this is not an issue for Pharo-Seasiders. Good for them ;-) > > Anyway... the specific problem is that at the WAServerAdaptor level we KNOW which encoding has been specified and so we delegate to the specified encoder. The usage of the #deployFiles as you said, it's in a completely different moment where you cannot guess anything. You cannot guess which encoding you will specify in the external web server. That's why I am against the change in #write:toFile:inFolder:. > Yes, this was my feeling as well. Not so much the place (write:toFile:inFolder: is in Grease anyways), but because it misses a parameter, namely the charset to convert to. I think we both agree that converting EVERY file to UTF-8 is not a good idea, and there are many imaginable reasons for even not every non-binary file. So my suggestion is only covering my case, not a general case. I wouldn't even dare to call my case an 80% case. > > What I propose (and this would work also for the VAST port if upstream Seaside does not want to incorporate it) is to add a new implementations: #write:toFile:inFolder:encoder: and #deployFilesUsing: anEncoder. Of course, the later passes by the encoder to the former. That way, the developer (that knows and decides which encoding to use in the external web server) can do something like this: > > MyFileLibrary deployFilesUsing: *GRCodec named: 'UTF-8') > Sounds much better, and still misses a way to give control over the conversion up to #deployFiles: > > Again, we could add these new methods as extension methods of VAST apps. > > What I don't like is the way to distinguish whether to encode or not. The "isString" is weak because at that level of Grease I might provide a text but as ByteArray and that I would like to encode it. I guess I would prefer the FileLibrary to determine wether to encode or not based on the type of file being served. For example, imagine if in #deployFilesUsing: we can do something like this: > > deployFiles > "Write to disk the files that the receiver use to serve as methods. > The files are stored in a subfolder named like the classname of the receiver in a subfolder of Smalltalk image folder." > GRPlatform current ensureExistenceOfFolder: self name. > self fileSelectors do: [ :each | > GRPlatform current > write: (self perform: each) > toFile: (self asFilename: each) > inFolder: self name > encoding: (( self mimetypeOf: each ) isBinary ifTrue: [nil] ifFalse: [ GRCodec named: 'UTF-8' ]) > ] > > > man, the mimetypeOf: was what I was actually looking for. It still wildly guesses on the mimetype and all it has available for it is the filename extension, but that's much better than isString. Absolutely agreed. > > That way, on Grease level, if we receive a nil encoding we do nothing. If we receive non nil, we do encode. And we let the caller to decide whether to encode or not rather than deciding on a "isString". > > Thoughts? > My gut feeling says we're at the end of the road, because nobody else will care. I would love to see your suggested implementation incorporated in VAST, but don't think it will be accepted by the Seaside devs. OTOH, maybe my assumptioons about this are wrong. Do you have a channel for pushing changes back? I haven't heard anything about this from anybody on my blog or the mailing list... Joachim > > Mariano > > -- > Instantiations Smalltalk Support > vast-support(a)instantiations.com > > -----Original Message----- > From: "jtuchel(a)objektfabrik.de" <jtuchel(a)objektfabrik.de> > Reply-To: "jtuchel(a)objektfabrik.de" <jtuchel(a)objektfabrik.de> > Date: Sat, 17 Nov 2018 06:33:43 +0100 > To: "Seaside - general discussion" <seaside(a)lists.squeakfoundation.org> > Subject: Should WAFileLibrary convert files in #deployFiles? > > >Hi, > > > >I am not sure whether this topic is of interest to anybody not on VA > >Smalltalk. Let me just explain my problem: > > > >VA Smalltalk is not (yet) natively UTF-8. So when you edit code in the > >Smalltalk Browser, it is encoded in the local codepage. In my case this > >is iso-8859-15. Seaside code and file library contents are served using > >a server adaptor. In VAST, this adaptor converts between UTF-8 for > >everything going to or coming from the Browser and the native code page. > >Not sure if this is the case on Pharo, Squeak or VW as well, but I guess so. > > > >So as long as you server the files from the Smalltalk image, special > >characters in, say javascript files, will be converted to UTF.8 when > >delivered to the Browser. > > > >The trouble starts when you use #deployFiles to have the files served by > >a web server (apache, nginx etc.). WAFileLibrary doesn't convert the > >files before writing them to the filesystem. > > > >I hacked GRVASTPlatform to handle this: > > > >write: aStringOrByteArray toFile: aFileNameString inFolder: aFolderString > > "Writes @aStringOrByteArray to a file named @aFilenameString in > > the folder @aFolderString." > > > > | fullFilePath streamstr| > > > > fullFilePath := CfsPath fromParts: (Array with: aFolderString with: aFileNameString). > > stream := fullFilePath newReadWriteStreamBinary: aStringOrByteArray isString not. > > > > str := aStringOrByteArray isString ifTrue: [aStringOrByteArray > >convertToCodePage: 'UTF-8'] ifFalse: [aStringOrByteArray]. [ stream nextPutAll:str ] > > ensure: [ stream close ] > > > >The idea is that if teh contents of a method is not binary (like .png or > >.gif etc.), it most likely wants to be in UTF-8 on the file system. > > > >I am not sure, however, if the Grease layer is the right place for this. > >What if other users do not want the files converted to UTF-8. I am also > >not sure if it is okay to convert everything non-binary to UTF-8. Maybe > >there should be a way to tell a Library which codepage to convert to, or > >maybe it is desired to be able to decide for every file individually, or > >maybe even something else. > > > >And, I am not even sure if this is even necessary on other platforms. > >That's why I post here first and ask for comments/discussion. > > > >More on this topic: > >https://joachimtuchel.wordpress.com/2018/11/16/seaside-file-libraries-and-u… > > > >Joachim >

1 0

Update on SeasideDoc
by gettimothy 18 Nov '18

18 Nov '18

Quick update on SeasideDoc I am working on the presentation of the existing Help system. The instances of ClassBasedHelpTopic present their pages just fine providing those pages are method accessors or other ClassBasedHelpTopics. They blow up when the page is not a ClassBasedHelpTopic. See http://menmachinesmaterials.com/SeasideDoc/ -> Help Topics ->Help on Help for example. The existing Help system has other FooHelpTopic things...all subclasses of AbstractHelpTopic and a ClassBasedHelpTopic such as SqueakHelp etc can contain pages or sub classes of these types. AbstractHelpTopic subclasses {ClassAPIHelpTopic . MethodListHelpTopic . PackageAPIHelpTopic . ClassBasedHelpTopic . HtmlHelpTopic . SearchTopic . HelpTopic . DirectoryBasedHelpTopic . FileBasedHelpTopic} So, my task is to create and render 'doclets' that handle those various 'FooHelpTopic' classes. cheers. tty

1 0

Should WAFileLibrary convert files in #deployFiles?
by jtuchel＠objektfabrik.de 17 Nov '18

17 Nov '18

Hi, I am not sure whether this topic is of interest to anybody not on VA Smalltalk. Let me just explain my problem: VA Smalltalk is not (yet) natively UTF-8. So when you edit code in the Smalltalk Browser, it is encoded in the local codepage. In my case this is iso-8859-15. Seaside code and file library contents are served using a server adaptor. In VAST, this adaptor converts between UTF-8 for everything going to or coming from the Browser and the native code page. Not sure if this is the case on Pharo, Squeak or VW as well, but I guess so. So as long as you server the files from the Smalltalk image, special characters in, say javascript files, will be converted to UTF.8 when delivered to the Browser. The trouble starts when you use #deployFiles to have the files served by a web server (apache, nginx etc.). WAFileLibrary doesn't convert the files before writing them to the filesystem. I hacked GRVASTPlatform to handle this: write: aStringOrByteArray toFile: aFileNameString inFolder: aFolderString "Writes @aStringOrByteArray to a file named @aFilenameString in the folder @aFolderString." | fullFilePath streamstr| fullFilePath := CfsPath fromParts: (Array with: aFolderString with: aFileNameString). stream := fullFilePath newReadWriteStreamBinary: aStringOrByteArray isString not. str := aStringOrByteArray isString ifTrue: [aStringOrByteArray convertToCodePage: 'UTF-8'] ifFalse: [aStringOrByteArray]. [ stream nextPutAll:str ] ensure: [ stream close ] The idea is that if teh contents of a method is not binary (like .png or .gif etc.), it most likely wants to be in UTF-8 on the file system. I am not sure, however, if the Grease layer is the right place for this. What if other users do not want the files converted to UTF-8. I am also not sure if it is okay to convert everything non-binary to UTF-8. Maybe there should be a way to tell a Library which codepage to convert to, or maybe it is desired to be able to decide for every file individually, or maybe even something else. And, I am not even sure if this is even necessary on other platforms. That's why I post here first and ask for comments/discussion. More on this topic: https://joachimtuchel.wordpress.com/2018/11/16/seaside-file-libraries-and-u… Joachim

1 0

[ANN] Camp Smalltalk 2019 in Charlotte, NC
by Mariano Martinez Peck 14 Nov '18

14 Nov '18

Greetings Fellow Smalltalkers, We would like to invite you to Camp Smalltalk, March 29th – March 31st 2019 in Charlotte, North Carolina. Event details and registration info are available at the following link: Camp Smalltalk Charlotte 2019 <https://www.eventbrite.com/e/camp-smalltalk-charlotte-2019-tickets-52380940…> Hope to see you there! -- Mariano

1 0

Any advice on URL to component mapping before I dive in?
by gettimothy 12 Nov '18

12 Nov '18

Good morning. Thanks to the folks who wrote the Twitter Bootstrap, I figured out how to change the URL so that the URL reflects the current path in the application. For example, like this: http://menmachinesmaterials.com/zurb/BuildingBlocks/Containers/CSSMasonryGr… However, that URL WILL NOT take you directly to the component. That is what I would like to implement. The Seaside Book appears to touch on this with their REST Services section, so I have that to go on. I figured I would ask the board before I tackled this task. Thank you in advance. tty

2 1

Deprecation of #registerAsApplication:
by Tim Johnson 02 Nov '18

02 Nov '18

Hi, Just wondering about the deprecation of #registerAsApplication: which I think took place during the refactor of WASession and/or WAApplication. This method is still the #1 answer on the Seaside FAQ: http://www.seaside.st/documentation/faq/how-to ...and still featured in two sections of the canonical documentation: http://book.seaside.st/book/getting-started/gemstone/developing-component/r… http://book.seaside.st/book/getting-started/cincom-smalltalk/component/regi… Is there a way to contribute changes to documentation? Thanks, Tim

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

seaside November 2018