Added Disqus comments to the blog today. I imagine they do all sorts of nasty things behind the scenes with cookies and JavaScript. I apologize for that in advance -- though see below. The way I've done it, you'll only get that nastiness if you go to a single-post page by permalink.

Note also that I use the really old version of Blogger where I have my own html theme with some Blogger variables (like <$BlogItemPermalinkURL$>) sprinkled within. Let's just say that the instructions to add Disqus to Blogger are out of date for dinosaurs like me.

Here's what I added to my template. Neat plus: It's not loaded at all on my front page, and since every post is listed in its entirety there, you shouldn't get any Disqus nastiness unless you go to a specific post. That said, I've always kinda liked Disqus as a comment manager, so I hope you'll find it useful.

<!-- Disqus comments -->
<div id="disqus_thread"></div>
<script>
var disqus_config = function () {
    this.page.url = "<$BlogItemPermalinkURL$>";  // Replace PAGE_URL with your page's canonical URL variable
    this.page.identifier = "<$BlogItemNumber$>"; // Replace PAGE_IDENTIFIER with your page's unique identifier variable
};

(function () { // DON'T EDIT BELOW THIS LINE <<< MUAHAHAHAHA!!! I did anyway. Because I needed to.
    if (
        "/" !== window.location.pathname                                // on the home page
        && "" !== window.location.pathname                              // on the home page with IE < 11, _mayhbe_
        && !window.location.pathname.match(/^\/*[0-9]+\/[0-9]+\/*$/)    // archive pages
        && window.location.pathname.indexOf("search") == -1             // tag search pages
    ) {
        var d = document, s = d.createElement('script');
        s.src = 'https://myfreakinname.disqus.com/embed.js';
        s.setAttribute('data-timestamp', +new Date());
        (d.head || d.body).appendChild(s);
    }
})();
</script>
<noscript>Please enable JavaScript to view the <a href="https://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>
<!-- eo Disqus comments -->

Key lines:

this.page.url = "<$BlogItemPermalinkURL$>";  // Replace PAGE_URL with your page's canonical URL variable
this.page.identifier = "<$BlogItemNumber$>"; // Replace PAGE_IDENTIFIER with your page's unique identifier variable

I'm pretty sure those are the Blogger variables you want to use for those two properties.

And then le piece de resistance. Or whatever.

    if (
        "/" !== window.location.pathname                                // on the home page
        && "" !== window.location.pathname                              // on the home page with IE < 11, _mayhbe_
        && !window.location.pathname.match(/^\/*[0-9]+\/[0-9]+\/*$/)    // archive pages
        && window.location.pathname.indexOf("search") == -1             // tag search pages
    ) {   

By adding that check in the shudder area Disqus says not to edit, you make it so that Disqus isn't loaded on your home page (or on archive review pages like this one), which is good, because who wants Disqus on every freaking post on your home page? That'd be lots of wasted space.

Taking the Disqus UI off of posts on the home page of the blog is also good because the UI will only pop up under the first post on the page. That's because Disqus doesn't honor multiple instances of its UI on the same URL. Which leads us into Good Thing #3: Those comments on the first page would forever be for the first post on the home page, which would change from day to day. So it's an important check.

Anyhow, with that info in hand, all you dinosaur Bloggers can add Disqus invasive nastiness to your posts too and enable comments in a manner that's much more mature than all the crap Google and Google+ has tried to pull (and then pull back!) over the years.

Labels: blogger, comments, html

This is a test. Does the preview do live updating? Yes, yes it does.

Labels: blogger, macOS

Good grief folks, can we roll back to the old pyra editor?  I've put the following text into the HTML pane:

filter.first.first.id === '.' &&
filter.first.first.first.first &&
filter.first.first.first.first.string === 'Object' &&

and when I look back in the Compose pane, the &'s from the html are turned into &.  Should the code be &?  Yes.  Should the HTML display in the Compose window be & (with code of &)?  Good heavens no.

Look, I appreciate the work, but between the BlogThis formatting trouble and the "quirks" in the edit page, it's getting close to time to leave blogger (I've been blogging here since 2001).  I spend more time formatting than writing.

Labels: blogger, google fail, JSLint

In the MVC paradigm the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, each specialized for its task. The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). [emph mine]

Essential dependencies between model, view, and controller. (I call this essential because in fact the view and controller do link to each other directly, but developers mostly don't use this fact.)

Communication Within The MVC Triad
...
The Passive Model

In the simplest case, it is not necessary for a model to make any provision whatever for participation in an MVC triad. A simple WYSIWYG text editor is a good example. The central property of such an editor is that you should always see the text as it would appear on paper. So the view clearly must be informed of each change to the text so that it can update its display. Yet the model (which we will assume is an instance of String) need not take responsibility for communicating the changes to the view because these changes occur only by requests from the user. The controller can assume responsibility for notifying the view of any changes because it interprets the user's requests. It could simply notify the view that something has changed -- the view could then request the current state of the string from its model -- or the controller could specify to the view what has changed. In either case, the string model is a completely passive holder of the string data manipulated by the view and the controller. [more mfn emph]

Labels: blogger, code, mvc, noteToSelf

When I edited the post in BlogThis, those br tags with the close slash weren't there. I like the old style Blogger html edit where you were editing HTML directly *EXCEPT* for line breaks, which were inserted for each EOL. So if I hit return, a br was inserted. That's been very hit & miss with the new interface. And if you do insert br tags automatically, which I prefer but didn't expect here, I shouldn't be able to see them later, should I? What happens now? Will more br tags be inserted when I save for each EOL? If not, why not? etc etc

Labels: blogger, Google