|
[dokuwiki]
||
[Date Prev]
[09-2005 Date Index]
[Date Next]
||
[Thread Prev]
[09-2005 Thread Index]
[Thread Next]
[dokuwiki] Re: Roadmap for next release
- From: "Chris Smith" <chris@xxxxxxxxxxxxx>
- To: <dokuwiki@xxxxxxxxxxxxx>
- Date: Mon, 5 Sep 2005 21:09:20 +0100
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.
e.g. for a syntax plugin, there is no neat way to duplicate the sort of
functionality offered by footnotes.
If a plugin's handle function is called, the plugin knows it is going to be
active in producing output. It needs some mechanism to talk back to
dokuwiki and say
- I need to place some html in the <head> (e.g. adding scripts, style or
even meta tags)
- I need access to the top of the (wiki)page (e.g. special titles)
- I need access to the bottom of the (wiki)page (e.g. a better place to
locate one-off data related to popups, footnotes)
I think there is a need for a plugin prefix or some sort. Is
"plugin_<plugin type>_" really that bad?
Can you explain what you mean by fall back to getInfo if no menuname is set?
That to me says the plugin is improperly made. So saying it wouldn't be to
difficult to default to the plugin name, with a title attribute of the
plugin description. And it could be handy to allow plugins to provide title
attributes for their menu text in all cases.
Admin plugin localisation is isolated from $lang - as long as "global
$lang;" isn't used in the plugins lang.php file. The language strings are
loaded into the $this->lang[stringname], and they can be accessed through
the $this->getLang('stringname') function in the base admin plugin class.
Even if you change away from "$lang", there is still the possibility of
clashing with other plugins. I set the localisation up to be as similar to
dokuwiki's localisation structure, hence the use of $lang in the string
file, but it would be pretty easy to change to $p_lang or something similar.
I have a number of things to fix for the plugin manager. I'll try to get
them all done in the next few days and send a patch through. I can do the
other changes mentioned above if you want to go that way.
Cheers,
Chris
> -----Original Message-----
> From: dokuwiki-bounce@xxxxxxxxxxxxx
> [mailto:dokuwiki-bounce@xxxxxxxxxxxxx]On Behalf Of Andreas Gohr
> Sent: 05 September 2005 20:10
> To: dokuwiki@xxxxxxxxxxxxx
> Subject: [dokuwiki] Roadmap for next release
>
>
> Hi all!
>
> The new fast search is in and working and a lot of other cool features
> were added so I'd like get a new release out. But I guess
> there are some
> things still left to do before. I want get your input on them.
>
> I added a list of things I think that need to be done on wiki:todo -
> What do you think is missing? Should we add the language autodetection
> for the GUI before releasing or add that in the next release? (Linas -
> haven't forgotten your patch).
>
> I also like to get your feedback and improvements on some points:
>
> The idea of combining all plugin scripts and styles is okay for syntax
> plugins, but may be a bad idea for admin plugins. For example the new
> searchindex manager has a big javascript file with stuff a usual user
> never will use - it shouldn't be loaded until the admin plugin is
> called. We need to rethink this whole case again I think. I also added
> some smaller things I'd like to see improved with the plugins.
>
> The new search uses a function called ft_snippet to build
> search result
> extracts. I'm not very happy how it works currently and I'd
> love to get
> some ideas how to improve it.
>
> If some of you could adopt some bugs from the bugtracker and
> send fixes
> it would be great, too.
>
> We're missing some translations as well. I haven't got any feedback
> from freelists about the i18n mailinglist, yet (John are you reading
> this?)
>
> Andi
>
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
|
|
