<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Mariano,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">this looks really good - and <b>works
like a charm</b>! It's already in my req maps structure. And
it's much better than my half-baked approach.</div>
<div class="moz-cite-prefix">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. <br>
</div>
<div class="moz-cite-prefix">
<pre>
</pre>
</div>
<div class="moz-cite-prefix">
<pre>deployFiles</pre>
</div>
<div class="moz-cite-prefix">
<pre> 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?")</pre>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">One little comment about method naming:</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><font face="Courier New, Courier,
monospace">deployFilesEncodingWhen:with:</font></div>
<div class="moz-cite-prefix"><font face="Courier New, Courier,
monospace"> deployFilesUsing: <br>
</font></div>
<div class="moz-cite-prefix"><br>
</div>
<p>I think the names should be somewhat closer to each other.</p>
<p>Some suggestions for change:</p>
<ul>
<li><font face="Courier New, Courier, monospace">deployFilesUsing:
</font>and <font face="Courier New, Courier, monospace">deployFilesUsing:when:</font>
(note the changed order of parameters)</li>
<li><font face="Courier New, Courier, monospace">deployFilesEncoding:
</font>and <font face="Courier New, Courier, monospace">deployFilesEncoding:when:</font></li>
<li><font face="Courier New, Courier, monospace">deployFilesUsingCodec:</font>
and <font face="Courier New, Courier, monospace">deployFilesUsingCodec:when:</font></li>
</ul>
<div class="moz-cite-prefix">I think these are better and make clear
that the 2-parameter one is just a variant of the other one.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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)...<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I guess a good start for testing would
be to implement something like this:</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><font face="Courier New, Courier,
monospace">MyFileLibrary>>umlautTest1Js</font></div>
<div class="moz-cite-prefix"><font face="Courier New, Courier,
monospace"><br>
</font></div>
<div class="moz-cite-prefix"><font face="Courier New, Courier,
monospace"> ^'console.log("ÄÖÜäöüß")';<br>
</font></div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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 ;-)</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Joachim<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Am 19.11.18 um 17:54 schrieb
Instantiations Smalltalk Support:<br>
</div>
<blockquote type="cite"
cite="mid:00ff3289-337c-4fb2-a120-6662325bbede@hbny4">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<p>Hi Joachim,</p>
<p>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.</p>
<p>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:</p>
<p><code>MyFileLibrary deployFilesUsing: ( GRCodec forEncoding:
'utf8' )</code></p>
<p>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:</p>
<p><code>MyFileLibrary </code></p>
<p><code> deployFilesEncodingWhen: [:selector :fileLibrary
|<br>
(fileLibrary mimetypeOf: selector) isBinary not]<br>
with: aGRCodec</code></p>
<p>There you can plug whatever closure you want that will be
culled with the selector and the file library.</p>
<p>Thoughts?</p>
<p>Mariano</p>
<p>--<br>
Instantiations Smalltalk Support<br>
<a class="moz-txt-link-abbreviated" href="mailto:vast-support@instantiations.com">vast-support@instantiations.com</a></p>
<p>-----Original Message-----<br>
From: "Joachim Tuchel" <a class="moz-txt-link-rfc2396E" href="mailto:jtuchel@objektfabrik.de"><jtuchel@objektfabrik.de></a><br>
Reply-To: "Joachim Tuchel" <a class="moz-txt-link-rfc2396E" href="mailto:jtuchel@objektfabrik.de"><jtuchel@objektfabrik.de></a><br>
Date: Mon, 19 Nov 2018 16:09:01 +0100 (CET)<br>
To: "Instantiations Smalltalk Support"
<a class="moz-txt-link-rfc2396E" href="mailto:vast-support@instantiations.com"><vast-support@instantiations.com></a><br>
Cc: "Seaside - general discussion"
<a class="moz-txt-link-rfc2396E" href="mailto:seaside@lists.squeakfoundation.org"><seaside@lists.squeakfoundation.org></a><br>
Subject: Re: (Case INST64237) Should WAFileLibrary convert files
in #deployFiles?</p>
<p>>Hi Mariano,<br>
><br>
>> Instantiations Smalltalk Support
<a class="moz-txt-link-rfc2396E" href="mailto:vast-support@instantiations.com"><vast-support@instantiations.com></a> hat am 19. November 2018
um 14:55 geschrieben:<br>
>><br>
>><br>
>> Hi Joachim,<br>
>><br>
>> Thanks for keep finding and reporting encoding issues.<br>
>><br>
><br>
>I keep enjoying them and like to share the goodness ;-)<br>
><br>
>><br>
>> Hopefully we will have less and less :)ra<br>
>><br>
>><br>
>><br>
><br>
>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.<br>
><br>
>><br>
>> I agree and I understand everything you said.<br>
>><br>
><br>
>Please keep this sentence for later use. I like it ;-)<br>
><br>
>><br>
>><br>
>><br>
>> 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.<br>
>><br>
><br>
>I was guessing that this is not an issue for
Pharo-Seasiders. Good for them ;-)<br>
><br>
>><br>
>> 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:.<br>
>><br>
><br>
>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.<br>
><br>
>><br>
>> 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:<br>
>><br>
>> MyFileLibrary deployFilesUsing: *GRCodec named:
'UTF-8')<br>
>><br>
><br>
>Sounds much better, and still misses a way to give control
over the conversion up to #deployFiles:<br>
><br>
>><br>
>> Again, we could add these new methods as extension
methods of VAST apps.<br>
>><br>
>> 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:<br>
>><br>
>> deployFiles<br>
>> "Write to disk the files that the receiver use to serve
as methods.<br>
>> The files are stored in a subfolder named like the
classname of the receiver in a subfolder of Smalltalk image
folder."<br>
>> GRPlatform current ensureExistenceOfFolder: self name.<br>
>> self fileSelectors do: [ :each |<br>
>> GRPlatform current<br>
>> write: (self perform: each)<br>
>> toFile: (self asFilename: each)<br>
>> inFolder: self name<br>
>> encoding: (( self mimetypeOf: each ) isBinary ifTrue:
[nil] ifFalse: [ GRCodec named: 'UTF-8' ])<br>
>> ]<br>
>><br>
>><br>
>><br>
><br>
>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.<br>
><br>
>><br>
>> 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".<br>
>><br>
>> Thoughts?<br>
>><br>
><br>
>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.<br>
><br>
>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...<br>
><br>
>Joachim<br>
><br>
>><br>
>> Mariano<br>
>><br>
>> --<br>
>> Instantiations Smalltalk Support<br>
>> <a class="moz-txt-link-abbreviated" href="mailto:vast-support@instantiations.com">vast-support@instantiations.com</a><br>
>><br>
>></p>
</blockquote>
<p><br>
</p>
</body>
</html>