zwiki.org WikiAcquisition

home contents changes issues index options help subscribe edit

What are some kinds of acquisition/inheritance/transclusion-type behaviours that might be useful in the wacky world of wiki?

See also:

SubWiki - A SubWiki is a (almost) complete wikiweb in a wikiweb.
InterWiki -
WikiAcquisitionArchive - original content of this page
AcquisitionProblems

Fundamental issues:

Acquisition is a feature of Zope. ZWiki picks up this behaviour for free. It is of big helpfulness, especially in the usage of SubWikis (see that page for instructions how to start one). - In the SubWiki, you can reference pages from the ParentWiki. All links will work. (But the parent wiki's pages will for logical reasons not appear in AllPages or when searching)
Acquiring other ZopeObject?-s is possible. Eg a DtmlMethod? representing a standard chunk of content, standard_wiki_header/footer/page, etc. This should be useful for someone who wants to maintain multiple distinct wiki webs (a FreeHosting) which share some consistency.
Acquisition over the web (WikiTransclusion): Automatically search a remote wiki, or a chain of remote wikis, for a page which doesn't exist locally. Retrieve a particular page or a chunk of content from another site, specified in the page markup. eg FrontPage - See also IncludeOrTransclude.
Acquisition of page style: (by JJ) I've made a page_style property on a Wiki page. When the page gets rendered, if it has that property, that text is included in a section in the header. This part I have working now. But what I really want is for children (i.e. wiki children) to inherit style of their parents. Haven't got that working yet. Not sure if this all makes sense, but it is something I want to try. --JJ - Is this meant to be in the same WikiWebLevel? ?
Acquisition of DtmlMethods?: (from an unknown user) In updating my RecentChanges? to the current, I don't want to go about changing each SubWiki version (Can't inherit such pages like RC, AllPages) with every new change. My solution was to put the RecentChanges? code into a DtmlMethod? in the ParentWiki (or root) with a name like recentchangesdtml and replace the contents of every RecentChanges? page with '< dtml-var recentchangesdtml>' . Next time I want to update I just change the DtmlMethod? and all the changes will be inherited. - (Another alternative is to grab the contents of the parent pages page, and then process and render those on the current page...but that's too mystical for me at the moment, and doesn't sound as fast.) - from SubWikiDiscussion, 02-12
RemoteWikiURL-s are inherited, the pages containing the RemoteWikiLinks are acquisited: RemoteWikiLinks work usually by default in the SubWiki. This is comfortable when migrating many pages from the ParentWiki to a new SubWiki.

There are several possibilities to handle the situation, when there is SomePage? and wiki B inside wiki A: - how many? Three or four?

1. Status quo: In Wiki B SomePage? is presented as a link to an existing page, which triggers the context bug. Wikiusers can not create local SomePage?.

2. Acquisition for wikipages: In Wiki B SomePage? is presented as a link to an existing page, it leads to SomePage? in wiki A. Wikiusers can not create local SomePage?. (If you use pageheaders without context this is the status quo)

3. No acquisition for wikipages: In Wiki B SomePage? is presented as a new page questionmark link. Wikiusers can create local SomePage?. Linking to SomePage? in wiki A can be done by RemoteWikiLinks.

4. WikiMethods?: In Wiki A wikiadmin creates SomePage? as a wikimethod. SomePage? is acquired in wiki B. SomePage? can not be created locally. Acquisition should be working correctly, so that clicking SomePage? leads to SomePage? in A, where it can be edited by wikiusers.

I'd really like to see "No acquisition for wikispaces" to have clean namespaces and "Wikimethods for wikiadmins" to enforce structure in multiwiki sites by setting up wikis in wikis which share badges, remotewikilink pages, search and helppages (realized as wikimethods). - Hey as i think about it, for the moment it might do to have WikiMethod?-s implemented like wikipages but skip the context and preventing wikipages from getting acquired. Ah, no it's only a start as NameSpace? pollutions is caused by simple wikiname detection. I'll be thinking on that...

**[NameSpace]?s**

One has to use separate wikis to realize separate namespaces for the different projects, employees, whatever. On the other hand one want's to factor out some wikipages like those containing remote wikilinks, badges, stuff realizing functionality like useroptions and search.

Notes:

Pages and methods which can be acquired are: StandardWikiHeader?, StandardWikiFooter?, EditForm?, All basic content pages like FrontPage, HelpPage etc. - Pages and methods which have to be copied and adapted in every SubWiki are: RecentChanges? and other -Changes pages, AllPages, etc.
- What you change in the parent standard_wiki_header dtml method WILL BE ACQUIRED AND MUST BE OVERRIDEN IN EVERY CHILD. - Current problems with this such as RecentChanges?, FastChanges?, SearchPage? much be overriden to that the sub-wiki is acted upon, not the parent wiki.
Up to zwiki 0.8.1 acquisition doesn't work with context activated in the standard_wiki_header. It kind of works if you like browsing wikis without context information.
Instead i'd like wikipages not to be acquired. The main point here is, that wikinames shouldn't show up as links (broken at the moment) when there is no wikipage in the wiki. To have the possibility to factor out common pages we shouldn't use standard wikipages but WikiMethods? i think.
Acquisition of DtmlMethods? works fine with zwiki but they are not wikilike at the moment, as you can't edit and render them online.

The main point here is, that wikinames shouldn't show up as links (broken at the moment) when there is no wikipage in the wiki

Nesting ZwikiTracker's may not be a good idea, due to Issue numbering schemes...needs to be tested.

subject:

	( 46 subscribers )