<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>