Third Schema Type

[splitbrain]

We currently have two types of schema:

• page schema - each entry is attached to a different page (primary key: page)
• lookup schema - each entry is attached to no page (primary key: autoincrement)

I suggest having a third type that works like the lookup schema but where each entry is attached to exactly the same page - the one where the ---- struct lookup ---- syntax is used (primary key: page + autoincrement)

This would allow to reuse the schema on many different pages, giving you a new table for each of these pages. An example could be a schema offers(task, effort, price). Then I could add an offer table to each wiki page I need to describe the parts of an offer.

I'm not so sure about the implications of having this in how it would integrate with aggregations and lookup types etc. Eg. I'm not sure how much benefit this would give from a structural point of view.

[Digitalin]

Hello,

As I am asking how to make a list (catalogue), typically a use case of lookup schema, where users use it to complete a page with type lookup but doesn’t have to change the lookup schema which anyway doesn't relate to a page by itself. : yeah, I get one example
I wonder if this could join the purpose :
Let say, I have fields of services to the same level
Arts(1) - Home(2) - Music(3) - ....
and for each field relative (sub)fields, e.g. details for Music:
(3) Piano
(3) Guitar
....
that belongs to Music
I thing that what I am asking is about foreign key to join two tables which is not yet decided in the design. Anyway,

about third schema, I have two ideas (artistic mind):

1. an "aggregation" schema. It is already possible to aggregate fields (!) (haven't tried yet) from different schema but it could be nice to do the job before, mainly in case of complex requests (fields from different schema) and this in a schema gui then give a name to this "aggregation" schema. Easier for users and still possible to refine with aggregation in a page if necessary.
2. a "showing" schema (presentation) : why not store infos like Bureaucracy has, in a Struct schema rather than in template.txt or in meta (I do not know how Bureaucracy stores it). In this schema, you can assign a style of presentation to a schema, or a namespace where a schema applies, surely according to the previous assignment done in the schema page. A must have would be to design the page by drag & dropping fields on.
   A full process in struct plugin by itself.

[splitbrain]

I came up with another use case example: cooking recipes. A receipt schema would be (ingredient, amount). One recipe would have multiple ingredients in different amounts. An aggregation would be "list all recipes using onions".

Something like this could be achieved with a page schema and multi fields, but the association between ingredient and amount would break then.

cc: @detman @stvoigt @micgro42

[micgro42]

Funny thing: I do have some recipes in a wiki and would like such functionality^^

But I would like to see more features:

• A receipt might be an ingredient for another receipt
  • e.g. Risotto is an ingredient for "Chili con XYZ with Risotto"
• List all recipes sorted by summed kcal of their ingredients (i.e. treat the table as a single result)
• List all recipes sorted by number of ingredients
• List all recipes sorted by total preparation time, assuming we have also a schema containing the steps to cook a recipe.

(not sure whether they are all to be implemented in this type)

[micgro42]

Structured User-Stories on requirements could be another example. An example of an aggregation might be "List all userstories/requirements with an Manager as actor" or "List all userstories/requirements affecting a certain feature" etc.

[Digitalin]

With a bit more experience with Struct plugin, I hope this exemple matches the design 😄

I am beginning a time manager to count time passed on a task, and possibly a todo list as you can fill who, date, time and other info after.

The first field (dropdown type, only one choice) is an heading called "commission" with five values:

• Administration
• Communication
• IT
• Reception - Events
• Coordination

All private namespaces are already following this arrangement.

For each commission (Administration, Communication...), there is a field (dropdown type, one choice) giving a list of names describing a task's family (sub-headings).
As all the tasks to do are known, it is an exhaustive list. For complex task's family, a wiki page gives all details of achievement.

The others fields are : Date, Who (user type), Time (passed to the task in minutes), Description, Notes, Link (page type), Media. I use a lookup schema, no need to create wiki pages.

To extend Andi's idea of third schema, the benefit I imagine is to have an association between the first field values, e.g. "commission" with a table in a pagename. When filling a new task belonging to "Administration", it also fills a table in the pagename Administration for only tasks related to "Administration" commission. And in this namespace, only the field "Administration" displays. So, in the page dedicated to Administration, the fields are : Administration , date, who, time, Description, Notes, Link (type page), Media

[solewniczak]

I think that similar effect can be achieved with #356 + bureaucracy forms.

1. create lookup schema with pageid field.
2. create bureaucracy form:

<form>
struct_field "someschema.col1"
struct_field "someschema.col2"
struct_fieldhidden "someschema.pageid" "=@FORMPAGE_ID@"
</form>

3. Create lookup aggregation:

---- struct table ----
schema: someschema
cols: col1, col2
filter: pageid = $ID$
----

[Digitalin]

Sorry, I missed your message. Good news :-)
Seems a nice way for chained menu if I understand well the design.
Unfortunately, I met some issue with Bureaucracy (see #246). I will give a try when the issue has been resolved or the documentation updated if the declarative mecanism form/Struct has changed.

[annda]

I believe this has been solved by the introduction of the serial data