Description
I want to use Wikka to store, edit and access a large knoweldge base. Most of this knoweldge base is made of non relational database (only one table). I'd like to get a unique frontend to access the entire KB and wikka could be a nice way to do that.
How ?
My first idea is to work like a mailling system. Pages would still be edited and stored in the same way as used by te "page" handler. An extension of the TextFormatting could be enough to implement a field and data access definition.
Data storage
Data used to generate these pages can be stored in the wikka database, in a table with a special prefix in its name (e.g. wikka_dac_, standing for Data Access Component, or dah for handler). But the system would be even more powerfull if able to access an external database.
Data Access definition
The page must contain a set of instruction to define the data source, the way to access it, and how to display it.
Syntax example :
Header
{{dac_def "dac_ID" "host" "user" "pass (read only ;)" "db_name" "table_name"}}
As JavaWoman said, storing the database creditentials in the page is a bad idea. I first thought it could be stored in another table but that would create a need for a way to manage this table too.
if no host/creditentials/path is provided, we'd consider the source as beeing from a local table
Insertion in text
{{dac_field "dac_ID" "field name" "field_type"(optionnal ?)'
How to implement that
I see 2 solutions : a hack in the Page handler or the creation of a new handler.
Let's say we want to work properly and code it in a clean way, using a new handler. This dac handler would use parsing functions from Page but it'll just add a function to parse {{dac* funtions.
Page naming sheme
In order to select the right page to display we'd also need to add something in its name. It could simply be a prefix/suffix based request. Let's say we want to create a KnoweldgeBase table with articles identified by their number. We could gently ask wikka for KnoweldgeBase.article_id if we told the dac handler to match the suffix to a field in the source table in the header. A more powerfull method could be to specify the field used for matching in the suffix, e.g.: KnoweldgeBase.ID=article_id.
Content management
JackOfShadows pointed me on that in comments, i've forgot to mention it earlier
2 possibilities :
1) As in my projects, the database is actually feeded by another app. No need to have edition capabilities in wikka, it'll only be used to display it.
2) We want an administrator backend to create tables and manage global ACL on them, and a edit form for every table. Wich would make it a really heavy feature, maybe to much to keep it fast andd simple.
So I'd rather implement just a viewer, with an ACL per table, that's it. Keep it damn small and simple, I (selfishelly) just need a viewer, I think most of us could code the edit backend or use existing app to fit their exact needs. Or simply use phpMyAdmin.
I will add more soon, fell free add comments and/or corrections
ChiWaWa
I's a nice idea (if I understand correctly).
One thing that jumps out to me is storing the credentials for accessing that knowledge base in the Wikka page (essentially insecure). Maybe you could store that in a few configuration variables, or in a separate table (or fields in the user table)? I'm not quite sure whether you'd want to allow access to any user or just (a) particular one(s). Or whether you'd want to access a single knowledge base table or multiple ones. I see those as the parameters you'd need to define to determine how to let "Wikka" or a "Wikka user" access the knowledge base(s), and how to store the (various?) credentials for that access.
More later (maybe :))