
|
[dokuwiki]
||
[Date Prev]
[05-2007 Date Index]
[Date Next]
||
[Thread Prev]
[05-2007 Thread Index]
[Thread Next]
[dokuwiki] XSLT Plugin
- From: "Gabriel Birke" <Gabriel.Birke@xxxxxxxxx>
- To: <dokuwiki@xxxxxxxxxxxxx>
- Date: Thu, 3 May 2007 12:30:54 +0200
Hello!
For our DokuWiki installation there has been the need to display the content
of uploaded OpenOffice spreadsheets directly in the Wiki. I am in the
process of writing a syntax plugin that reads an XML file (that can also be
inside a zip file like OO documents are), applies an XSLT Stylesheet to it
and then displays the output. The XML and XSL files can be uploaded with the
media manager. The Wiki syntax looks like this:
{{xslparse file=knowledgebase:tables:spreadsheet1.odt#content.xml
style=knowledgebase:tables:oo-style.xsl}}
The basic functionality is there, everyone is happy and I would like to give
something back to the great DokuWiki community (a plugin like this has been
requested in the plugin wishlist). But there are a couple of issues I would
like to discuss first:
My first and foremost concern is security: the uploaded XSL style sheet can
contain JavaScript, so this is a huge security risk for people who allow
uploads. It upens up the wiki for all kinds of XSS and CSRF attacks. In our
case this is no problem (only a handful of trusted people has upload
permission) and the ability to script is considered a feature (we are
emulating the tabs found in spreadsheets). But should a plugin like this
made public (even if it has a huge warning sign)?
The next issue is deleting the xml or xsl file in the media manager. The
search_reference function doesn't capture the file references. My approach
to this problem would be a new event inside search_reference that gives
action plugins the ability to expand the regular expression that searches
for file references. I am not quite sure what the event name should be, I am
thinking of SEARCH_REGEX_REFERECE or SEARCH_MEDIA_REFERENCE. Any other
suggestions for event names? Or other suggestions on how to solve this issue
with other means than a new event?
Another issue is caching: My approach was an action plugin that handles
PARSER_CACHE_USE events (only for xhtml mode). The handler loads the file
text, looks for my xslparse tag and if the tag is found, the files are added
to $event->data->depends['files']. I have a bad feeling about the
performance of this approach, since the page text is now loaded and
processed on every request - that goes a bit against the spirit of caching.
Any suggestions for a better approach? Perhaps it is possible to write some
plugin-specific flags to the metadata of a page?
A welcome but not necessary feature would be the ability to search for the
file contents. I have no idea on how to implement this.
Greetings,
Gabriel
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
|

|