From: Dmitry M. <dm...@la...> - 2004-06-09 19:50:43
|
Hello all. I need a suggestion on how to implement a plugin. Basically I'm trying to submit some additional data on page edit. I've hacked editpage.php which seems to work fine. For the final version however, I want the whole thing implemented as a plugin. This is not a problem for retrieving data as the engine passes control to the plugin on page load (which is all I need). I can't think of a nice way to do it on page edit (and can't find anything in code). Any suggestions? -d |
From: Dan F. <dfr...@cs...> - 2004-06-09 21:03:17
|
No suggestions, other than to change the plug-in interface (add a method, say), and put a hook in editpage.php. I can't check in code in Phpwiki, tho, so you shouldn't necessarily take my word on it. Out of curiosity, what are you trying to do? I've thought about putting hooks there for structured data (essentially, the ability to edit and retrieve versioned fields associated with a page, like "author" of a book page and so on). Dan Dmitry M. wrote: >Hello all. > >I need a suggestion on how to implement a plugin. > >Basically I'm trying to submit some additional data on page edit. I've >hacked editpage.php which seems to work fine. For the final version >however, I want the whole thing implemented as a plugin. > >This is not a problem for retrieving data as the engine passes control >to the plugin on page load (which is all I need). I can't think of a >nice way to do it on page edit (and can't find anything in code). > >Any suggestions? > >-d > > > > >------------------------------------------------------- >This SF.Net email is sponsored by: GNOME Foundation >Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. >GNOME Users and Developers European Conference, 28-30th June in Norway >http://2004/guadec.org >_______________________________________________ >Phpwiki-talk mailing list >Php...@li... >https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > |
From: Dmitry M. <dm...@la...> - 2004-06-09 21:28:44
|
On Wed, Jun 09, 2004 at 04:03:32PM -0500, Dan Frankowski wrote: > No suggestions, other than to change the plug-in interface (add a > method, say), and put a hook in editpage.php. I can't check in code in > Phpwiki, tho, so you shouldn't necessarily take my word on it. Hmm, perhaps that is what I will do. I have no idea how this is usually implemented. Any examples of good implementations? I will have to think about this. > Out of curiosity, what are you trying to do? I've thought about putting > hooks there for structured data (essentially, the ability to edit and > retrieve versioned fields associated with a page, like "author" of a > book page and so on). > > Dan I'm trying to see if a external "category" association will be useful at all. Basically every wiki page can belong any number of "categories". For instance, DmitrysResume could belong to {Documents, Dmitry}. DmitrysBlog could belong to {Blogs, Dmitry} and DmitrysPictures could belong to {Pictures, Dmitry}. Then I'd be able to click on "Dmitry" and retrieve all the logically related pages. So instead of a tree structure (like a filesystem), I end up with a flat list that's very quick to traverse. I believe this a variation on a concept called "faceted categories". What I have now is a plugin that allows the traversal of that list. The category addition/modification is implemented as a textbox on the edit screen (which is another problem). So, to append categories, I"ve simply added a couple of lines to the editpage.php. Clearly it can work this way, but it doesn't seem wise to hack code to enable some specific plugin functionality.. If this is to work only main wiki functionality has to be in /lib/ and the rest should be implemented as plugins.. Cheers. -d |
From: Reini U. <ru...@x-...> - 2004-06-09 21:42:20
|
Dmitry M. schrieb: > On Wed, Jun 09, 2004 at 04:03:32PM -0500, Dan Frankowski wrote: > >>No suggestions, other than to change the plug-in interface (add a >>method, say), and put a hook in editpage.php. I can't check in code in >>Phpwiki, tho, so you shouldn't necessarily take my word on it. > > > Hmm, perhaps that is what I will do. I have no idea how this is usually > implemented. Any examples of good implementations? I will have to think > about this. > > >>Out of curiosity, what are you trying to do? I've thought about putting >>hooks there for structured data (essentially, the ability to edit and >>retrieve versioned fields associated with a page, like "author" of a >>book page and so on). >> >>Dan > > > I'm trying to see if a external "category" association will be useful at > all. Basically every wiki page can belong any number of "categories". > For instance, DmitrysResume could belong to {Documents, Dmitry}. > DmitrysBlog could belong to {Blogs, Dmitry} and DmitrysPictures could belong > to {Pictures, Dmitry}. Then I'd be able to click on "Dmitry" and > retrieve all the logically related pages. So instead of a tree > structure (like a filesystem), I end up with a flat list that's very > quick to traverse. I believe this a variation on a concept called "faceted categories". > > What I have now is a plugin that allows the traversal of that list. The > category addition/modification is implemented as a textbox on the edit > screen (which is another problem). So, to append categories, I"ve simply added a couple of > lines to the editpage.php. Clearly it can work this way, but it doesn't > seem wise to hack code to enable some specific plugin functionality.. If > this is to work only main wiki functionality has to be in /lib/ and the > rest should be implemented as plugins.. If you can persuade some developer to put it into core it will be in lib/ :) 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. The problem is that I ran against yet unknown problems with MacIE, where most of the editpage toolbar features don't work. I only knew that the display property is missing on MacIE, so CreateToc and AddComment with js_hide will not work. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Dmitry M. <dm...@la...> - 2004-06-09 22:18:19
|
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. > 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)... > The problem is that I ran against yet unknown problems with MacIE, where > most of the editpage toolbar features don't work. I only knew that the > display property is missing on MacIE, so CreateToc and AddComment with > js_hide will not work. Don't know anything about JS stuff, sorry :] -d |
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/ |
From: Dmitry M. <dm...@la...> - 2004-06-15 07:56:44
|
On Wed, Jun 09, 2004 at 02:29:04PM -0700, Dmitry M. wrote: > I'm trying to see if a external "category" association will be useful at > all. Basically every wiki page can belong any number of "categories". Hi all. I actually sort of did what I was planning to. If you don't mind taking a look: http://www.lazymonkey.org/wiki/CategorizerPlugin I've finished it yesterday and I'd like some opinions. Some of the stuff is bound to be broken, so don't worry about it too much :) Thanks, -d |
From: Dan F. <dfr...@cs...> - 2004-07-06 13:16:19
|
Dmitry M. wrote: >On Wed, Jun 09, 2004 at 02:29:04PM -0700, Dmitry M. wrote: > > >>I'm trying to see if a external "category" association will be useful at >>all. Basically every wiki page can belong any number of "categories". >> >> > > >Hi all. I actually sort of did what I was planning to. If you don't mind >taking a look: http://www.lazymonkey.org/wiki/CategorizerPlugin >I've finished it yesterday and I'd like some opinions. Some of the stuff >is bound to be broken, so don't worry about it too much :) > > Dmitry, I wish some sort of similar functionality. I was planning to implement it through various back-links tricks. Something like: - Some pages (e.g., Book, Restaurant) are special 'category pages' by linking to a special 'Category' page. - Other pages link to the category pages (e.g., The Firm links to Book, La Bodega links to Restaurant). These category links are link your category label. However, they aren't entered in a separate editor, or displayed or searched separately. I'm not sure how my proposal related to your implementation. That is, I don't know what I like about mine versus yours. Mine is probably more traditional in the sense that people have been using back-links in Phpwiki to represent categories since before either of us. Thus, mine perhaps requires fewer code mods as well. Yours has a different UI. Possibly better? Don't know. Comments? Dan |