Bug in ROSTER plugin?

[opn]

The ACTIVITY plugin does not appear to pickup nested ROSTER references.

See this page for an example:

• http://sites.fedwiki.org/changes-to-the-future.html

[WardCunningham]

If I remember correctly, there is some logic in the plugins to break recursions. Also the Activity and Roster plugins make decisions once, independently of each other. The sequencing of emit and bind calls could be made in two passes, all emits complete before first call to bind. This was always the plan but hasn't been the practice. I also don't think it helps here because the compounded redirection would all be in the same pass.

[paul90]

Part of the problem, if I remember correctly, is that the roster is only looked at by the activity plugin once - so if a roster is only partially loaded the activity plugin will only take what is there, and not notice that other sites are being loaded. A good demo of this is loading a line up containing a roster and active page, such as http://goals.pod.rodwell.me/view/welcome-visitors/view/pod-activity.

[opn]

@paul90 this is the "doesn't load first time" problem. The bug I am talking about means that the Activity plugin will not load the Roster whatever you do - even though the Roster renders fine and is ready and available in the DOM. Take a look at the page in the link to see the issue in the link above - or this link - http://sites.fedwiki.org/view/welcome-visitors/view/changes-to-the-future

It seems a new issue - but maybe I didn't notice it before. Essentially a Roster of a Roster cannot be connected to an activity Plugin as Ward suggests.

[paul90]

The problem appears to be that the roster you are loading goals.pods.wiki.org/goals-for-federated-wiki itself has categories. I suspect this means that the Goals category is empty, at least this is how it looks - if I create a copy of goals-for-federated-wiki, remove the categories from it, and point changes-to-the-future to use it - it works.

I think the desired behaviour should be when loading a roster into another roster that any categories in the roster being loaded should be ignored.

[WardCunningham]

I created a Roster from REFERENCES in what I believe is the @opn style.

http://ward.asia.wiki.org/ward-on-wiki.html

I assume this suffers from the same async reading/rendering limitations at the case that is subject of this issue. Perhaps we could short-circuit some async file handling when the Roster is on the same page as the References it includes. The markup could simply omit the site and slug so that

REFERENCES ward.asia.wiki.org/ward-on-wiki

becomes

REFERENCES

The page has already been fetched to get the Roster. Some sort of logic should be able to suppress further fetches and return the desired list constructed from text on hand.

I haven't worked out exactly what is going wrong and whether this would solve the problem in a useful subset of the cases. Please advise. I understand that the primary goal is to get a drag and drop interface to Roster construction and this would seem to be it.

[paul90]

That would cause a problem when the Roster was dragged off elsewhere.

Maybe rather than blindly loading the page, Roster should check the site/name of the wiki page it is on, and if it matches it can short-circuit the file handling.

As a side note, I don't see any async reading/rendering issues with that page.

[WardCunningham]

You raise a good point about maintaining behavior when moved. There is a static vs. dynamic argument here. What would one expect when forking such a page? What do we want to teach people to expect in order to make the commons more attractive?

Aside: I'm not a fan of the Reference plugin because it is too tightly bound. David uses lots of them so his many sites are all really just one big site that won't come apart.

What if we added the optimization you suggest and offer the two forms of the markup above. Or maybe even add a third form:

REFERENCES ward-on-wiki

that follows the rules of collaborative links.