• • Other wikis have developed the notion of structured data items, most notably (to my knowledge) twiki∞ and xwiki∞, as well as the interesting wikidbase∞.

• use a specific visual rendering (including microformats∞) to format and display only key informations of each data item

1. embed in any page a "structured data item" which is defined by a type (e.g. a To-Do list entry) and a list of parameters (or fields, in the database terminology). Note that fields are not typed;
   - to display it as a microformat∞, where applicable

1. one field is mandatory: n, containing the name of the contact, formatted as 'last_name[;given_name[;middle_name]]'
2. optional fields are:
   2.1. org (organization): use the same value as the 'n' field if the contact is an organization instead of a person
   2.2. email
   2.3. tel and/or fax
   2.4. adr (address), formatted as 'street_adress;[city_name];[postal_code];[region_or_state];[country_name]'
   2.5. title
   2.6. url (personal or organizational web address)
   2.7. note (any further information)
3. a contact card is rendered by default as an inline text displaying the contact's name and (if any) organization, with a 'mailto' hyperlink to the contact's email address and a tooltip showing his/her phone and fax numbers. Example: John Doe (His_org).
4. optionally, a contact card can be displayed as a hCard microformat∞. Just add the print="hCard" parameter. The visual rendering of the hCard can be customized by adding classes to the wikka.css stylesheet (an example is given in the right-hand side box.)

• Double and single quotes around parameters and values shall be used in the same way as in the examples.
• A possible path of development would be to provide dynamic edition/validation capabilities for data items by embedding a HTML/Javascript form into the page.
• Possible refactoring: use an object approach to dynamically extend a base class with new structured data item types, each packaged in its own file.
• A nice feature of this action is that it is possible to freely mix regular wiki page content and structured data items, without any change to the database structure. However, this approach relies on regular expressions and is probably not very scalable in terms of the performance achieved when processing requests.
• One could wish, instead of having pre-cooked requests, to be able to run SQL-style SELECT statements. This would require a syntactic parser and is currently beyond my resources.

Structdata Action Documentation

Documentation

Short description

• use a specific visual rendering to format and display only key informations of each data item
• call predefined requests (a la SQL) to select and process data items across all wiki pages

• a "To Do" list
• a contact card

Parameters

• either a pair (type, data), if you want to define a data item

• either req with context-dependent p1, p2 and p3, if you want to perform a request

• If you pass both a type and a req parameter, the req parameter will be ignored

Long description

1. embed in any page a "structured data item" which is defiined by a type (e.g. a To-Do list entry) and a list of parameters (or fields, in the database terminology). Note that fields are not typed;
2. validate the list of parameters. You can:
   - check for the presence of a mandatory parameter; and
   - perform any data validation desired.
   An error message will indicate failure to validate a given data item. Note that this requires you to provide the corresponding code.
3. control the visual rendering of each data item. You can choose:
   - to make it invisible; or
   - to display it as a list, a table or an inline text by using predefined display modes; or
   - to display it in any custom way you may provide code for.
4. perform any selection, processing and aggregation request you wish (example: display all the open To-Do list entries with priority levels of 1 or 2). Of course, here again you have to provide some code.

Usage

{{structdata (type="datatype" data="fieldslist" [print="printmode"] | req="reqname" [p1="val1"][p2="val2"][p3="val3"] [help]) }}

Examples

Example 1: To-Do list structured data item

{{structdata type="ToDo" print="table" data="date_open='2006-10-3'  owner='jdoe' status='open' date_due='2007/11/13'  desc='Complete logo design'"}}

{{structdata type="ToDo" print="false" data=" owner='kbill' status='open' desc='Book flight to Lake Tahoe' priority='2' date_open='2006-10-4' date_due='2006-12-2' "}}

1. four fields are mandatory: owner, desc (description of the task), date_open and date_due. Dates shall follow the 'yyyy-mm-dd' format.
2. date existence check is performed for date_open and date_due.
3. no specific visual rendering has been defined. print='table' usually gives good results:

Example 2: Contact card structured data item

{{structdata type="Card" data="n='DOE;John' email='jdoe@his_organization.org' fax='(123) 654-898' tel='(+41) 123 4567' org='His_org'"}}

1. one field is mandatory: n, containing the name of the contact, formatted as 'last_name[;given_name[;middle_name[;title]]]')
2. optional fields are: org (organization), email, tel and fax.
3. no data validation is performed.
4. a contact card is rendered by default as an inline text diplaying the contact's name and (if any) organization, with a 'mailto' hyperlink to the contact's email address and a tooltip showing his/her phone and fax numbers. Example: John Doe (His_org).

BEGIN:VCARD
VERSION:2.1
N:DOE;John
FN:John Doe
ORG:His_org
TEL;WORK:(+41) 123 4567
TEL;FAX:(123) 654-898
EMAIL;INTERNET:jdoe@his_organization.org
END:VCARD

Example 3: ItemTable request

To-do, bugs and limitations

• Use of double and single quotes around parameters and values shall follow the example.
• A field can not be multi-line (should be fixed in release 1.1.7.)
• A possible path of development would be to provide dynamic edition/validation capabilities for data items by embedding a HTML form into the page.

Other considerations

• A nice feature of this action is that it is possible to freely mix regular wiki page content and structured data items, without any change to the database structure. However, this approach relies on regular expressions and is probably not very scalable in terms of the performance achieved in request handling.
• One could wish, instead of having pre-cooked requests, to be able to run SQL-style SELECT statements. This would require a syntaxic parser and is currently beyond my resources.
• Another possibility would have been to use an XML format (e.g. in the spirit of microformats∞) to define the data items. However, it seemed to bring more complexity than actual value.
• Other wikis have developed the notion of structured data items, most notably (to my knowledge) twiki∞ and xwiki∞.

Author

Structdata Action Documentation

• To access items across all wiki pages, locate this line:

$this->GetPageTag()) && ($row['type']

$p1)

BEGIN:VCARD
VERSION:2.1
N:DOE;John
FN:John Doe
ORG:His_org
TEL;WORK:(+41) 123 4567
TEL;FAX:(123) 654-898
EMAIL;INTERNET:jdoe@his_organization.org
END:VCARD

Example 3: ItemTable request

1. embed in any page a "structured data item" which is defiined by a type (e.g. a To-Do list entry) and a list of parameters (or fields, in the database terminology). Note that fields are not typed;

{{structdata type="Card" data="n='DOE;John' email='jdoe@his_organization.org' fax='(123) 654-898' tel='(+41) 123 4567' org='His_org'"}}

• a field can not be multi-line.
• a possible path of development would be to provide dynamic edition/validation capabilities for data items by embedding a HTML form into the page.
• a nice feature of this action is that it is possible to freely mix regular wiki page content and structured data items, without any change to the database structure. However, this approach relies on regular expressions and is probably not very scalable in terms of the performance achieved in request handling.
• one could wish, instead of having pre-cooked requests, to be able to run SQL-style SELECT statements. This would require a syntaxic parser and is currently beyond my resources.
• another possibility would have been to use an XML format (e.g. in the spirit of microformats∞) to define the data items. However, it seemed to bring more complexity than actual value.
• other wikis have developed the notion of structured data items, most notably (to my knowledge) twiki and xwiki

Usage

Example 2: Contact card structured data item

{{structdata type="Card" data="n='DOE;John' email='jdoe@his_organization.org' fax='(123) 654-898 tel='(+41) 123 4567' org='His_org'"}}

1. a contact card is rendered by default as an inline text diplaying the contact's name and (if any) organization, with a 'mailto' hyperlink to the contact's email address and a tooltip showing his/her phone and fax numbers. Example: John Doe (His_org).

• a field can not be multi-line (yet).
• A possible path of development would be to provide dynamic edition/validation capabilities for data items by embedding a HTML form into the page.
• A nice feature of this action is that it is possible to freely mix regular wiki page content and structured data items, without any change to the database structure. However, this approach relies on regular expressions and is probably not very scalable in terms of the performance achieved in request handling.
• One could wish, instead of having pre-cooked requests, to be able to run SQL-style SELECT statements. This would require a syntaxic parser and is currently beyond my resources.

Examples

Example 1: To-Do list structured data item

{{structdata type="ToDo" print="false" data=" owner='kbill' status='open' desc='Book flight to Lake Tahoe' priority='2' date_open='2006-10-4' date_due='2006-12-2' "}}

1. no specific visual rendering has been defined. print='table' usually gives good results:

To-do, bugs and limitations

• a field can not be multi-line (yet)
• A possible path of development would be to provide dynamic edition/validation capabilities for data items by embedding a HTML form into the page

Other considerations

• A nice feature of this action is that it is possible to freely mix regular wiki page content and structured data items, without any change on the database structure. However, this approach is probably not very scalable in terms of performance of request handling.

• use a specific visual rendering to format and display only key informations of each data item

1. four fields are mandatory: owner, desc (description of the task), date_open and date_due. Dates shall follow the 'yyyy-mm-dd' format.
2. date existence check is performed for date_open and date_due.
3. no specific visual rendering has been defined. print='table' usually gives good results.
4. a request called ToDos is predefined. It displays all To-Do list items in a table, sorted in reverse order of date_open. If parameter p1 is present, only data items whose owner equals p1 are selected. If parameter p2 is present, only data items whose status is equal to p2 are selected.

{{structdata type="Card" data="n='DOE;John' email='jdoe@himself.org' fax='(+1) 415 696 123' tel='212-898-31321' org='himself'"}}

1. one field is mandatory: n, containing the name of the contact, formatted as 'last_name[;given_name[;middle_name[;title]]]')
2. optional fields are: org (organization), email, tel and fax.
3. no data validation is performed.
4. a contact card is rendered as an inline text. Example: John Doe (His organization).
5. a request called Cards is predefined. It displays all contact cards in a table, sorted by name. If parameter p1 is present, only contacts whose organization equals p1 are selected. If parameter p2 is present, its value is used as the name of the field to sort on.

Other considerations

• One could wish, instead of having pre-cooked requests, to be able to run SQL-style SELECT statements. This would require a language parser and is currently beyond my resources.
• Another possibility would have been to use an XML format (e.g. in the spirit of microformats∞) to define the data items. However, it seemed to bring more complexity than actual value.
• Other wikis have developed the notion of structured data items, most notably (to my knowledge) twiki and xwiki

• use a specific visual rendering to display and format only key informations of each data item
• call predefined requests (a la SQL) to select and process data items across all wiki pages

• if you pass both a 'type' and a 'req' parameter, the 'req' parameter will be ignored

1. control the visual rendering of each data item. You can choose:

{{structdata (type="datatype" data="fieldslist" [print="printmode"] | req="reqname" [p1="val1"][p2="val2"][p3="val3"] [help]) }}