Menu
▾
▴
Re: [Phpwiki-talk] plugin help
|
From: Reini U. <ru...@x-...> - 2004-06-10 09:32:04
|
Dmitry M. schrieb: > On Wed, Jun 09, 2004 at 11:42:15PM +0200, Reini Urban wrote: >>If you can persuade some developer to put it into core it will be in lib/ :) > > Well that's not exactly the point I was trying to make :). > It seems strange if 99% of the functionality is encapsulated within a plugin, > and requires 1 specific line in a library.. It seems to make much more > sense to write something generic that could take care of situations like > these. Sure. I agree. That's why I started to support certain hooks. For example extended <body ...> attributes, more headers to be added, custom preferences fields, custom pagelist columns only needed by certain plugins, ... edipage might require such an extension scheme also, but I'm not sure yet into which direction. I tried htmlarea intergration with a lot of hooks, then js_searchreplace with no hooks (everything inside core), then edit_toolbar (no hooks yet). >>I have such a editpage toolbar feature in the works where you can press >>a button, which opens a window with a pulldown of all: >> >>* plugins >>* categories >>* all pagenames >> >>You select one and this is inserted verbatim into the textarea. >>This way you can easily associate categories, insert links to other >>pages and insert plugins. > > Hmm, I can see this working if there are 10 categories, or even 50, but > not more. This doesn't seem to scale well at all. A lits with incremental > search would be ideal (Midnight Commander style)... With AllPages from a select box it's the same problem. That's why I want to generate and display this window on demand, not on every edit request. It is long and will need some time to be generated, but users migth find it useful even if they have to wait a bit and have to scroll down a lot. For faster access there exist javascript helpers with keyboard quickaccess, which try to mimic a windows combobox. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
