[pmwiki-users] Request input on soon-coming FAST Data release

[Ben Stallings]

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.