[pmwiki-users] Request input on soon-coming FAST Data release
Ben at InterdependentWeb.com
Thu Oct 5 11:54:05 CDT 2006
The Editor wrote:
> Now Ben, if I've met your three conditions, we might could talk a bit
> more about adding database capabilities. Or interfacing this recipe
> with your database project? How should it look?
> I'm thinking either hooks (somehow) to enable my recipe serve as a
> front end for your recipe, so it can manage the input and output of
> data, but your recipe does the actual database work. The other option,
> might be to keep them separate but enable my recipe to do simple
> database saves/queries in a format that works with what you are doing.
> Unfortunately I'm not familiar enough with your project to know what
> it does/does not do, or how best these two can interface. Maybe
> someone familiar with both can comment.
Alas, so far all my new project (tentatively called DataQuery, and not
yet publicly available to get familiar with) does is pretend that
database records are wiki pages, for the purposes of displaying and
listing them. It doesn't yet allow you to edit or delete them or even
to control the way they display. It's clear that the many features of
FASTData (whetever it may be called) could be very useful in rounding
out this new recipe.
I see one big challenge to integrating the two: In FASTData, as I
understand it, the data format is determined by the form you submit. If
you add a new field to a form and submit it, the new field gets added to
the data page. Is that right? It's a very appealing strategy for
situations where you're more concerned about form design than about data
structure, which is probably the case for most wiki users and many
admins, so I really appreciate your clever approach!
Unfortunately my approach is the opposite... I want the form structure
to be determined automatically by the data structure! If a field in the
database is defined as varchar(20), it should be displayed in the
editing screen as <input type="text" size="20" maxlength="20">, and if
you change it to varchar(40), all the forms in the wiki should
automatically reflect the change. I want folks to think carefully about
data structure when they design the database, and then let the forms
take care of themselves, secure in the knowledge that nobody will be
able to submit 40 characters to a 20-character field, or a value of
"maybe" to a boolean field, or whatever.
So I see three possibilities.
1) We could try to keep both approaches within one recipe, one for data
pages and one for databases. This would mean a number of functions
would need to be duplicated, and we'd have to explain the conceptual
difference between the two to the end users, because they would have to
know how to go about creating forms for a particular data destination.
2) We could choose one approach over the other. Going with yours would
mean that submitting 40 characters to a varchar(20) field would cause
the field to be redefined as varchar(40)... kind of a scary thought for
a data purist like myself. Going with my approach would mean explicitly
defining the structure for a set of data pages on another page
somewhere, and automatically creating forms based on that information.
3) I could make my recipe generate virtual data pages on demand (using a
template) that the-recipe-formerly-known-as-FASTData could then process,
just as it (DataQuery) currently creates virtual pages that PageList can
process. If a FASTData form tried to edit one of the virtual pages, the
request would need to be handled by my DataStore object, and any
resulting error message would need to be displayed appropriately. There
would also be a separate way (I'm still hoping for ?action=edit) to
auto-generate a form based on the database structure.
I'm leaning toward #3... it allows the two recipes to work either
separately or together, based on the needs of the particular wiki. It
allows me to leave all the bells and whistles to you (because you're so
good at them!) and focus on data integrity, which you may have noticed
is my passion. :-)
What do you think? Suggestions welcome! --Ben S.
More information about the pmwiki-users