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

[marc]

Ben Stallings said...
> 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

Sounds terrific, Ben. 

-- 
Best,
Marc