THL Toolbox > Workflow Issues > Sakai Collaborative Worksite Technology > WIKI Publishing
Publishing Wikis In THL
Contributor(s): THL Staff.
Summary
We are using WIKIs as offered within the Sakai environment to build collaborative content. This is especially true for documentation, which generally needs constant updating to be useful and relevant, and content organized in complex hierarchies - such as the Encyclopedias - which requires multiple people to work on the hierarchy as well as its description and content. WIKIs allow for easy online editors by the generators of content themselves, as well as easy generation and revision of hierarchical organization schemes holding the content. In the future, with the implementation of a better WIKI system like TWIKI allowing for WYSIWYG editing and structured functionalitiy, this will become even more true.
For documentation, given the need for constant updates, the relatively informal nature of such documents, and their generally collaborative content, we plan for WIKIs to be the permanent home for such materials. However, scholarly ontologies or topic maps organizing information into complex hierarchies are best suited to publication in XML because of the need for multilingual interfaces, annotations, global updates of structure, metadata, and more. Thus our current plan is to use WIKIs to build the hierarchies and initial content, but then eventually publish in XML-GDMS. We thus need to look into an efficient way to convert a set of WIKI documents into GDMS. Even after publication, however, we will continue to want to use the WIKIs to help create supplemental content, so that we need a model which combines formal GDMS publications with ongoing content creation in WIKIs.
At present, it is simple to "publish" a WIKI so that it has a publicly viewable mode of access through a URL. However, quite a bit remains to be done to make this view user friendly.
How to generate a public URL for a WIKI
Worksite WIKIs can be shown via URL to the public. You have to click on INFO for that WIKI, and then set the permission settings so that the public can "view" the pages. Then hit SAVE. Then go further down that INFO page in the feeds section where it says "Public View". Click on that, and it will open up a second window with the public view of the WIKI. Copy the URL from the browser address line and you have it. This public URL can also be used whether or not you have activated public view, but only by people within a worksite after logging in.
Please note it has settings for the public being able to "update" the page, but these do not work. That will only work if you want to have a link to your add a link to your publicly editable wiki page (that you provide to them) to their wiki that they can view and edit your wiki page from within their own worksite wiki. It doesn't make the "Public View" URL editable. But this seems irrelevant since within worksites its better to use the other protocol (see above) to just incorporate the other worksite's WIKI into the second worksite.
How to incorporate a WIKI into a THL page
Wiki pages can be incorporated into a THL-style page using the <iframe> tag. (See 
an example.) In every other respect, the page contains the standard THL formatting and can be labeled with its own title and breadcrumbs. The page should begin with a <head> (header) element that contains the following:
- a <title> element with the name of the page that will appear at the top of the browser's window.
- a <script> element linking to THDL Scripts
- a <link> element linking to the THL styles
The head is followed by a <body> which itself contains:
- a <script> element loading the banner scripts (/scripts/banner.js)
- the breadcrumbs for the page which are contained in two nested divs <div id="sub_banner"> which contains <div id="breadcrumbs">. (This is the usual formatting for breadcrumbs in THL.)
- and finally, the main div with its class set to "text-heavy" (<div id="main" class="text-heavy">).
Within this main div, one includes a single <iframe> element with the following attributes:
- align="top" (keeps the frame at the top of the page)
- frameborder="0" (no border)
- src="https://collab.itc.virginia.edu/access/wiki/site/070b5a99-3720-4b1c-00f9-cd26322508a4/home.html" (the source of the frame's content)
- width="700" (set to the average width of a THL page)
- height="2000" (set high to include the longest possible content)
One can view an example of an embedded wiki page.
Problems with Embedded WIKI Pages
- The first issue is that the public view shows the name of the WIKI in a grayed out small font, which is irrelevant. It needs to be suppressed.
- Any link in the internal frame will link to that frame. Thus, when clicked, the content of the frame will change but the title of the window and the breadcrumbs will remain the same.
- It would be good if we could generate a TOC for a given document out of the use of headers (h1, h2, etc.) within a given WIKI document.
- We need some way to be able to look at a public view of a given WIKI, and figure out which worksite it is located in so we can edit if necessary.
To modify the content of the <iframe> or to dynamically adjust its size to match the length of the content will require the use of Javascript. Preliminary attempts at this proved that it is difficult to access frame's source document to change it's content. It is not a straightforward task.