dokuwiki-plugin-data
dokuwiki-plugin-data copied to clipboard
splitbrain
Multiple entries per page is easy!
It should be easy to allow multiple entries per page. Since I'm not a developer on this project, I'll just tell you how.
-
Allow a special data element that specifies a section name and level: section: 3,This is My Data
-
In the metadata renderer, use that section name along with the page id as the primary key: if ($section) { $s = array(); $id = $ID . '#' . sectionID($section, $s); }
-
And use the section name as the title: _saveData($data, $id, $section ? $section : $title)
-
In the handler function, generate a section header: if ($section) { if ($handler->status['section']) $handler->_addCall('section_close',array(),$pos); $handler->_addCall('header', array($b['name'], $level, $pos), $pos); $handler->_addCall('section_open', array($level), $pos); $handler->status['section'] = true; }
-
Currently, the edit action uses faulty logic to determine if a data section has been removed - it just searches for the string "dataentry." Replace that logic with something more complex: Search the entire document for dataentry sections, and compare the list to a SQL request.
I've made my own plugin which overrides the "entry" parser to use my own syntax. It does steps 1-4 without a problem. I'll have to override the action plugin too, in order to do step 5.
I've figured out the action plugin, though I'm not sure it's as efficient as possible, since it has to do a regex search on every page as its submitted... It's fast with two or three entries.
Add this to the _handle function:
$elts = array();
// Find all current section names.
preg_match_all('/----+ dataentry(?: [ a-zA-Z0-9])?-+\n.?\n----+/', $event->data[0][1], $matches);
for ($x=0; $x<count($matches); $x++) {
if (preg_match('/\n\s_section:\s_(._?)\s*\n/i', $matches[0][$x], $name)) {
$a = array();
$name = sectionID($name[1], $a);
$elts[$id . '#' . $name] = 1;
}
}
// Remove all non-current section names.
$query = $sqlite->query('SELECT pid, page FROM pages WHERE page like ?', $id . '#%');
while ($entry = sqlite_fetch_array($query, SQLITE_BOTH)) {
if (!$elts[$entry['page']]) {
$pid = (int)$entry['pid'];
$sqlite->query('DELETE FROM data WHERE pid = ?',$pid);
$sqlite->query('DELETE FROM pages WHERE pid = ?',$pid);
}
}
I already started on this a few weeks ago.
My implementation follows a slightly different approach with regard to the indication of a data entry identifier: bwanders/dokuwiki-plugin-data@04f149a5f1f04da4192530c60f4ae9e4f98c975c.
I'm planning to submit a pull request today -- I should've mentioned I'm working on this earlier. Could've saved you some work.
Good to hear that this plugin is still being maintained!
Once your changes are stable, I can see how well they work for my purposes. I had to override the action and syntax plugins anyway, because I use my own syntax to create the data, and just use the data plugin for fetching results.
I wonder how hard it would be to allow users to extend the data plugin with custom syntax... Probably harder than it's worth. :)
I'm not sure I like @bwanders approach. The data plugin is meant to be a way to attach additional structured data to a page. That's why the result in a data aggregation table is link to the page the data was attached to.
If you need multiple data entries, then it seems to me your page really should be two (or more pages) because they seem to cover different topics.
@zioth's approach of using the section identifier at least is a continuation of the idea to attach data to a page only that he attaches it to a page section. But still I'm not convinced.
The only thing I can imagine where multiple entries would be useful is if you want to simply split up data entry in different parts (maybe to logically structure your page). But then all entries should be merged on saving to be treated as the data for the whole page.
I agree that there's a lot to be said for not having multiple data entries on one page. If you want to describe a single concept per page (which is what is usually the case). However, there are situations where you have a lot of data, usually on parts of a larger whole, and in these cases (to help the imagination: an example, though syntax is from my own plugin you get the idea) it is useful to have multiple data blocks per page.
This plugin aims to add data to the page only. In that respect, I agree with @splitbrain that the whole idea of multiple data blocks per page might not even fit this plugin. Should you decide to pick up the concept of multiple entries per page, I think that for this plugin, @zioth's approach is better.
The thing about a plugin that stores arbitrary data is that it's inherrently flexible. You designed the plugin to identify a page with additional data, but people will find many other uses for arbitrary data. For example, imagine a site that displays brief summaries of novels. The site also wants to be able to search for novels by the ISBN number, author or title. One page on the site is called "Novels by Mark Twain." You want to have a data entry for each novel, but because of the limitations of the plugin, you can't do it without redesigning your web site and creating a tiny page for each book.
My own site does a similar thing. I wanted to put a collection of related items on one page, an another collection of items on another page, but I wanted all of those items to be searchable from a third page. I had to extend the data plugin, as described above.
can someone comment the progress on this enhancement? will it be implemented or is it already?
In more detail, since here seem to be general design and usage questions:
Maybe I do not get it, but it sounds as if there is a strong demand to have data storage, data entry mask(s) and data retrieval on one and the same page (or: in one and the same resource) - and that all in a wiki system, not in a database system. But if you have a look on usual (relational) database systems, you may find that data are spread over tables and put together by interfaces so it might look as if some collection of data was one discrete dataentry. So why don't you try one page (your interface) with multiple datatables, each retrieving from its "own" dataentry page? You can design a datatable (and your data) so that it retrieves exactly one dataentry and let it link to these data's page so that you can edit data as if it were on the page where it is displayed. It should be much easier to style datatables for your needs than to redesign the data plugin, the thing you have to decide is if you want to search for (connected) data by data plugin's datatables or by the "normal" DokuWiki search, the latter requiring "connection" being expressed by "stored on the same page".
What is irritating in the data plugin is that it claims to add and query structured data while settling on SQLite - Wikipedia for example redirects Structured storage to NoSQL, what in some way illustrates the more non-relational, NoSQL-like "everything on one page" as opposed to a more appropriate relational SQL-like "split it over multiple pages" way - finding yourself somewhere in the middle, again expressible in Wikipedia's terms of a Semi-structured model, being "also known as" Document-oriented database - but if you now have the strong desire to search only Wikipedia by yourself for anything one should know to only choose the right data(base) model, you might get lost before sunrise (and don't mix data plugins "datatables" with relational "data tables" ...).
Another point might be a desire for some structured data format and / or an entry editor and / or some uniform nice display of data as provided by the data plugin, but without any interest in data retrieval or reference to identical data on multiple pages, maybe rather searching for a table editing replacement (for strictly "local" data). bwanders' example page http://www.fwurg.net/dokuwiki/ic:mirda looks as if the data there is used rather only on exactly that page, therefore for him it would make sense to write (or derive) his own plugin for editing, storing, and displaying lots of structured data on one and the same page - indeed he has a repo for a Semi-Structured Data plugin for Dokuwiki - note the "semi-structured" and document-driven idea as mentioned above - but this is more like the data plugin itself. I would suggest splitting a plugin named "dataset" from the data plugin that is "reduced" to the described "editing system" for individual pages (or - table like - parts of pages) - at least to make clear the differing interest of the data plugin (being able to use both in the same wiki, but not mixing intentions when using them, marked in source code by <dataset> instead of ---- dataentry ----). The usage of a full database engine like SQLike feels like overhead for a simple page editing approach, but in practice that might be more than often - nearly any CMS functions that way. Note that the genius of the data plugin lies in instrumenting SQLite while keeping DokuWiki's basic claim for human readable and software independent simple text files as its data structure and NOT replacing that by some high level data description model (to be honest, I could not easily read the source code for bwander's unreleased strata plugin (see above) - though it is totally clear from a database programming view).
The Strata Plugin [1] handles multiple entries per page very well. So for everybody who needs multiple entries at one page, the Strata Plugin is the way to go. This prevents also adding more complexity to the already not-that-simple code of the Data Plugin.
[1] https://www.dokuwiki.org/plugin:strata
@zioth - can you please help me use this plugin with multiple data entries? I am by no means a developer but need to get this function working on my internal dokuwiki. Any assistance is much appreciated.
Sorry, @packgo. I'm not a developer on this plugin, and I haven't looked at it for almost six years. If you're having trouble with this one, consider trying the newer struct plugin: http://www.dokuwiki.org/plugin/struct