Small tutorial for db interface wiki plugins

This is a very small tutorial for WikiPluginsDb. Please contact me if you have problems with that.

These plugins are rather powerful, so you should learn to know them somewhat before you could use all their features. You should know at least some SQL to use them.

Remember that this is working great in a production environment! So: it works, at least for me 😕.

1. Create a dsn to tell the plugins how to connect to the db's. The plugins can use multiple databases. If the name of your dsn is default, you won't have to specify it. Go to ''Admin menu'->DSN.
2. I sometimes use the short plugin syntax, which is {PLUGINNAME(param1=>val1,param2=>val2)/}. It should work with the cvs HEAD version of Tiki, as I made the change some time ago. Don't know from which version it works. You could always use the complete plugin syntax, which should work in every Tiki version : {PLUGINNAME(param1=>val1,param2=>val2)}{PLUGINNAME}.
3. Wiki plugins are processed back-to-front by Tiki. This means that if you want plugin PLUGINA to be executed before PLUGINB, you should write PLUGINB{()/} before PLUGINA{()/}. This could look bad, but it isn't after all: this way, you could put all db requests at the end of the page.
4. Although plugins are processed (executed) in reverse order by Tiki (the last one first), they display on the right place: where you put them on your page.
5. If you get a blank page, maybe you came across the Tiki adodb bug with dsn's. Check my post about it on the dev list for an explanation and a quick fix.

Examples

Here are some page examples (just paste them in a new wiki page, on a site where the plugins are installed in lib/wiki-plugins/). To use it, you should have a db with a Student table with 3 fields: Id (autoincrement), First_Name and Last_Name. You should also make a dsn to it, named default (or you'll have to change the code). Go to ''Admin menu'->DSN.

I didn't have time to test these examples yet, it's from memory, but I'm fairly confident about it.

Very basic example: this is a page which displays all data from a table:

{DATATABLE()/}

{REQUEST()}
SELECT * FROM my_table
{REQUEST}

Comments:

• The request plugin has no db parameter, so it will take the default dsn (=dsn named default).
• DATATABLE, when used without any parameter, just displays the data from the default request (the first unnamed request).

Another example: display a list of students, with links to individual informations.

{DATATABLE(title=>1)}
__Id.__|__First name__|__Last name__|__''Links''__
*Id|*First_Name|*Last_Name|LINK:More info:StudentInfo:Id=*Id
{DATATABLE}

{REQUEST()}
SELECT Id, First_Name, Last_Name FROM Students
{REQUEST}

Comments:

• The DATATABLE plugin has the title parameter set, so the first row is the title row.
• Rows are separated by | , as in wiki tables.
• The second line contains a template for the other rows. *Fieldname will be replaced by the corresponding column from the default request (just set the from parameter on DATATABLE and it will take a named request).
• If you set the magic cursor parameter to 1 on REQUEST, the data table will display navigation buttons for moving between results (or result pages). See also the next example.

Same as above, but with a form on the same page to create a new record:

{DATATABLE(title=>1)}
__Id.__|__First name__|__Last name__|__''Links''__
*Id|*First_Name|_Last_Name|LINK:More info:StudentInfo:Id=*Id
{DATATABLE}

{FORM(update=>Create)}
__First name:__ {FIELD(name=>First_Name)/}
__Last name:__ {FIELD(name=>Last_Name)/}
{FORM}

{REQUEST(cursor=>1)}
SELECT Id, First_Name, Last_Name FROM Students
{REQUEST}

{REQUEST(id=>new_student,cond=>update)}
INSERT IGNORE INTO Students SET First_Name='?First_Name', Last_Name='?Last_Name'
{REQUEST}

Comments:

• The update parameter of the FORM plugin is simply some text for the Submit button, which will display automatically unless you specify it.
• The cond=>update parameter on the REQUEST field tells that this request will only be executed if an update parameter has been given to the page, which is automatically the case when you submit a form using {FORM} (unless you specify otherwise with the noupdate parameter in FORM)
• The id parameter is the name of the request, which you could use in FIELD or DATATABLE with their from parameter. If you don't specify a name, unnamed requests will be numbered, beginning with 0 (which will be the default request).

More

There is much, much more to it. You could let the plugins make backups of your updates, history in another table, etc. automatically, simply by setting flags. There is some magic in it for these things (including automatic query manipulation).

Please let me know what you think about it.