cosmocode / dokuwiki-plugin-struct Goto Github PK

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!

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.

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

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

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.

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.

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

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

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?

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

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

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?

When a page gets deleted, the attached data should be blanked, too.

Maybe we need a config array for the schema itself?

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.

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.

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

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

Do we need prefix/postfix?

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?

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'

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

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.

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.

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.

See comments in 2987727

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

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

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?

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.

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

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

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

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

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.

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

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

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

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

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

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

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

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.

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.

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.

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

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"

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