defeat plugin annotation for normal pages

[WardCunningham]

We remove the green halo from about pages that have been forked into normal page space.

Future pull requests will handle client-side adjustments at the moment of fork and ultimately a mechanism for deleting unwanted or accidental forks of about pages.

[paul90]

This resolves the plugin annotation on pages that have already been forked, but it might also be an idea to update the client to remove the plugin key from the page when a plugin page is forked. Might be an idea to add the link back to the plugin to the fork event in the journal.

[paul90]

Published as + wiki-server@0.10.1

[WardCunningham]

I've looked through the client but haven't yet found where the plugin annotation gets cleared on fork. My current theory is that it got lost in a refactoring or perhaps it was never written, only thought about. To refresh my memory I have located the commit that introduced the annotation four years ago.

https://github.com/WardCunningham/Smallest-Federated-Wiki/commit/88225ba78e131348e8a87c3f39e1433d3a9754b0

[WardCunningham]

Everything was in one repo four years ago. The next commit added the green border with very similar mods in three different files: $page.addClass('plugin');

https://github.com/WardCunningham/Smallest-Federated-Wiki/commits/master?after=42c261a63edccadc3478b6fa4137a2b79e35ff58+69

I notice @nrn, @paul90 and I were all committing at the same time back then. I'm going to assume that clearing the annotation on fork was an intention that got forgotten amid lots of other interesting activity.

[paul90]

Think, in the client, the plugin property needs removing at or close to https://github.com/fedwiki/wiki-client/blob/master/lib/pageHandler.coffee#L127

[WardCunningham]

Yes, I think you have it there. Something like this on the next line should take care of it.

delete bundle.item.plugin

I've always thought that there was some sneak path letting that annotation escape but no, it seems there was never an attempt to do the simplest removal.

I will direct my attention to straightening out the pageObject and the dom when this takes place.

[WardCunningham]

You are in a maze of twisty passages.

https://github.com/fedwiki/wiki-client/blob/master/lib/pageHandler.coffee#L173-L191

This code seems overdue for at least some functional decomposition where the cases are more clearly labeled. If the pageObject were made correct here then the getRawPage later wouldn't need modification. There is clearly precedent for munging dom classes for other cases here too.

I can't help but wonder if future siteAdapters will want to participate here too?

[paul90]

You're at brink of pit.

Yes, correcting the page object there would be good. Removing the 'plugin' class will also remove the green halo, that currently persists after the fork.

Should the fork event in the journal include details of which plugin the page was forked from?

[WardCunningham]

I decided to take a break from this code and read further in the pdf I left open last night. I read:

"By forgoing this separation, modelers who fit rate constants to ODE systems risk engaging in an idle encoding exercise rather than a modeling process, since many behaviors can be inscribed into any sufficiently large system of ODEs by appropriate choice of rate parameters."

ODE = Ordinary Differential Equations. This is from a study of cell signaling in biological systems. http://fontana.med.harvard.edu/www/Documents/WF/Papers/signaling.causality.pdf

I might equally write, "many behaviors can be inscribed into any sufficiently large nest of if-statements."

In another conversation earlier in the week a colleague noted that "epicycles" actually did a pretty good job of modeling planetary motions. Except that a sufficiently large nest of epicycles can model pretty much any motion, including square orbits.