bwanders / dokuwiki-strata Goto Github PK
View Code? Open in Web Editor NEWStrata - a Semi-Structured Data plugin for Dokuwiki
Home Page: https://www.dokuwiki.org/plugin:strata
Strata - a Semi-Structured Data plugin for Dokuwiki
Home Page: https://www.dokuwiki.org/plugin:strata
Got this error installing strata plugin from dokuwiki web interface:
Error Parse error: syntax error, unexpected ':' in lib/plugins/strata/helper/syntax.php on line 277
The issue
I'm not able to ODT export a page containing a block. I get the error "We're sorry. We can't open pagename.odt because we found a problem with its contents." If I remove the and tags, I can export the page.
Have been experimenting with a combination of strata, templatery and stratatemplatery (and enjoying it very much).
What I can't figure out is how to get the data refresh (at the data end not at the output end).
I threw in a few files from fwurg.net - and struggled to get these to show up -- eventually they did but
I figured out that running Searchindex Manager plugin did not achieve it.
It was only achieved by manually altering the time-stamp on all txt files and only after that running Searchindex Manager - now all good.
Obviously this would be necessary if ever required to resurrect the database from the txt source files, so what mechanism is there to ensure that data is entered apart from going into every file, making some trivial change, and re-saving?? It may be relevant to note that I installed templatery and stratatemplatery only after copying data files across. May be worth a note in manuals unless there is a simpler way.
I'd like to create a bunch of information for our users, and then have them update it. Can this be done through inputs like date pickers somehow, rather than having to do text entry for every field?
Missing values in query results.
strata plugin version : 2016-02-03
PHP version on server : 5.3.3 (Redhat 6)
Entry 1 (expurged)
<data ct>
libellé:blabla
id:CT-097
R*:
A:DO
C*:
I*:
</data>
Entry 2 (on another wiki page)
<data ct>
libellé:blabla
id:CT-058
R*:
A:DE
C*:
I*:
</data>
Entry 3 (on another wiki page)
<data ct>
libellé:blabla
id:CT-001
R*:
A:
C*:
I*:
</data>
query
<table ?c "Chantier" ?l "Libellé" ?r "Responsable">
?c is a: ct
?c libellé:?l
optional {
?c A:?r
}
sort {
?c (desc)
}
</table>
Output shows the "A" field of first record (DO) but an empty value for the second one (which should read DE)
Doing a sql query on the sqlite database shows that both records contain values for the "A" field (as well as the corresponding wiki pages)
The wiki page which contains the query codes embed the NOCACHE directive.
Deleting the wiki page for the second record, and recreating it afterwards with the same record descriptions does not solve the problem
Regards,
MB
PS : records entries have been sanitized for the issue report.
The [[]] operand is essential for queries to find rows which refer to “self”. However, when the query is repeated on a largish number of pages for the same entity type, maintaining the queries becomes quite cumbersome and error prone.
An obvious solution would be to place the query into a separate page and to include it into the pages where it is to be rendered using the include plugin. This would make it very easy to change the query for a great number of pages. However, this will not work because the [[]] refers to the page where the query is stored and not to the main page being rendered. In fact, the [[]] notation is not even needed because just writing down the fully qualified id of the page would suffice.
The Dokuwiki plugin struct (which serves roughly the same purpose) can do that. Apparently, it defines the symbol which stands for self as the main page being rendered and not as the page where the query is stored.
The suggestion: add a new function referring to the page being rendered so that the query can be placed in different page from the base data. I think the semantics for [[]] should not be changed so as not to break existing code.
I like the query language in strata very much and I think it's much more powerful than comparable plugins. Was it based on QBE? Thank you very much for this nice work.
I'm currently experimenting with the strata plugin. Data blocks and queries inside the <list>
tag are working fine. However it seems that the <table>
tag is not working properly. The text inside <table></table>
is left as is in the final render version.
Am I missing something ? Or is strata conflicting with some other plugin ?
Dokuwiki version: 2017-02-19 “Frusterick Manners”
Plugins installed that might conflict : wrap, styling, mathjax, filelis, ckg edit, cell background, caption
Using the type "wiki" either in a data block or in a query results in an error message. See the attached wiki page. My wiki is running Release rc-2020-06-09 "Hogfather" RC3
I have found where the list of known data types comes from and I have found "wiki" there. Is it supposed to be working?
So I am struggling a bit with syntax of Strata so I haven't messed up.
As a test, I have three or four DokuWiki pages with blocks similar to:
[data customer]
Name: Bloke
Product: pdm
Enterprise: yes
CUCM: no
Lync: no
ShoreTel: no
Avaya: no
Genesis: no
[/data]
Then I have a separate page, call it "results" for clarity:
[table ?c "Customer" ?p "Product" ?m "CUCM"]
?c is a: customer
?p = egw
?c Product: ?p
?c CUCM: ?m
[/table]
When I modify any of the wiki pages containing the "data" customer blocks, and then subsequently go to the "results" page, the data does not automatically refresh. I have to actually edit the "results" page, make a change, and save it for the table to take any changes into effect in the "data" customer blocks.
Is this a bug or normal behaviour?
Thanks.
I'm making a database of singers in DokuWiki, and trying out the Strata plugin. Seems to be going well, but I'm missing having an enum type; is there a way of setting up lists that restrict entry to only those items, such as a list of voice parts "Soprano, Alto, Tenor, Bass" so that we don't get typos polluting our database? For that matter, one form of Boolean like "Yes, No", would be another candidate for this.
When I use "filter*:..." expression I get an exception because the plugin uses for parsing "split" function which was removed in PHP 7.0. Just need to replace split->explode
PHP Fatal error: Uncaught Error: Call to u
ndefined function split() in /var/www/html/dokuwiki/lib/plugins/strata/helper/syntax.php:1026\nStack trace:\n#0 /va
r/www/html/dokuwiki/lib/plugins/strata/helper/syntax.php(983): helper_plugin_strata_syntax->_setPropertyValue(Array
, 'ui', Array, 'filter', true, 'select, select', Array)\n#1 /var/www/html/dokuwiki/lib/plugins/strata/syntax/select
.php(190): helper_plugin_strata_syntax->setProperties(Array, Array)\n#2 /var/www/html/dokuwiki/lib/plugins/strata/s
yntax/select.php(116): syntax_plugin_strata_select->handleUI(Array, Array, Array)\n#3 /var/www/html/dokuwiki/inc/parser/handler.php(80): syntax_plugin_strata_select->handle('<table ?name ?c...', 5, 73, Object(Doku_Handler))\n#4 /var/www/html/dokuwiki/inc/parser/lexer.php(526): Doku_Handler->plugin('<table ?name ?c...', 5, 73, 'strata_table')\n#5 /var/www/html/dokuwiki/inc/parser/lexer.php(454): Doku_Lexer->_invokeParser('<table ?name ?c...', 5, 73)\n#6 /var/www/html/dokuwiki/inc/parser/lexer.php(411): Doku_Lexer->_dispatchTokens('', '<table in /var/www/html/dokuwiki/lib/plugins/strata/helper/syntax.php on line 1026, referer: http://localhost/dokuwiki/doku.php?id=start&do=draft
PHP Fatal error: Uncaught Error: Call to u
ndefined function split() in /var/www/html/dokuwiki/lib/plugins/strata/helper/syntax.php:1026\nStack trace:\n#0 /va
r/www/html/dokuwiki/lib/plugins/strata/helper/syntax.php(983): helper_plugin_strata_syntax->_setPropertyValue(Array
, 'ui', Array, 'filter', true, 'select, select', Array)\n#1 /var/www/html/dokuwiki/lib/plugins/strata/syntax/select
.php(190): helper_plugin_strata_syntax->setProperties(Array, Array)\n#2 /var/www/html/dokuwiki/lib/plugins/strata/s
yntax/select.php(116): syntax_plugin_strata_select->handleUI(Array, Array, Array)\n#3 /var/www/html/dokuwiki/inc/parser/handler.php(80): syntax_plugin_strata_select->handle('<table ?name ?c...', 5, 73, Object(Doku_Handler))\n#4 /var/www/html/dokuwiki/inc/parser/lexer.php(526): Doku_Handler->plugin('<table ?name ?c...', 5, 73, 'strata_table')\n#5 /var/www/html/dokuwiki/inc/parser/lexer.php(454): Doku_Lexer->_invokeParser('<table ?name ?c...', 5, 73)\n#6 /var/www/html/dokuwiki/inc/parser/lexer.php(411): Doku_Lexer->_dispatchTokens('', '<table in /var/www/html/dokuwiki/lib/plugins/strata/helper/syntax.php on line 1026, referer: http://localhost/dokuwiki/doku.php?id=start&do=draft
I'm using the strata plugin as a sort of to-do list manager, adding a TODO class entry on pages and then generating a table on the front page.
Part of my data structure includes Creation and Deadline times.
It would be nice to be able to compare these with the current time, and say one week ahead, to highlight impending tasks/meetings/deadlines
I've extended strata with a new type, which I've called datetime:
class plugin_strata_type_datetime extends plugin_strata_type {
function render($mode, &$R, &$triples, $value, $hint) {
if($mode == 'xhtml') {
if(is_numeric($value)) {
// use the hint if available
$format = $hint ?: 'Y-m-d-H:i';
// construct representation
$date = new DateTime();
$date->setTimestamp((int)$value);
// render
$R->doc .= $R->_xmlEntities($date->format($format));
} else {
$R->doc .= $R->_xmlEntities($value);
}
return true;
}
return false;
}
function normalize($value, $hint) {
// use hint if available
// (prefix with '!' te reset all fields to the unix epoch)
$format = '!'. ($hint ?: 'Y-m-d-H:i');
// try and parse the value
$date = date_create_from_format($format, $value);
// handle failure in a non-intrusive way
if($date === false) {
return $value;
} else {
return $date->getTimestamp();
}
}
function getInfo() {
return array(
'desc'=>'Stores and displays dates in the YYYY-MM-DD-HH:ii format. The optional hint can give a different format to use.',
'tags'=>array('numeric'),
'hint'=>'different date format'
);
}
}
So an example entry looks like:
<data TODO>
entry title:
-- nicer name (not sure how this is used yet)
Created [date]:
-- YYYY-MM-DD
Deadline [datetime]:
-- YYYY-MM-DD-HH:MM
Description [text]:
-- description of task
Related [link]*:
-- links to related to-do items
Status:
-- Status 0=completed,...,5=not-started
Priority:
-- Priority 0=DO IT NOW,...,5=would be nice?
</data>
It would be nice to have a table of the form:
<table ?created ?priority "P" ?description ?todo "Link" ?deadline ?related ?status "S">
?todo is a: TODO
?todo Created [date]: ?created
?todo Description: ?description
optional{
?todo Deadline[datetime]: ?deadline
}
optional{
?todo Related[ref]: ?related
}
optional{
?todo Priority: ?priority
}
optional{
?todo Status: ?status
}
-- would be nice to compare, for example
?todo Deadline < TODAY+7days
</table>
I'd love to be able to extend strata myself... but I don't really follow the - what seems complex to me - code that handles all the clever query building part; which is where I'd imagine this needs to be included.
An approach would be to include some sort of replacement-key, that gets converted to the right date format, then compared to the stored Unix-epoch representation of the date(time) type. strtotime()
should be able to construct these times with offsets.
(As a complete aside... in my entries I've got the entry title field... which is a nice human readable label for the to-do item. Can someone tell me how to replace the ?todo "Link"
column with links but the text being the nice entry title. I didn't really follow how the entry title field is used, grep-ing the source code was not much help to me).
My goal is to populate the syntax for the another extension using values in Strata data. Although this could equally apply to lots of other wiki extensions/syntax, in this example I'm looking at the SwitchPanel plugin
For instance, a four port switch could be specified as follows:
<switchpanel>
==line:4
1,Alpha
2,Beta
3,Gamma
4,Delta
</switchpanel>
My goal is to do something like:
<switchpanel>
==line:4
1,<strata type="switchport" searchfield="id" searchkey="port1" getvalue="name">
2,<strata type="switchport" searchfield="id" searchkey="port2" getvalue="name">
3,<strata type="switchport" searchfield="id" searchkey="port3" getvalue="name">
4,<strata type="switchport" searchfield="id" searchkey="port4" getvalue="name">
</switchpanel>
to query existing strata objects, e.g.
<data switchport>
id: port1
name: Alpha
</data>
so that the values driving SwitchPanel can be held in Strata data objects, rather than hard-coded on the wiki page where the SwitchPanel representation exists. I realize there are some things I haven't thought of, like how to handle cases where more than one data object shares the same value of id
, or a single object has more than one name
.
I've looked at the various strata add-on plugins, but I haven't yet figured out how I could achieve this. Is it possible somehow?
I have a page namespace1:somepage
Variant A
description[wiki]: [[somepage|]]
Variant B
description[wiki]: [[:somepage|]]
Variant C
description[wiki]: [[namespace2:somepage|]]
Variant A and C work as intended but Variant B does not make link to root namespace. It makes link to namespace1:somepage
using Release rc-2020-06-09 "Hogfather" RC3; using the directive ~~INFO:stratatypes~~ produces an error message:
Fatal error: Uncaught Error: Class 'plugin_strata_type_AbstractBaseType' not found in /volume1/web/dokuwiki/lib/plugins/strata/helper/util.php:50 Stack trace: #0 /volume1/web/dokuwiki/lib/plugins/strata/helper/util.php(62): helper_plugin_strata_util->_load('type', 'AbstractBaseTyp...', 'text') #1 /volume1/web/dokuwiki/lib/plugins/strata/syntax/info.php(51): helper_plugin_strata_util->loadType('AbstractBaseTyp...') #2 /volume1/web/dokuwiki/inc/parser/handler.php(279): syntax_plugin_strata_info->handle('~~INFO:strataty...', 5, 25670, Object(Doku_Handler)) #3 /volume1/web/dokuwiki/inc/Parsing/Lexer/Lexer.php(270): Doku_Handler->plugin('~~INFO:strataty...', 5, 25670, 'strata_info') #4 /volume1/web/dokuwiki/inc/Parsing/Lexer/Lexer.php(197): dokuwiki\Parsing\Lexer\Lexer->invokeHandler('~~INFO:strataty...', 5, 25670) #5 /volume1/web/dokuwiki/inc/Parsing/Lexer/Lexer.php(147): dokuwiki\Parsing\Lexer\Lexer->dispatchTokens('', '~~INFO:strataty...', 'plugin_strata...', 25670, 25670) #6 /volume1/web/dokuwiki/inc/Parsing/Parser.php(1 in /volume1/web/dokuwiki/lib/plugins/strata/helper/util.php on line 50
This is unfortunate as I am unable to produce a complete list of supported types. The directive for listing the aggregates (~~INFO:strataaggregates~~) works correctly.
Hi,
is it possible to define more than on entry on a page? I have tested it, and the result is a little bit confusing for me because I don`t know if I make a mistake in my table definition or if it really doesn't work correctly.
Here is my syntax:
<data person>
Full Name: John
Age: 24
Contact [link]: [email protected]
</data>
<data person>
Full Name: Alice
Age: 28
Contact [link]: [email protected]
</data>
<table ?person ?contact ?Age>
?person is a: person
?person Contact [link]: ?contact
?person Age: ?Age
</table>
Best regards
Juergen
Hi.
Trying to figure out how to accomplish this, but having read all documentation, I can't get it to work.
I have a single page named datapage
containing all data objects of class "item":
<data myitem #item1>
SampleField: One
</data>
<data myitem #item2>
SampleField: Two
</data>
<data myitem #item3>
SampleField: Three
</data>
and so on...
What I want is a simple table showing direct links to each item, so I use:
<table ?item>
?item is a: myitem
</table>
And I end having a table which links to datapage#item1
, datapage#item2
and datapage#item3
But having a look at the HTML code I've found there are no HTML sections / anchors defined as #item1 .. #itemN, so no direct linking possible, and that's what I need. When I click on the links I'm always redirected to the top of the datapage
. Is there any way to do this? Am I missing anything in the item / fragment approach?
Thanks a lot in advance. Greetings.
There appears to be no way to do this within the existing plugin, even though it is achieved on this website
http://www.fwurg.net/dokuwiki/guides:combat
I get a great big horrible table with each and every block of input code (making the otherwise great plugin useless to me).
Is this a bug, or is there something missing from the manual?
None of the configuration options seem relevant to not-displaying every input block as a table, even though this seems possible.
The current use of big regular expressions makes it difficult to provide fine-tuned error messages to help out the user.
A new scheme for parsing should be implemented. Either by splitting up the regular expressions to work towards more of a "scanning" approach (i.e., regex is used to tokenize mostly), or by replacing the whole parsing stage with a different kind of parser such as a recursive descent parser.
I have Data-entries which have a Description, which can be more than one line.
Is there any builtin way to handle/declare those?
right now only the first line is shown and i get the error
I don't understand data entry line ' (second line of description)'
Dokuwiki Release rc-2020-06-09 "Hogfather" RC3
I am trying to define a table which shows a hierarchy of projects. In English terms the query is to show all projects which are not parts of other projects, and their sub-projects. The predicate which associates a subproject with its main project is partof: The table yields the proper result if and only if the two occurrences of the predicate partof: are written differently: "partof:" and "Partof:" are OK, two times "partof:" is not OK. The attached sample shows two variants of the query.
I found out by pure chance that the two occurrences of the predicate had to use different spellings.
-------------Sample page (all in one page)----------------
<data proj #main1>
name: main 1
partof[page]:
<data proj #main2>
name: main 2
partof[page]:
<data proj #sub1>
name: sub 1
partof[page]: #main1
<data proj #sub2>
name: sub 2
partof[page]: #main1
===Correct output===
?project is a: proj
optional {
?part partof: ?project
}
minus {
--- note the incorrect capitalisation of the predicate partof:
--- in the following line
?project Partof: ?higher
}
group {
?project
}
===Incorrect output===
?project is a: proj
optional {
?part partof: ?project
}
minus {
--- In the following line the predicate is correctly capitalised
?project partof: ?higher
}
group {
?project
}
Attachment: Dokuwiki page rendered as PDF (if I succeed in attaching such a thing)
[correct_output.pdf](https://github.com/bwanders/dokuwiki-strata/files/4938865/correct_output.pdf)I was just wondering if there was an easy way to suppress the 'Previous' and 'Next' breadcrumb links that appear at the bottom of data blocks on pages with more than one data block easily, or or point me the way to which lines in the code I should look to comment out.
Currently a 'special' field type of 'class' is available, through two methods
<data class1 class2>
Name: Bob
</data>
or
<data>
is a: class1
is a: class2
Name: Bob
</data>
However, these 'classes' are not open to use with CSS (or, I can't work out how?).
It would be nice if:
For example, HTML would render as:
1)
<table class="class1 class2"> ... </table>
2)
<tr class="Name"> ... </tr>
This would then allow writing CSS files that treated 'classes' of entry different (possibly even setting display: none) and allow different styling to be applied to rows.
I have no idea how easy it is to do this.
I'd like to do the following with strata, but I'm not sure if this is possible, and if it is, how to do it.
I'd like to create, modify and query on dokuwiki :
Let's say I have a class named "it application"
<data it_application>
app_id:864
name:first app
</data>
<data it_application>
id:865
name:second app
</data>
Now I want to declare flows of data between "it applications" : for example "first app" sends customer information to "second app"
a flow could be described as
<data flow>
flow_id:123
source:864
target:865
data:customer
type:batch
</data>
or maybe
<data flow>
flow_id:123
source:first app
target:second app
data:customer
type:batch
</data>
How could I set up this with strata so that :
I have an object that can be defined or not, eg.
<data MISC>
Name: Bob
Count: 3
</data>
<data MISC>
Name: Bill
Count:
</data>
<data MISC>
Name: Ben
Count: 15
</data>
Following from the Public Examples issue, I'd like to generate a table with all data entries that either: (a) have no Count defined, or (b) if it is defined is must be greater than 10.
Neither of the following do what I want
<table ?name ?count>
?name is a: MISC
optional {
?name Count: ?count
?count > 10
}
</table>
<table ?name ?count>
?name is a: MISC
optional {
?name Count: ?count
}
minus {
?name Count: ?count2
?count2 > 10
}
</table>
I'd like a table include Bill
(Count is undefined) and Ben
(Count is defined AND greater than 10), while excluding Bob (Count is defined BUT less than or equal to 10)
I just can't quite work out the combination of optional/minus/etc blocks to achieve this.
Sorry, me again.
I have three data entries on three separate pages:
On Page test:links:a
<data TEST>
Date: 2015-01-01
Title: Initial meeting
</data>
On Page test:links:b
<data TEST>
Date: 2015-01-02
Title: Second meeting
</data>
On Page test:links:c
<data TEST>
Date: 2015-01-05
Title: Final meeting
</data>
I'd like a two column table with the Date
and Title
, like the following:
<table ?date ?title>
?item is a: TEST
?item Date: ?date
?item Title: ?title
</table>
However, this has no link to the page with the data entry on.
You can get a link as follows:
<table ?item ?date ?title>
?item is a: TEST
?item Date: ?date
?item Title: ?title
</table>
However, is it possible to have just the Date
and Title
column, with one of them as a href link to the page holding the data entry?
I've tried:
<table ?date [link] ?title>
?item is a: TEST
?item Date: ?date
?item Title: ?title
</table>
Which makes the Date
column into links... but the href target is wrong.
So I'm trying to combine two fields into one column with a link
type.
Hi,
I found that Stata does not support hint to format number like 1.000.000, it is much easier to read than the default (1000000).
Could you please add a hint to support this.
Thanks
Great plugin. Really really useful.
Only have two requests so far.
The first is...how do I combine search clauses to search by Foo or Bar?
If a field in data entry has a type hint and the type can not normalize the given value then the user should receive feedback about this.
For example, the Start [date]
field correctly normalizes 2016-02-18
, but can not normalize 2016/02/18
. Both represent the same dates to a human. Without normalisation the latter represents a flat string to Strata.
This break in user expectation is currently silently ignored. Possible options for improvement are:
Question
If I use dropbox to sync dokuwiki (but not database files obviously) across computers, can I still use this addon? I know most programs that use databases cannot be synced without loss of data, but maybe strata just gets all the data it needs from the text files alone (and then maybe caches them in a database).
Say you take dokuwiki file with some strata records to another computer and edit it in a plain text editor. You then sync the file back to the computer where strata is installed. Does strata know I changed anything?
Thanks
Dear Mr Wanders,
I have used your Strata plugin to improve a DokuWiki based tool that I use for risks analysis.
I needed some extra features, and implemented them the best I could:
I implemented them as well as I could with the attached changes.
The scoped mode relies upon a new "scope" column in the data table, that receives the namespace of the subject page. Depending upon the "scoped" configuration attribute, a filter on this column is added to the SELECT request.
The enumerated type is fully contained in the enum.php file. It displays the full text for a shorthand code or value, taking the replacement from a resource identified by the hint attribute. For example, Criterion [enum::params#criteria]: C displays as 'Confidentiality' since the Confidentiality: C entry exists in the params#criteria fragment.
At least for the scoped mode, I would be grateful if you could consider to include it into the plugin, rather that maintaining it on my own. I can probably handle the enum in a separate plugin if you think it is not relevant.
Strata delta.zip
Strata diff.txt
Best regards,
François KAAG
We use both the move and strata plugins. We recently moved some pages that were linked in strata blocks using [wiki] hints. The links in the strata blocks were not updated.
The move plugin's docs at https://www.dokuwiki.org/plugin:move say "this plugin uses the DokuWiki parser which allows it to correctly identify all links and nothing else."
Can you expose links embedded in strata blocks with [wiki] hints via the DokuWiki parser, such that other plugins can find them?
I have clean install of strata plugin and I'm receiving following error every time I try to add more than items in data entry:
I don't know what to do with the unnamed block in the '' data entry
I'm trying with example from your documentation:
<data user>
Full Name: John Doe
Age: 24
Contact [link]: [email protected]
Friends [ref]*: Alice, Bob
</data>
If I use only two items like:
<data user>
Full Name: John Doe
Age: 24
</data>
Than it works without any problem. I tried numerous variations of data.
When I disable line 87-90 in syntax/entry.php
(sanity check) then everything seams ok.
It seams to me like there is some problem in constructTree
method.
In dokuwiki 2017-02-19e "Frusterick Manners" I've installed sqlite and strata in Extension Manager. Then created 2 pages:
http://localhost/dokuwiki/doku.php?id=xxx:page_in_namespace
<data xxx>
Display Name: Page in namespace
</data>
http://localhost/dokuwiki/doku.php?id=referencing_page&do=edit
[[xxx:Page in namespace]]
<table ?name>
?xxx is a: xxx
?xxx Display name [ref::xxx]: ?name
</table>
In the last page there are 2 links leading to 'Page in namespace'. Here are they as seen in a browser.
First links works, but second actually points to not existing page because it haven't namespace component. I expected it to work because I've specified namespace in hint of ref following strata reference. What am I doing wrong? Can you advise an alternative way for that (namespace TOC) with strata? I know how to use other plugins for that, but need strata because need to add more columns in TOC table.
I'm trying to create tables of information about our network using this tool, and it's excellent at being able to collect the specific information I need from each device's page, which is excellent.
The only issue I'm having is that when it renders a table query (say, a device, its MAC address, and its IP address), I have no way of deciding how the device's name gets displayed -- it will always render the device's page name (e.g. "floor_0_cam_ap_switch" or "fiber_switch").
I'd like to be able to provide neat and clean entry for the columns; say, the "entry title" field manually specified in the data block (which doesn't change how the query renders the name, I've discovered), or a field that I can choose in the query itself. I don't know if I'm overlooking something, but I couldn't find it in the reference guide, and I don't want to spend a day pouring over the source code to see if there's an alternative.
The following table was generated using the code
<table ?d "Device" ?i "Internal IP" ?a "MAC Address">
?d is a: switch
?d ~> sca
?d IP [link]: ?i
?d MAC: ?a
</table>
Instead of, say "lib_switch", I'd like to say "Library Switch", or instead of "floor_2_cam_ap_switch" I'd like to say "Server Room Camera/AP Switch (POE)". At the moment, it automatically defaults to the page name.
If I've missed something (entirely possible, as I just set up the plugin yesterday), please let me know. If you can add this feature in a future version, that would also be great. Thanks!
The SQLite interface allows access to the SQLite databases used in a DokuWiki instance. The strata database is shown as sqlite version 2. Trying to select this entry with the SQLite interface yields the error message:
This is a database in sqlite3 format.
This plugin needs your database file has the extension ".sqlite3" instead of ".sqlite" before it will be recognized as sqlite3 database.
The interface then offers to rename the sqlite2 file into a sqlite3 file. However, this results in both sqlite2 and sqlite3 version being shown, with the sqlite2 version still unaccessible and the sqlite3 version being reported as broken.
Dokuwiki is Release 2020-07-29 "Hogfather"; strata is Installed version: 2020-08-09
I made a discovery today after several hours of head-scratching. I simply could not get Strata to render page TITLES in its various constructs. On my site, it would only render page names (page addresses or what I would call in another context as a page slug). It turns out that ''useheading'' setting must be set to "Always" or "Wiki Content Only" for strata to render the titles. My setting was "Never" and the moment I changed it, strata rendered page Titles. My pondering would have been hours quicker had there been any mention of this setting in the Strata Reference Guide, so here's my hint for somebody who can edit that to make this documentational improvement. For details, see https://www.dokuwiki.org/config:useheading.
Hi, it's me again :-)
I have created a table like below:
table ?s ?Name ?Geburtstag ?Alter ?Alter ?Alter ?Alter ?Alter ?Alter ?Alter ?Alter ?Alter ?Alter ?Alter
?s is a: person
?s name: ?Name
?s birthday: ?Geburtstag
?s age: ?Alter
?s age: ?Alter
?s age: ?Alter
?s age: ?Alter
?s age: ?Alter
?s age: ?Alter
?s age: ?Alter
?s age: ?Alter
?s age: ?Alter
?s age: ?Alter
?s age: ?Alter
If I now add one more "?Alter", so that I get 15 columns in the output table, the result is an error as follows:
Strata storage: Failed to prepare query 'SELECT DISTINCT v0, v6, v9, v12 FROM (SELECT DISTINCT lit1, lit2, lit5, v6, lit8, v9, COALESCE(r1.v0, r2.v0) AS v0, COALESCE(r1.lit11, r2.lit11) AS lit11, COALESCE(r1.v12, r2.v12) AS v12 FROM (SELECT DISTINCT lit1, lit2, lit5, v6, lit8, v9, COALESCE(r1.v0, r2.v0) AS v0, COALESCE(r1.lit11, r2.lit11) AS lit11, COALESCE(r1.v12, r2.v12) AS v12 FROM (SELECT DISTINCT lit1, lit2, lit5, v6, lit8, v9, COALESCE(r1.v0, r2.v0) AS v0, COALESCE(r1.lit11, r2.lit11) AS lit11, COALESCE(r1.v12, r2.v12) AS v12 FROM (SELECT DISTINCT lit1, lit2, lit5, v6, lit8, v9, COALESCE(r1.v0, r2.v0) AS v0, COALESCE(r1.lit11, r2.lit11) AS lit11, COALESCE(r1.v12, r2.v12) AS v12 FROM (SELECT DISTINCT lit1, lit2, lit5, v6, lit8, v9, COALESCE(r1.v0, r2.v0) AS v0, COALESCE(r1.lit11, r2.lit11) AS lit11, COALESCE(r1.v12, r2.v12) AS v12 FROM (SELECT DISTINCT lit1, lit2, lit5, v6, lit8, v9, COALESCE(r1.v0, r2.v0) AS v0, COALESCE(r1.lit11, r2.lit11) AS lit11, COALESCE(r1.v12, r2.v12) AS v12 FROM (SELECT DISTINCT lit1, lit2, lit5, v6, lit8, v9, COALESCE(r1.v0, r2.v0) AS v0, COALESCE(r1.lit11, r2.lit11) AS lit11, COALESCE(r1.v12, r2.v12) AS v and so on and so on……………………………………………………………………………………………………………
(Of course I came along this behaviour while using a table with 14 different columns :-) )
Is there a maximum numbers of columns which can be specified?
As noted in #28 pagination seems to be a complicated solution, but is there a way to just hard cap the amount to display? Say I'm just wanting to display the last 10 items added?
I'm working on a database with more than 10.000 data entries. Is there an option to define how many rows should be displayed?
I know that the Structured Data Plugin has the options max
and limit
and makes the table browsable if more rows are available. Some kind of pagination would be great to use the cool user interface with filters of strata for lots of data entries.
Running Dokuwiki: Release 2014-09-29d "Hrun"
Strata plugin 'master' branch
Running the strata plugin with the latest sqlite it requested to change the filename from .sqlite to .sqlite3, to use version 3.
However, from the Admin-sqlite interface I get errors when trying to look inside the strata database.
Specifically:
HY000 1 no such table: opts:
SELECT val FROM opts WHERE opt = 'dbversion'
SQLite: no DB version found. 'strata' DB probably broken.
Live public examples or demos of how this could be used (other than the short example in the readme), would be great.
Is it possible to use current page title [[]] as part of Fragment?
<data grp #[[]] test>
Does not resolve [[]].
Using the aggregate function @sum yields funny results. Apparently, the sum is reckoned for unique values. The following sample will show the effect:
<data beans>
who: peter
when: monday
beans: 1
</data>
<data beans>
who: peter
when: tuesday
beans: 2
</data>
<data beans>
who: peter
when: wednesday
beans: 2
</data>
<table ?who ?beans@sum >
?b is a: beans
?b who: ?who
?b beans: ?beans
group {
?who
}
</table>
This will show ?beans@sum as 3. Changing beans: to 3 for wednesday will show the expected result, 6.
Dokuwiki is Release 2020-07-29 "Hogfather"; strata is Installed version: 2020-08-09
http://han.dekthro.com/gear/weapon
Is there a way to have the links styled as "Title_Key" (which I have set as "Name") so as to not have lowercase_underscored_links? Also I have a variety of long/wide images being used, so doing something as [image::16] works really inconsistently, any suggestions as a solution to this? Thank you!
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.