TJ: Time for a new thread on this one.
Clayton wrote on another thread:
The Wiki API allows you to retrieve a page from the Wiki database. You
can do any manipulation you want on that text including scanning for
next and previous sections. That's possible. You could in theory build
a page based on this info... and then "put" it into the wiki.
Issues as I see it with this:
- It's not dynamic. You cannot (at least as far as I know) generate
the TOC on demand usig the WikiBot. The Wikibot could build a page and
save it, essentially mimicking the actions of a person doing the same
tasks, but dynamic... although, there is at least one extension that can
create a dynamic page list...
- You cannot (as it's currently implemented) tell if a next page is a
next top level section, or a next subsection (nested sections).
I'm sure these things can be solved...
it actually might not be best to use a WikiBot, but instead maybe a
custom built extension.
WikiBots basically are used to mimic human actions on the Wiki.. doing
mass moves, changing links or common text in a stack pf pages etc.
Extensions are used to add functionality to the Wiki... and mybe this is
a better route... worth looking more into both possibilites.
C.
Picking an implementation method (please read "bot" as "whatever you
decide should be implemented") might be easier if we consider
work-flows. I'm thinking of:
a) User wants to add a page. (I just did this.)
b) User wants to add a bunch of pages.
c) Admin wants to check TOC links.
d) (There must be others...)
For a), the user is on the "prev" page, and invokes the "creator" bot.
The bot needs two pieces of information: the new page name, and the
relative level. Given these (no idea of UI), the bot begins editing the
new page, with the TOC call filled in, and [category] and {{license}}
added. To the user, this looks like any other editing session. If the
user cancels, it all goes away.
When the user saves, the bot (which has hijacked the Save button! :-)
No, actually, assuming the edit process is modal, the bot merely figures
out, when it gets control back, whether the page has been saved or
canceled) then either goes away, or (assuming the editor will have done
the save, if it's wanted) edits the TOC calls in the previous and next
pages, and adds the name to the TOC. At bot speed, this minimizes the
editing time on the other three pages, and minimizes the time when the
actual linking is out of whack. Plus, of course, doing all these things
and doing them right.
For b), we want to consider a wider range of level parameters than the
a)-case user would generally need. Something like level=[[+|-][0..9]]
would probably do. The bot should be capable of generating <DIV>
statements in the TOC template, too. We might consider some "don't do
this" parameter(s), for things the user has already done off-line.
For c), the bot checks all the page links against the TOC. Some
anomalies we can fix on the spot, some we probably just want to report,
or both.
* If prev and next pages link to a page not listed in the TOC, then we
aren't sure what level it should be there. Add to the TOC as a peer of
the previous page, and report the action.
* If one of the prev or next links (but not both) skips over a page
listed in the TOC, fix that per TOC.
* If a page is in the TOC, but skipped in both links, then we don't know
whether the page is coming or going. Report it. In response, a human
edits the TOC template and:
** deletes a "going away" entry (and the page itself, presumably);
** or, adds a flag ($ as first character on line?) that tells the bot,
"link me". Subsequent bot run adds links and removes flag.
* report anything really anomalous (page has totally different TOC name,
say), and leave it alone.
* check for self-link (TOC call copied and not modified, probably) and
fix per TOC.
* (ad lib. Try to automate anything that keeps getting reported.)
--
T. J. Frazier
Melbourne, FL
(TJFrazier on OO.o)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org
For additional commands, e-mail: dev-h...@documentation.openoffice.org
