cosmocode / dokuwiki-plugin-struct Goto Github PK

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?

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....

The current implementation gives access to Admins only, but I'd think it would make sense to open this up to managers.

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()

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:

• make schema exports: maybe the sql-statements needed to create/change the tables
  • allow imports via the sqllite-interface
• manage schema within the animals but make it readable and distributable by the farmer
  • allow the animal to use and override the schema
• manage schema by the farmer and give an option "use in animal"

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.

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

• how to implement the custom code?
  • just some place to put classes within the plugin directory?
  • proper new plugins registering to struct plugin specific hooks?
• what kind of input would this custom code need?
  • the field configuration of course
  • the page id?
  • all the structured data already saved for the page?

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

Currently (local?) videos and audio files seem to work as well within the image type. I guess we should either enforce a check on the mime-type or rename the type to media.

This has been introduced by #13 and #26.

The renderer functions do seem to be pretty renderer agnostic already, but the render() method currently returns early when $mode != 'xhtml'

As suggested in #19 fields should have a comment field to allow for info how to fill them.

It would be nice to have check boxes as input type. This could be used for filtering or sorting of page data in aggregations.

We should check that the user is allowed to at least edit the page before we allow them to change its struct-values.

Empty values should not be rendered (otherwise empty dates default to today, or prefixes are added to empty texts, etc.)

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.

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.

A few things currently seem to work fine but are not covered by tests:

• revert action
• page deletion
• enable/disabling of fields (check in search, entry, table)
• config clearing in Types
• AbstractBaseType functionality
• diff showing
• access level checking in search
• assignment/deassignment in #33
• the functions in Value
• User Type #41
• skipempty in SchemaData::getData*
• SchemaData::clearData()
• field sorting
• search distinct
• config parser
• visibility handling
• bureaucracy support

Pull Requests welcome!

Maybe we need a config array for the schema itself?

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.

there were complaints that editing the section before the structured data output snips off chars at the end

Currently we display a standard table at the end of the page. This definitely needs better styling.

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.

It would be nice if users could export the data of an aggregation as CSV.

See comments in 2987727

Input is treated as wiki syntax and rendered accordingly. We probably want a text area as input.

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 a page gets deleted, the attached data should be blanked, too.

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
----

they are currently green. they should default to the main link color instead. simple CSS fix

Currently you can't search for structured data through DokuWiki's built in search. Structured data should be added to the search index.

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.

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?

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?

It would be nice to have a way to edit all available data of a schema in one go through a big table. Implementing this would be half way to #37

• Related to #59 a CSV import and export for this would be nice to have

Should validate the input. Output through our default obfuscation mechanism.

Do we need prefix/postfix?

For external links. Prefix and Postfix should be available, I guess.

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.

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.

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.

This basically links to a different page (configurable) and pushes the selected tag as a filter for a (configurable) column.

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 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.

Would be nice to be able to create dropdown fields. Data would be read from the config.

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?

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.

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?

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

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:

• title attributes always show the current page ID -> a "click to sort" would be more useful
• span.curid is added to all of them
• colors and boldness have to be overriden in CSS

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).

The TOC entry for structured data seems to vanish on rerendering.

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...