[dokuwiki] Re: Roadmap/Todo, Getting (admin) plugins straight
- From: "Chris Smith" <chris@xxxxxxxxxxxxx>
- To: <dokuwiki@xxxxxxxxxxxxx>
- Date: Wed, 14 Sep 2005 10:57:07 +0100
Hi,
The one point currently under this heading is "avoid including unused JS and
CSS).
... from a week or so ago ...
> -----Original Message-----
> From: dokuwiki-bounce@xxxxxxxxxxxxx
> [mailto:dokuwiki-bounce@xxxxxxxxxxxxx]On Behalf Of Andreas Gohr
> Sent: 05 September 2005 21:12
> Subject: [dokuwiki] Re: Roadmap for next release
>
> On Mon, 5 Sep 2005 21:09:20 +0100
> "Chris Smith" <chris@xxxxxxxxxxxxx> wrote:
>
> > Hi,
> >
> > Some comments ...
> >
> > Related to your plugin specific js/css point. I think there needs to
> > be a way for a plugin to tell dokuwiki that it wants to put code into
> > other parts of the page.
>
> Yes that could solve some of the problems. That would mean my admin
> plugin should use a non-standard named scriptfile and add it itself to
> the head section of the page?
Hows about a pair of functions,
(1) function to allow plugin handle functions to interact with other places
on the current page
prototype: void register_pagecontent($location, $content)
(2) function to allow producers of page output to retrieve any extra output
suitable to their location.
prototype: array retrieve_pagecontent($location)
Broadly speaking these two functions would manage an array of the form
$extra_content[$location][] = $content
Functions that call retrieve_pagecontent should check each array element of
the returned array
- if its a string, simply output that string.
- if its an array, treat the first element as a callback function and the
second element as the data for that function and call the callback function
with that data and the location name.
Locations supported initially would be
CSS links
JS links
My initial thoughts were this could be set up in such a way to be used by
syntax plugins. Thats not really possible without some significant changes.
More information on this is at the bottom of the message so it doesn't
obscure things.
What do you think?
Cheers,
Chris
===========================
Problems for syntax plugins
At present wiki page content is displayed in a one operation. That
operation could be html cache retrieval, instruction cache retrieval +
render instructions, raw wiki page retrieval + instruction generation +
render instructions. If the wiki page is retrieved from the html cache there
is no mechanism for a syntax plugin to affect other parts of the page.
In order to allow syntax plugins to use "extra content" functions would
require:
- another cache for the extra content requirements of the particular wiki
page
- retrieving this cache and adding its contents to the "extra content" data
during act_dispatch
- ensuring retrieve_pagecontent() can recognise data with a call back to a
syntax plugin and load that plugin before attempting to use the call back.
Implications:
- determination of main page cache use needs to take place in act_dispatch
before template inclusion.
- if instruction generation is to take place it needs to occur in
act_dispatch (above template inclusion) not in tpl_content() - at least not
in its present location, in the middle of a template.
Implementation:
1 - refactor tpl_content() into two parts. The first part does all that
tpl_content() does now but buffers the output. This could happen
immediately prior (except 2 below) to template inclusion. The second part,
called from within the template, outputs that buffer. This is probably the
simplest way to do both points in (1).
2 - after generation of the tpl_content() buffer, save/retrieve the
extra_content cache as necessary.
Any thoughts on this?
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Other related posts:
- » [dokuwiki] Re: Roadmap/Todo, Getting (admin) plugins straight
