[pmwiki-users] SelectQuery development: database records as pages?

[Ben Stallings]

Caveman wrote,

> Just a thought on this.  FAST Data has MANY data manipulation features
> available in it already, as well as nice data retrieval capabilities.
> I was wondering if there is interest in using FAST Data as a front end
> for a database?  It already has functions for GetPage, SetPage, and
> GetData, etc.  I imagine it could optionally be set up for database
> use just by modifying a few lines of code.  Haven't studied it out,
> but it would be nice to give users the chance to store data info
> either way in one recipe.  Add a couple different fields and it works
> completely different.  And yet keep all the existing functions.  I
> will probably add this feature at some point, but why not work
> together?

Perhaps I should have been more forthcoming about this from the start, 
but I have a few concerns about combining SelectQuery/UpdateForm (or the 
yet-to-be-named recipe that succeeds them) with FASTData.  I may be 
unclear about some of the details, since I have yet to use FASTData 
myself... all I know about it is what I've read.

* Both SelectQuery/UpdateForm and FASTData attempt to be general-purpose 
recipes, but their development was driven by specific applications, so 
they have many tacked-on features that, while tremendously useful in the 
original context, may be distracting to people with more modest 
ambitions.  The main thing I hope to accomplish by starting over is to 
get back to simple, straightforward functionality: you have a database 
and a wiki; you install the recipe; now you have a front-end for the 
database.  Bells and whistles optional.  The extra features are slick, 
but they're not very thoroughly documented and so are a little 
intimidating... maybe they should even be separate recipes, if possible.

* FASTData's markup is rendered as HTML (hidden fields), which makes it 
visible to users who don't have editing privileges.  Although you've 
made the recipe pretty darn secure, I worry that people with better 
hacking skills than myself could write their own HTML forms in an 
attempt to access or modify information.  One of the things I feel I did 
right in SelectQuery and UpdateForm is to remove those details from the 
HTML so that all clues to the database structure -- and how it is 
accessed -- are hidden unless you have editing privileges.

* It may be petty of me, but I'm uncomfortable with the fact that 
FASTData's name refers to an evangelical organization.  I didn't call my 
recipes PermacultureQuery and PRIForm, in spite of their funding source, 
because there's nothing especially permacultural about them, just as I 
suspect there's nothing Christian about FASTData aside from its origins. 
  I personally would be more comfortable contributing to a project 
called "FastData" -- especially if it were as quick and easy to install 
as what I have in mind!

If you're in agreement with me that A) a database recipe needs to be 
simpler to install and use than either of our recipes currently is, B) 
the details of a data source need to be concealed from unfriendly eyes, 
and C) "FastData" is an acceptable name compromise, then I'd be honored 
to join forces with you.  Perhaps you have some conditions of your own 
to suggest.  :-)  --Ben