@FosseWay: I would love help with the documentation! Both with an examples section, and improvements to the manual anywhere you feel it would be beneficial. More specific error messages will also be of immense value, I will gladly review any PR that helps improve feedback to the user.

Your idea of replacing the "weird line" message with a more helpful message is certainly worth the time to implement. When building Strata, I opted for using regular expressions because it helped develop the plugin at the time. The problem with parsing by regex is that the way I use them right now is an all-or-nothing proposition: either the whole pattern matches, or it does not. There's little context to work with to create a better error message. I've opened #37 to track and discuss parsing improvements (and I hope to get some work done on this in the coming weeks).

from dokuwiki-strata.

You are right: the manual needs a few good examples and an explanation of what's going on in the examples. I hope to get on that in some spare time during the holidays.

@bkidwell To answer your immediate question: the following table syntax will give you a table of all subjects with the show class, together with field one always displayed and field two and field three only displayed if they are available.

<table ?s ?f1 ?f2 ?f3>
?s is a: show
?s field one: ?f1
optional {
  ?s field two: ?f2
}
optional {
  ?s field three: ?f3
}
</table>

Note that it is also possible to have field two and field three displayed only if both if them are available:

<table ?s ?f1 ?f2 ?f3>
?s is a: show
?s field one: ?f1
optional {
  ?s field two: ?f2
  ?s field three: ?f3
}
</table>

from dokuwiki-strata.

I completely agree. I hope I can get to that within reasonable time.

In the meantime, you could go and have a look at a technology within the FWURG game if you feel adventurous. Most of the description of the game world of http://www.fwurg.net is done through this plugin actually.

from dokuwiki-strata.

I am having the same problem. I spent the last hour trying to make sense of the manual and I have failed to get anything more than a single column table. Everything I try just gives me a syntax error I can't understand.

If I have columns called "field one", "field two", and "field three" in pages with data blocks of class "show", what is the minimum syntax to show a table of all "show" records and all three fields, where "field two" and "field three" are optional?

I honestly can't parse the narrative text in the manual, and the one example given for a table doesn't make it at all clear what parts of the <table> syntax are specifying the name of the source field or the caption or what. As it stands, the documentation is unusable without the addition of several simple use case examples all highlighting different features of the plugin.

I would like to use this plugin, but I think I might have to move on to the less capable "Structured Data".

from dokuwiki-strata.

Thanks for taking my rant gracefully @bwanders. Your response is enough for me to go on for now. Please do fill out the docs with more examples when you get the time.

from dokuwiki-strata.

I have also one question concerning table view:

gives me a table, where all entries are mixed somehow. I had created 6 sets. I just want to see these 6 data sets in a table, each of them in one line.
What I get is a table of 180 lines in which all variables f1, f2, f3 appear 30 times. The table shows values in one line, which do not belong to each other.
What am I doing wrong?

from dokuwiki-strata.

@virk: Based on what you are describing, I'm guessing you have 6 data entries on a single page. Without taking care to make data fragments, this will attach all the data to the page itself. You can make data fragments on the same page like this:

====== Page Header ======

These two entries are both on the same page ''data_test''.

<data #fragmentA>
name: Foo
</data>

<data #fragmentB>
name: Bar
</data>

Now, you'll have data_test#fragmenta and data_test#fragmentb as subjects that can will match ?s.

Hope that helps, if not, please elaborate on what's going on.

from dokuwiki-strata.

Thank you; that has helped. But I noticed the following:

<data person#fragmentF>
name: Herny Morgan Veelken
birthday: 20.02.1961
age: 52
Contact [link]: [email protected]
Friends [ref]*: Martin, Günter, Erik, Jürgen

If I "forget" to attach "#fragmentF" to ,

In other words:
If I have 10 data sets on one page, 5 of them "attached" with "#fragment1-5" and the other 5 do not have this attachment, the output of table gives wrong results, because then values are mixed up.

I have attached a file to illustrate that. Hopefully it can be seen.

Remark: For us it is a big advantage to have more data sets on one page. Great job!

from dokuwiki-strata.

There is an explanation for the mixing up of values. The trick is that strata does data entry and data querying as two separate things: the first attaches data to a page or fragment, and the second queries that data without caring where it comes from. The querying simply matches the pattern you give it to the data.

For example, let's say you have three data entries on the people page, and forgot the fragments for two of them:

<data>
name: Foo McFoo
Age: 22
</data>

<data>
name: Bar Barson
Age: 33
</data>

<data #This guy>
name: Guy Guyson
Age: 44
Friends: A, B, C
</data>

After saving the page, strata will 'see' the following data:

(people, age, 22)
(people, age, 33)
(people, name, Bar Barson)
(people, name, Foo McFoo)
(people#this_guy, age, 44)
(people#this_guy, friends, A)
(people#this_guy, friends, B)
(people#this_guy, friends, C)
(people#this_guy, name, Guy Guyson)

Now, when you query for:

?s name: ?n
?s age: ?a

You are asking strata to match the pattern (?s, name, ?n) + (?s, age, ?a) in all the data that it knows about. Since strata doesn't care where the data came from, there's 5 combinations that match: ?n=Foo McFoo, ?s=22, ?n=Foo McFoo, ?s=33, ?n=Bar Barson, ?s=22, ?n=Bar Barson, ?s=33, ?n=Guy Guyson, ?s=44. And the table will show these. (Note also how the multiple value Friends becomes 3 separate items of data.)

I understand your opinion on why this must or should not happen. Most people feel this way at first, but after using it for a while, they start to appreciate that strata does not assume that it knows better than you by automatically splitting data.

An advantage of this method is that the data can literally come from anywhere; strata does not care at all when answering a query. This means that on long pages, you can have multiple ways of adding data to the page (such as the strata inline plugin) -- You could even have an external tool adding more data to the database and that would be find too.

from dokuwiki-strata.

Hi, I need help to understand the @sum aggregation. Can you please give me a short exemple to calculate (add upp) som Numbers from a data block in strata view. Thanks!

// H. Sonesson

from dokuwiki-strata.

@SecurityDragon: Happy to help!

Using the @sum aggregation (or any aggregration, really) in Strata is a two-step process:

1. Gather all values in a variable by using the group construct
2. Apply the aggregation function to the variable with multiple values

For this example, let us assume that we have four data blocks describing the loot in chests in a game's levels (you can paste these on a page to test):

<data chest #Small Chest in kitchen>
Where: Level 1
Gold pieces: 4
</data>

<data chest #Small Chest in secret room>
Where: Level 1
Gold pieces: 5
</data>

<data chest  #Strongbox in vault>
Where: Level 2
Gold pieces: 12
</data>

<data chest #Big chest in hallway>
Where: Level 2
Gold pieces: 8
</data>

Now, suppose we want to know how much loot there is on each level.

We start out with "Gather all values in a variable by using the group construct": We get all the chests ?c, what level they are on ?where and how much each chest is worth ?loot. With the group construct we tell Strata to group all data on the ?where variable. This means that values on other variables get bunched together:

<table ?where ?loot>
?c is a: chest
?c Where: ?where
?c Gold pieces: ?loot
group {
  ?where
}
</table>

This will produce a table informing us of the loot of each chest on the floor:

• Level 1: 4, 5
• Level 2: 12, 8

Now, we apply the aggregation function to the variables with multiple values (the only difference with the above query is the addition of the @sum aggregate function to the ?loot variable in the header of the table):

<table ?where ?loot@sum>
?c is a: chest
?c Where: ?where
?c Gold pieces: ?loot
group {
  ?where
}
</table>

Strata will now apply the @sum aggregation to the multiple values in the ?loot variable, summing up the loot on each floor. This will give is:

• Level 1: 9
• Level 2: 20

And that's it!

Notice that it is possible to show the same variable multiple times, and with different aggregates if you want:

<table ?where ?loot@sum ?loot@max>
?c is a: chest
?c Where: ?where
?c Gold pieces: ?loot
group {
  ?where
}
</table>

Gives both the total amount of loot in each level and the maximum chest value for each level.

Does this help you out?

from dokuwiki-strata.

Hi Brend,

Thank you for your answer and a awesome piece of code to DokuWiki.

Your website (.fwurg.net) is amazing. Respect!

I have another question, I hope you can help me with.

I use strata to create a content management for computer and information assets.

I will add a module for data classification. I can't figure out if I can

check if a variable/field has a specific string in a template. In other words i need to check logical if a string exist...

For example I know that i can check if a field is set, for example in a template:

I would like to do something like this

<if ISAInfo="check if ISAInfo contains a specific string or number>

Thanks in advance!

// Håkan Sonesson

Sweden

Från: Brend Wanders [email protected]
Skickat: den 1 juni 2016 14:02
Till: bwanders/dokuwiki-strata
Kopia: Security Dragon; Mention
Ämne: Re: [bwanders/dokuwiki-strata] Public examples (#6)

@SecurityDragonhttps://github.com/SecurityDragon: Happy to help!

Using the @sum aggregation (or any aggregration, really) in Strata is a two-step process:

1. Gather all values in a variable by using the group construct
2. Apply the aggregation function to the variable with multiple values

For this example, let us assume that we have four data blocks describing the loot in chests in a game's levels (you can paste these on a page to test):

<data chest #Small Chest in kitchen>
Where: Level 1
Gold pieces: 4

<data chest #Small Chest in secret room>
Where: Level 1
Gold pieces: 5

<data chest #Strongbox in vault>
Where: Level 2
Gold pieces: 12

<data chest #Big chest in hallway>
Where: Level 2
Gold pieces: 8

Now, suppose we want to know how much loot there is on each level.

We start out with "Gather all values in a variable by using the group construct": We get all the chests ?c, what level they are on ?where and how much each chest is worth ?loot. With the group construct we tell Strata to group all data on the ?where variable. This means that values on other variables get bunched together:

This will produce a table informing us of the loot of each chest on the floor:

• Level 1: 4, 5
• Level 2: 12, 8

Now, we apply the aggregation function to the variables with multiple values (the only difference with the above query is the addition of the @sum aggregate function to the ?loot variable in the header of the table):

Strata will now apply the @sum aggregation to the multiple values in the ?loot variable, summing up the loot on each floor. This will give is:

• Level 1: 9
• Level 2: 20

And that's it!

(Notice that it is possible to show the same variable multiple times, and with different aggregates if you want:

Gives both the total amount of loot in each level and the maximum chest value for each level.

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/6#issuecomment-222971840, or mute the threadhttps://github.com/notifications/unsubscribe/ABqs4-bx5LOoPSLNp5w2sZgHsURrXDo1ks5qHXS-gaJpZM4CcjN3.

from dokuwiki-strata.

Unfortunately, there is currently no way of checking the value of a variable for use in a template. That is something I would really like to build, but have not yet found the time to do.

from dokuwiki-strata.

Hi,
Okej, no problem. I will handle this in the querys. Thanks for fast Respons!

// Håkan

Skickat från min iPhone

1 juni 2016 kl. 22:27 skrev Brend Wanders <[email protected]mailto:[email protected]>:
Ns

Unfortunately, there is currently no way of checking the value of a variable for use in a template. That is something I would really like to build, but have not yet found the time to do.

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/6#issuecomment-223114257, or mute the threadhttps://github.com/notifications/unsubscribe/ABqs47t0FSRj8oF-ZmOLpBPJD3Ww_ydSks5qHesdgaJpZM4CcjN3.

from dokuwiki-strata.

Hi,

Really sorry to disturb you again. It won't be a habit I promise!

You give me a pice of code-example as below. The only different in my example is that all are set to level 1.

Question

When I try to compare ( > or >=) if the sum is bigger then 28 (the sum is 29) then it seems that i can't summarize all values all together in var ?loot

Se code below:

<data chest #Small Chest in kitchen>

Where: Level 1

Gold pieces: 4

<data chest #Small Chest in secret room>

Where: Level 1

Gold pieces: 5

<data chest #Strongbox in vault>

Where: Level 1

Gold pieces: 12

<data chest #Big chest in hallway>

Where: Level 1

Gold pieces: 8

Best,

// Hakan Sonesson

Från: Brend Wanders [email protected]
Skickat: den 1 juni 2016 14:02
Till: bwanders/dokuwiki-strata
Kopia: Security Dragon; Mention
Ämne: Re: [bwanders/dokuwiki-strata] Public examples (#6)

@SecurityDragonhttps://github.com/SecurityDragon: Happy to help!

Using the @sum aggregation (or any aggregration, really) in Strata is a two-step process:

1. Gather all values in a variable by using the group construct
2. Apply the aggregation function to the variable with multiple values

For this example, let us assume that we have four data blocks describing the loot in chests in a game's levels (you can paste these on a page to test):

<data chest #Small Chest in kitchen>
Where: Level 1
Gold pieces: 4

<data chest #Small Chest in secret room>
Where: Level 1
Gold pieces: 5

<data chest #Strongbox in vault>
Where: Level 2
Gold pieces: 12

<data chest #Big chest in hallway>
Where: Level 2
Gold pieces: 8

Now, suppose we want to know how much loot there is on each level.

We start out with "Gather all values in a variable by using the group construct": We get all the chests ?c, what level they are on ?where and how much each chest is worth ?loot. With the group construct we tell Strata to group all data on the ?where variable. This means that values on other variables get bunched together:

This will produce a table informing us of the loot of each chest on the floor:

• Level 1: 4, 5
• Level 2: 12, 8

Now, we apply the aggregation function to the variables with multiple values (the only difference with the above query is the addition of the @sum aggregate function to the ?loot variable in the header of the table):

Strata will now apply the @sum aggregation to the multiple values in the ?loot variable, summing up the loot on each floor. This will give is:

• Level 1: 9
• Level 2: 20

And that's it!

(Notice that it is possible to show the same variable multiple times, and with different aggregates if you want:

Gives both the total amount of loot in each level and the maximum chest value for each level.

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/6#issuecomment-222971840, or mute the threadhttps://github.com/notifications/unsubscribe/ABqs4-bx5LOoPSLNp5w2sZgHsURrXDo1ks5qHXS-gaJpZM4CcjN3.

from dokuwiki-strata.

Ah yes. That is a drawback of the way Strata handles aggregates. It is not possible to compare with aggregated values, because the aggregation function is only applied when displaying the values. In effect it is not possible to filter on aggregate values.

(In your case, you are trying to compare each of the four values against 28 separately... Which leads to not getting any results because each values is smaller on its own.)

from dokuwiki-strata.

Hi,

Ok, thanks for your resp. Have a nice summer :)

// H

Skickat från min iPhone

3 juni 2016 kl. 15:45 skrev Brend Wanders <[email protected]mailto:[email protected]>:

Ah yes. That is a drawback of the way Strata handles aggregates. It is not possible to compare with aggregated values, because the aggregation function is only applied when displaying the values. In effect it is not possible to filter on aggregate values.

(In your case, you are trying to compare each of the four values against 28 separately... Which leads to not getting any results because each values is smaller on its own.)

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/6#issuecomment-223582589, or mute the threadhttps://github.com/notifications/unsubscribe/ABqs43LeV2lCpjfCtAf21Wgke67VKAy6ks5qIC_1gaJpZM4CcjN3.

from dokuwiki-strata.

I appreciate the power and potential of this plugin. Thank you for all your hard work on it, @bwanders!

However, like others in this thread, I'm finding the examples and documentation more of a struggle than I had hoped. I'd be happy to help improve them, but it's a bit of a Catch-22.

In the hope of understanding the plugin better, I'm trying to teach myself to use the long form for everything, but immediately I run into the generic error message "Weird line in fields block". If the parser can't give me any hints as to why it's weird, I don't know what I should do to fix it.

This works:

<table>
fields {
?client
}
?client is a: client
</table>

but if I try to to add any other columns, I always seem to get the "Weird line" message.

Please accept my apologies if I have missed the bit of the documentation which explains how to use the fields block, but I couldn't find much in the Strata Reference Guide.

Checking helper/syntax.php, I see that this message (error_query_fieldsline) is returned when a certain pattern isn't matched:

"/^({$p->variable})\s*({$p->aggregate})?\s*({$p->type})?(?:\s*(:)\s*({$p->any})?\s*)?$/S"

...which in turn breaks down into several other patterns as defined within helper_plugin_strata_syntax_RegexHelper.

After reading the documentation, and following through these regexp, I thought that the line "client: ?c" should be OK, but clearly it's not.

I'm not an expert in writing parsers, but I wonder if it might be helpful to parse lines in stages, so that feedback could be given at each stage of the very large pattern I quote above. Instead of "weird line", you could then say:

"Line "bad$name: ?something" in fields block: variable name "bad$name" contains forbidden character "$"

...or something. Of course that's a simple example, but I hope it makes clear what I'm suggesting. Does this idea seem possible/worth doing?

I am quite serious about wanting to help to improve the documentation, particularly by providing more examples! If I can understand enough of how the plugin works, and if you think my suggestion above has value, I also hope to implement some more specific message and submit a PR for your consideration.

from dokuwiki-strata.

I thought I should come back and say that I got multiple fields displaying:

<table>
fields {
    ?id: ID#
    ?client: Client
    ?status: Status
}
?client is a: client
?client ID: ?id
?client Status: ?status
</table>

There's a significant amount of advanced functionality in this plugin, but maybe more simple examples are needed for beginners.

I still wonder if my idea of replacing "weird line" with more helpful messages is possible/worth trying.

I've started a new page on the DW wiki: https://www.dokuwiki.org/plugin:strata:examples

Nothing there yet, but I hope to have time to go through the Reference Guide and invent a few working examples over the next few weeks.

from dokuwiki-strata.

Thank you @bwanders! I appreciate that all of this takes time and effort. I like Strata for how easy it is to add data, and how powerful the engine seems to be, even if I don't yet understand it all.

I've made a start on the Examples page by deconstructing a really simple example. I might be using some of the terms incorrectly(?) but I've demystified the concept and config for myself a bit.

I've now committed to using Strata in my production wiki, so I can say with some confidence that I will continue to work to improve my understanding of Strata. I'll try to add several more simple examples over the next week or two. I will also add examples which I think should exist, but which I haven't yet figured out how to code.

As for the "all or none" regex problem, I think you've already done a lot of work which could be useful here; by templating the sub-patterns (e.g. $p->variable) I think it is then a bit easier to do some pre-testing on sections of the line ahead of the current "everything" match:

1. For each pre-defined match sub-patterns
2. Test each sub-pattern against the beginning ^ of the config line
3. Syntax checks on the match. For any syntax errors, provide the editor with as much guidance as reasonably possible
4. Remove each match from the config line string
5. End for each loop

I hope to get that functionality into a PR, although it might take me a while to get to it. I'm slowly working on a similar mechanism for the top plugin.

from dokuwiki-strata.

I've made some progress in my own understanding of how strata works, and I will continue to work on https://www.dokuwiki.org/plugin:strata:examples as I go.

One thing I am struggling with is the use of operators other than = to exclude results; in some cases, I haven't yet been able to get it working the way I expect.

An example of what I mean is at https://www.dokuwiki.org/plugin:strata:examples#cities_with_fewer_than_5_million_inhabitants - I'm sure it's my mistake, but I will extend the examples once I understand it. @bwanders, I'm hoping my explanation of the issue is clear enough that you might be able to tell me where I'm going wrong so I can extend the examples.

I've had some success with the minus block. Should I be using it in this case?

from dokuwiki-strata.

@FosseWay, not a 100%, but I think the problem with your population example is mixing types. By including delimiters in the numbers (eg. 3,455.25) it is been treated like a string. You then apply a numerical filter to a string.

Following the concept of separating data and presentation, the data is the number (eg. 3455.25) which will then need a custom type to format it within the output table. Also, remember not everyone uses the comma to separate thousands, millions, etc - depends on your local, could be: 3.455,25 or even 3 455,25 (although PHP, given its country of origin, I believe fixes inputting numbers in the form 3455.25).

(Also, the comma is used to separate multiple values on a single line. So if we wanted to store multiple numbers be definitely couldn't use the human-readable separates, for example:
value: 3,455, 6,777 is completely ambiguous)

from dokuwiki-strata.

@FosseWay: @simon-r-white is correct: the numbers in the data are neatly formatted, but this formatting is not recognized by Strata as a number. If you format them "plainly", e.g., for London that would be 8673713, Strata will be able to work with them.

At the moment there is no type specifically for numbers and their formatting, but it should be easy to add one based on the type examples already available.

@simon-r-white: PHP uses its locale settings to determine whether to parse , or . as the decimal separator. Unfortunately, the decimal mark standard is not actually supported as far as I know, even though that does seem to be the best way to handle this.

(As a side note, the , is only ambiguous if the field is marked as a multiple-value field with a. value: 3,455, 6,777 is a field with key value and a text value of 3,455, 6,777, whereas value*: 3,455, 6,777 is four values for the key value.)

from dokuwiki-strata.

Thank you @simon-r-white and @bwanders. I should really have thought of that. Sorry for the delayed response to your useful responses. The commas in the numbers causing them to be treated as strings is indeed the cause of my confusion.

I'm now starting to use the ui block, which for me really unlocks the true potential of strata. Understated and very powerful. I wish I had more time to devote to this effort right now, but I will keep chipping away at the Examples page.

from dokuwiki-strata.