Forum OpenACS Development: Re: Wiki modifications for mediawiki format

Collapse
Posted by Gustaf Neumann on
Thank you for the nice words about xowiki. Conceptually includes {{...}} are a more powerful construct than links [[...]], since every include can return an HTML link markup.

We could easily use {{link WIKIPAGE -label "Some Label"}} as long-form for [[WIKIPAGE|Some Label]]. Similarly, we could use {{start sidebar}} instead of >>sidebar<<. so, one construct could be sufficient.

So, i am not sure, whether links with an "image:" prefix is currently the best way to go. The image could come from different sources, from the filestore, icons, or photo-album, it can be linked or included. so, unless we have a canonical way to refer to images/files/news articles/... it seems better to me to use the include syntax and provide a small adp-file if needed, such as e.g.

{{adp photo joe.jpg album album1}}

Still, the nicer way to handle images is via an image selector, that has some of this logic built in. We have developed an image selector plugin for xinha for our elearning application learn@wu, which could be extended this way. i will give it a closer look soon. This has the advantage that it is more straight-forward for a end-user, it is more wysiwyg, and there is no need to handle all HTML image options via the include syntax. The disadvantage is a bigger dependence on the richtext package.

Similarly, for categories, i would like to have a adp-snippet that handles this instead of extending the syntax of [[...]]. Categories can be used for many things loke for example for structuring a book with chapters, where pages are wiki-pages and the menu-structure comes from categories. We use in learn@wu our own category system to build a "concept space" containing text-pages and exercises etc for every lecture unit. It would be interesting to experiment with this by using the oacs categories as sketched...

i am not sure what you have implemented in detail, but certainly, all contributions to xowiki are welcome.

Collapse
Posted by Brian Chapados on
I realize that includes {{...}} are indeed more flexible/powerful for integrating and rendering different types of content. Clearly, [[page|label]] could be short for {{link page -label "label"}}. As soon as I saw the demo page, I knew you had nailed the problem.

What I'm having a hard time wrapping my head around is whether the {{...}} syntax provides an easy way to relate the included item to the wiki page. There will certainly be cases where you don't need that functionality, but if you want to render a different type of cr_item, such as an image, it would be nice to have a way to setup a cr_relationship between the page and the image. I noticed that you're using an xowiki_references table to store page references. In the wiki package, Dave B. created cr_item relationships to do this. I'm not sure which way is better, but xowiki seems to be more robust in terms of handling page references right now.

Anyway, my point is that the link [[...]] construct implies a relationship between the page and the linked item, thus using the [[image:myimage.jpg]] might be a convenient way to achieve this. Your code for handling references already supports a link_type attribute. Using [[linktype:item_name|options]] can be implemented so that it ultimately resolves to {{adp /adp/stub/for/linktype item_name -options options}} to generate HTML for the item. The difference would be that the [[...]] construct creates a relationship. Alternatively, I suppose you could just add a -link or -relate option to the {{adp ...}} syntax, which would do the same thing.

Also, I have mixed feelings about WYSIWYG editors. I understand that people like them, however, for composing anything other than simple documents, I find them annoying. I especially hate them for any application where you need to insert several graphics into a document. I use latex when possible to write papers/protocols/technical documents, ect.. So, I like the idea of the xowiki supporting some type of _optional_ text markup system. I'm guessing that there might be others (though maybe a small percentage) that feel the same way. It occurred to me that much of the formatting for mediawiki (or any wiki really) could be handled by a proc such as:

ad_html_text_convert -from text/wiki

We could just add support for a text/wiki type. It would render everything except links [[...]], includes {{...}} and div &gt;&gt;...&lt;&lt; markups. This might be the best way to add support for using wiki markup in xowiki.