[pmwiki-users] SelectQuery development: database records as pages?
Ben at InterdependentWeb.com
Fri Sep 29 12:29:36 CDT 2006
> 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
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
More information about the pmwiki-users