<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Sep 29, 2006, at 8:42 PM, Kathryn Andersen wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">But having something that can act as an easy portal to a database (even</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">better if it is database-agnostic, since I tend to use SQLite rather</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">than MySQL for website databases) that could use the power of the</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">database for selecting and sorting, but the convenience of pagelist</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">templates for formatting its records, that would be great!</FONT></P> </BLOCKQUOTE></DIV><BR><DIV>Ben Wilson and I have discussed (and agreed on the benefits of) using ADODB for creating a database-agnostic version of AuthUserDbase that includes options for the features I added to create self-sign-up, email validation, etc.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I'm not sure when that's going to happen as he's working on a degree, and I'm working on paying my rent. If one additional person in my household gets a job, I'll be able to put more effort towards PmWiki modules (justifiable because nothing looks so good in my portfolio as my involvement in this community LOL).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I think it's a good idea to use a tool like ADODB, however, for something like SelectQuery as well. I'd be more than willing to talk to the package maintainer(s) about it.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>As long as we can all agree on one call to include ADODB it should all be good ;) And that would allow you to use SQLite instead of mysql/postgresql, etc. since that's one of the databases that ADODB supports.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Does anyone object to the use of a tool like ADODB for some recipes? 1) same license as PmWiki 2) 2.7 MB installed (currently) 3) one of the better open-source database abstraction layers 4) supports MANY databases: <A href="http://phplens.com/adodb/supported.databases.html">http://phplens.com/adodb/supported.databases.html</A> (some only on Windows, or with a plug-in) (may even include LDAP, but they're not very clear on that one)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>So essentially I'm asking cookbook authors if we can all agree on one database abstraction layer for PmWiki -- for use when we're going to deal with external databases. It would be quite helpful if we all agreed, and greatly extend the cookbook's support for a variety of data sources.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Crisses</DIV></BODY></HTML>