[pmwiki-users] SelectQuery development: database records as pages?
Ben at InterdependentWeb.com
Wed Sep 27 21:53:12 CDT 2006
Thank you all for your feedback about the possibility of treating
database records as pages. I gave it some serious thought today... I
want this recipe to be as user-friendly as possible (which the current
incarnations of SelectQuery and UpdateForm are definitely not), and I
think this is the way to go. I envision somebody being able to install
this recipe, point it at a database, and voila, everything else happens
automatically. Here's my modest proposal:
* The functionality of SelectQuery and UpdateForm will be merged into a
single recipe. I was thinking of calling it DataFace, but I see there's
already an open-source project by that name that does pretty much the
same thing I have in mind, but without the wiki integration. If I
weren't so invested in the wiki integration, I might consider using it
instead... but as it is I'm open to name suggestions!
* If the tag for the recipe (whatever it turns out to be) is used
without parameters -- for example, by putting it in a GroupFooter as you
would (:pmcal:) -- it will apply itself to a database table whose name
matches the Group. The Group/Group page will list all records in the
table (much like SelectQuery) with a link on each one so that you can
view or edit a single record.
* The Group/Search page will show a search form with fields based on the
table. The searching syntax of the PageList script will be imitated as
closely as possible, so that users don't need to learn two different
searching syntaxes on the same site.
* Browsing a Group/Record page will display the matching record, if any.
Editing a Group/Record page will produce a form (much like UpdateForm
currently does). The structure of the tables and forms will be based
automatically on the structure of the database table unless specified by
a template. Because the records are displayed as if they were pages,
viewing & editing privileges should apply, whether by AuthUser or
UserAuth or regular wiki passwords.
* If the tag for the recipe is used with the 'tables' parameter (and
'where' if necessary), the page group can refer to a query of one or
more tables rather than on a table directly. Searching, browsing, and
editing records will work just as if the records came from a single
table -- similar functionality to a saved query in Microsoft Access.
* Templates will be in a format as similar as possible to PageList
templates (see question #1 below). In addition to Site/LocalTemplates,
the recipe will look in Group/Templates for templates specific to the
current table or query.
So having said that, I have some more questions for you fine folks:
1) There will need to be some way for templates to allow for the
differing numbers and names of fields from one table to the next -- a
sort of field-loop within the page-loop that PageList executes. Can
templates be nested?? That is, could a template for a list of records
somehow include a template for a list of fields? Or is there a better
way to go about it?
2) A single query may need to have as many as four templates associated
with it: one for the list of records, one for viewing a single record,
one for the editing form, and one for the search form. Should I break
up the 'fmt' parameter into 'listfmt', 'editfmt', etc., or is there a
better way? Perhaps look in Group/Templates for #list, #edit, etc.?
3) If it works as described above, the recipe will pretend that certain
pages exist that do not actually exist. Is there a way to suppress --
or intercept -- the "page does not exist" message? Or is there a better
way to do this, too? Maybe this ties in with the recent talk of virtual
4) If it works as described above, the recipe will produce a
record-editing form when the (nonexistent) page corresponding to a
record is edited. What is the best way to intercept action=edit? Or
would I be better off creating a new action for database edits?
5) Where should I look to learn more about creating a PageStore object?
I'm having trouble finding the documentation.
Thanks again for your insight!! --Ben
More information about the pmwiki-users