cosmocode / dokuwiki-plugin-struct Goto Github PK
View Code? Open in Web Editor NEWA new structured data plugin
Home Page: https://www.dokuwiki.org/plugin:struct
License: GNU General Public License v2.0
A new structured data plugin
Home Page: https://www.dokuwiki.org/plugin:struct
License: GNU General Public License v2.0
When a page had a schema assigned previously and then the assignment is removed, this page should no longer have any of the schema data associated. Otherwise the page would still be found in aggregations.
The question is how to achieve this. We could save a new set of blank data. But should this create a new page revision? I would argue no. But am I right?
Also how do we actually do this? We would need to use the old assignment and find all pages matching the assignment, then check if they have currently saved data for the old assignment and then overwrite it.
The Entry-Editor should be styled a bit nicer. We also have to decide if it should be collapsible. If so is it collapsed by default? Is the collapsed state saved in a cookie?
We need a way to validate input and probably deny saving if the input is not satisfied (probably by switching the $ACT mode back to preview).
Types will need a validate() function. Should this functions call msg()
on their own or how are error messages signalled back?
Currently we have no indexes except for the primary keys defined. We need to decide what should be indexed and how to handle indexing for the user created data tables. Should we give index creation power to the user? Should we index everything?
Would be nice to be able to create dropdown fields. Data would be read from the config.
Adding a remote API component to the plugin would allow editing and reading struct data via DokuWiki's remote API.
#53 would be helpful with this
Image should be a local media ID or external URL. Configuration needs to cover display in page and in aggregation (you probably want a smaller thumbnail in aggregation than in the page itself). We need width and optionally height. Add ligtbox class for when gallery plugin is installed.
For fields that do not implement their own multiValueEditor, the single valueEditor is repeated per value. An additional empty field is added at the end. This needs to be repeated automatically via JavaScript to allow to add multiple values at once without needing to save in between.
When you change a field from a single value to a multi value and previously had data for that field, the data is no longer visible (because it's stored in data_* but the lookup now checks multi_*). Also vice-versa if you change a multi-value to a single value it should still show the first of the values.
Warning: Invalid argument supplied for foreach() in /nfs/home/gohr/public_html/dw-2014-01-13/lib/plugins/struct/syntax/table.php on line 253
using:
---- struct table ----
schema: foo
dynfilters: 1
cols: %pageid%, bar
----
The current new section makes a bunch of problems and doesn't look too good. Also people are used to have the structured data at the top from the data plugin.
The output component should be reworked. Styling could be somewhat similar to the data plugin.
Position in the instructions should be after the first headline if that headline is within the first 50 bytes of a page. Otherwise at the very top.
In the data plugin we had a hidden type. It made sense as each type could later be accessed as any other type. This is no longer possible so we need a different mechanism to make every type hidden an prefill it.
I am not sure how, yet. We could put it into abstract base type's config setup similar to how the label translation is done. Or we could have a first class hidden field. But then we need another for the default value. Or we do introduce a hidden type and have it have a config to define a "parent" type.
Currently you can't sort on a multi value column. Implementing this is a bit tricky as we might need to merge the appropriate multi table (user might sort by a table not selected) and then sort by the first value.
The idea is to be able to create fields that can not be edited manually, but instead pull data from a remote API. This needs some flexible configuration and probably some kind of custom code somewhere. In addition the data needs to be pulled in periodically (via indexer cronjob).
Questions
The more I think about this the more I think this is not a good idea and it would be implemented better through additional custom plugins simply calling a struct helper plugin or interaracting through an API as suggested in #56
As a future feature it might be nice to be able to create data tables with data not bound to pages. For these editing would happen directly on a page where users can add new, browse, edit or delete existing entries.
Functionality like this has been asked for in the forum: https://forum.dokuwiki.org/thread/12820
It could also be used as a data source for the proposed dropdown type on #36
Accepts a date in the form YYYY-MM-DD
Should use the jQuery UI data picker for entry
Output should be formatable through a config option. Defaulting to dformat()
As suggested in #19 fields should have a comment field to allow for info how to fill them.
The basic functionality of saving new struct data and retrieving existing data should be made available to other plugins through a helper plugin. This would ease the implementation of #56 as well.
Users might want to switch from the data plugin to this plugin. Providing a way to move would be nice.
We could simply import values from the data sqlite but that would leave the data syntax in the pages - some cleanup would be required. But that could be done with search and replace op....
I think for managing different project wikis (see farming concept) it would be helpfull to reuse pattern/schema between different wikis in one farm. I am not sure, if this is feasable, but I see the following options:
It's probably easiest to add the struct data to the two versions sources as pseudo syntax before the diff engine runs over it.
We should check that the user is allowed to at least edit the page before we allow them to change its struct-values.
When a page gets deleted, the attached data should be blanked, too.
For external links. Prefix and Postfix should be available, I guess.
See comments in 2987727
The TOC entry for structured data seems to vanish on rerendering.
A few things currently seem to work fine but are not covered by tests:
Pull Requests welcome!
Aggregations need to rerender when dynamic filters are applied. We could simply disable caching by setting $this->info['cache']
to false (as we did in the data plugin). The better option would be to create an action plugin that would add dynamic options to the cache name generation.
Inspired by http://stackoverflow.com/questions/35826232/dokuwiki-block-certain-sections-from-editing
We could make it possible to set who is allowed to edit structured data on a per schema basis. Would that be a good idea?
It would be nice if users could export the data of an aggregation as CSV.
Currently we display a standard table at the end of the page. This definitely needs better styling.
Users in data entries/forms/tables were a very nice feature in my past wikis. The only way to achieve this was a workaround with usercreate page and the page-data-type looking for existing pages in the user namespace. It would be nice to have kind of user field with autocompletion. Even better would be autocompletion on both: user name and real name. Or maybe something like the @-Link here in github editor...
It will be desirable to create pages with attached data from the Bureaucracy plugin. We have to find a way to do that. It will also be desirable to reuse the valueEditors inside a Bureaucracy form.
We need ideas on how to do that. What would be desirable syntax for bureaucracy?
they are currently green. they should default to the main link color instead. simple CSS fix
We have this already, but it needs to have some configuration options for at least prefix and postfix
This basically covers the nspage functionality, so we won't need that type anymore.
Currently you can't search for structured data through DokuWiki's built in search. Structured data should be added to the search index.
Currently struct timestamps and page revisions are out of sync. In addition when you edit struct data only without changing anything in the page's source no page revision will be saved.
The best solution would be to bring the timestamps in sync and have struct chnages force a new page revision as well.
If that turns out as not easily achieved, struct changes should create virtual entries in the changelog.
This is difficult, because we currently do not have the titles in the database. The data plugin used to have a list of all pages and their titles. I think we will need something like that again.
Input is treated as wiki syntax and rendered accordingly. We probably want a text area as input.
Maybe we need a config array for the schema itself?
Empty values should not be rendered (otherwise empty dates default to today, or prefixes are added to empty texts, etc.)
The renderer functions do seem to be pretty renderer agnostic already, but the render() method currently returns early when $mode != 'xhtml'
There are a couple of smaller problems with the table aggregation
Headers are currently build with $R->internallink()
- links are only needed for xhtml output. Other renderers should use $R->cdata()
. The use of internal links also creates some more problems:
It would probably a better to use custom HTML and build the URL with wl()
.
In addition instead of adding up/down unicode arrows for sort direction we should add proper classes to the link and style them accordingly (would look better).
there were complaints that editing the section before the structured data output snips off chars at the end
It would be nice to have check boxes as input type. This could be used for filtering or sorting of page data in aggregations.
The current implementation gives access to Admins only, but I'd think it would make sense to open this up to managers.
Should validate the input. Output through our default obfuscation mechanism.
Do we need prefix/postfix?
This basically links to a different page (configurable) and pushes the selected tag as a filter for a (configurable) column.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.