Menu
▾
▴
phpsqliteadmin-devel — phpSQLiteAdmin developer mailing list
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
(12) |
Apr
(1) |
May
(19) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(26) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(12) |
Feb
|
Mar
(26) |
Apr
(11) |
May
(8) |
Jun
|
Jul
(20) |
Aug
(13) |
Sep
(23) |
Oct
(2) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2008 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(22) |
Aug
(4) |
Sep
(3) |
Oct
(4) |
Nov
(1) |
Dec
(1) |
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
(2) |
| 2010 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(1) |
| 2011 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Yves G. <yg...@mi...> - 2005-01-01 16:30:40
|
On Saturday 01 January 2005 15:59, Mathias Siegmund wrote: > Hi! > I've got a problem with CVS. > Today I got my 1st CVS-Client. I wanted to get all files from > phpSQLiteadmin, so i followed the instructions on sf.net. But I > always get an error. > > Could you send me your CVSROOT to get the files? I attached my complete local folder of phpSQLiteAdmin, this should contain all you need and you should be able to proceed with "cvs up" to catch new checkins. Tell me if you have still problems! I also wanted to ask you if you could use the mailinglist for communication, this way all the members can follow our discussions. (You can subscribe here: http://lists.sourceforge.net/lists/listinfo/phpsqliteadmin-devel) Thanks, happy new year 2005 and best regards, Yves > Mfg, mathias -- Linux 2.6.10 #1 Sat Dec 25 11:15:48 CET 2004 i686 17:23:49 up 38 min, 1 user, load average: 1.94, 1.03, 0.43 |
|
From: Yves G. <yg...@mi...> - 2004-12-31 18:14:11
|
On Friday 31 December 2004 14:36, Mathias Siegmund wrote: > >> What does the list think about this way to achieve multilanguage > >> support? > > It's a good idea, but this function must be integrated in the > package. The file is actually already in cvs:=20 http://cvs.sourceforge.net/viewcvs.py/phpsqliteadmin/phpsqliteadmin/include= =2Ephp?view=3Dmarkup If you wanna work on it, better make a checkout since we have done some=20 work since the last release which is only available in cvs right now... MfG, Yves > mfg, mathias =2D-=20 Linux 2.6.10 #1 Sat Dec 25 11:15:48 CET 2004 i686 19:12:59 up 16 min, 1 user, load average: 0.00, 0.06, 0.11 |
|
From: Yves G. <yg...@mi...> - 2004-12-30 21:23:47
|
On Thursday 30 December 2004 13:42, Mathias Siegmund wrote:
> Hello List!
Hello and Herzlich Wilkommen!
> I want to help you with your project. I've got some ideas for
> phpSQLiteAdmin, e.g.: multi-language Backend.
That's very nice, help is welcome in fact :-)
Multilanguage support is a long-term todo of course, but until now we=20
did not spend time on it. I have however already written a function=20
which permits easy multilanguage support for any php application.
The main function is this:
function i18n($defaultstring,$string_id) {
global $strings;
if (isset($strings[$string_id])) {
return $strings[$string_id];
} else {
return $defaultstring;
}
}
Then, to use another language than english, simply add this to the main=20
include.php (or config.php):
require_once('lang/german.php');
With lang/german.php containing:
<?php
$strings =3D array(
// index.php
1 =3D> 'Forum',
2 =3D> 'Neue Nachricht',
14 =3D> 'Suchen',
// message.php
3 =3D> 'Autor:',
4 =3D> 'Datum:',
5 =3D> 'Titel:',
6 =3D> 'Abschicken',
7 =3D> 'Abbruch',
8 =3D> 'Beantworten',
// post.php
9 =3D> 'Neues Thema',
10 =3D> 'Autor:',
11 =3D> 'Titel:',
12 =3D> 'Abschicken',
13 =3D> 'Abbruch'
);
?>
Then, in the php files that output strings, the i18n function must be=20
used for printing these strings:
<form action=3D"search.php" method=3D"get" name=3D"search">
<input name=3D"q" type=3D"text" size=3D"20" maxlength=3D"40">
<input type=3D"submit" value=3D"<?=3Di18n('Search',14)?>">
</form>
What does the list think about this way to achieve multilanguage=20
support?
regards & Tsch=FCss Mathias,
Yves
> If you want my help, send me a mail to
> mat...@us...
>
> Mfg, mathias (Germany)
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Phpsqliteadmin-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpsqliteadmin-devel
--=20
Linux 2.6.10 #1 Sat Dec 25 11:15:48 CET 2004 i686
22:14:42 up 3:15, 1 user, load average: 1.07, 0.53, 0.45
|
|
From: Mathias S. <ma...@gm...> - 2004-12-30 12:41:52
|
Hello List! I want to help you with your project. I've got some ideas for phpSQLiteAdmin, e.g.: multi-language Backend. If you want my help, send me a mail to mat...@us... Mfg, mathias (Germany) |
|
From: Yves G. <yg...@mi...> - 2004-11-25 19:46:33
|
On Friday 19 November 2004 02:44, Felipe Lopes wrote: > IMO we must think about strategies on how to make phpsla more > popular. Visit this site: http://www.en.wampserver.com/download.php > You'll see that SQLitemanager is shipped w/ the wamp installer...What > a great deal for them! > > We must make phpsla stronger and them we should try ship it w/ any of > those installer out there...What you guys think? I know we should=20 > take one step each time, but I intend to have a strong (or at least > stronger) phpsla by middle december, wich means within 20/30 > days...Its not far away... > > Next important steps for me: > * decide about the class issue yes, IMO we should use pear and ship the necessary files > * edit/delete/view/anything-else entries sounds good, and IIRC Steve has it kind of working inside his tree > * pagination definately a TODO > * viewers > * triggers triggers (for me) are a low-priority TODO. ALTER TABLE is also a TODO... What do you mean by "viewers" ? > What else would you guys add to the list above? Lets write down a > road map we can work on... I for myself want to implement the so called "hoster mode". It's goal is=20 to enable a hoster who runs hundred of websites on one box to give his=20 customers sqlite database support & management utility without any=20 setup at all. cheers and hasta pronto > cheers > > Felipe Lopes. > > _____________________________________________________________________ >____________ Quer mais velocidade? > S=F3 com o acesso Aditivado iG, a velocidade que voc=EA quer na hora que > voc=EA precisa. Clique aqui: http://www.acessoaditivado.ig.com.br =2D-=20 Linux 2.6.9 #1 Mon Nov 1 12:01:23 CET 2004 i686 22:59:06 up 1:14, 1 user, load average: 1.53, 3.92, 3.64 |
|
From: Yves G. <yg...@mi...> - 2004-11-25 19:44:08
|
On Friday 19 November 2004 02:44, Felipe Lopes wrote: > IMO we must think about strategies on how to make phpsla more > popular. Visit this site: http://www.en.wampserver.com/download.php > You'll see that SQLitemanager is shipped w/ the wamp installer...What > a great deal for them! > > We must make phpsla stronger and them we should try ship it w/ any of > those installer out there...What you guys think? I know we should=20 > take one step each time, but I intend to have a strong (or at least > stronger) phpsla by middle december, wich means within 20/30 > days...Its not far away... > > Next important steps for me: > * decide about the class issue yes, IMO we should use pear and ship the necessary files > * edit/delete/view/anything-else entries sounds good, and IIRC Steve has it kind of working inside his tree > * pagination definately a TODO > * viewers > * triggers triggers (for me) are a low-priority TODO. ALTER TABLE is also a TODO... What do you mean by "viewers" ? > What else would you guys add to the list above? Lets write down a > road map we can work on... I for myself want to implement the so called "hoster mode". It's goal is=20 to enable a hoster who runs hundred of websites on one box to give his=20 customers sqlite database support & management utility without any=20 setup at all. cheers and hasta pronto > cheers > > Felipe Lopes. > > _____________________________________________________________________ >____________ Quer mais velocidade? > S=F3 com o acesso Aditivado iG, a velocidade que voc=EA quer na hora que > voc=EA precisa. Clique aqui: http://www.acessoaditivado.ig.com.br =2D-=20 Linux 2.6.9 #1 Mon Nov 1 12:01:23 CET 2004 i686 22:59:06 up 1:14, 1 user, load average: 1.53, 3.92, 3.64 |
|
From: Felipe L. <wi...@ig...> - 2004-11-19 01:44:35
|
IMO we must think about strategies on how to make phpsla more popular. Visit this site: http://www.en.wampserver.com/download.php You'll see that SQLitemanager is shipped w/ the wamp installer...What a great deal for them! We must make phpsla stronger and them we should try ship it w/ any of those installer out there...What you guys think? I know we should take one step each time, but I intend to have a strong (or at least stronger) phpsla by middle december, wich means within 20/30 days...Its not far away... Next important steps for me: * decide about the class issue * edit/delete/view/anything-else entries * pagination * viewers * triggers What else would you guys add to the list above? Lets write down a road map we can work on... cheers Felipe Lopes. _________________________________________________________________________________ Quer mais velocidade? Só com o acesso Aditivado iG, a velocidade que você quer na hora que você precisa. Clique aqui: http://www.acessoaditivado.ig.com.br |
|
From: Yves G. <yg...@mi...> - 2004-11-15 13:05:01
|
Hello folks, I added sdibb as developer to the project, Steve can you check if you=20 have cvs-write access? (Normally it should work) I tagged what we had right now as phpSQLiteAdmin_0_2+ So from now on cvs is open for changes, best regards and hear from you soon, Yves p.s. before tagging I added the db and images folder, I hope this was a good=20 idea... =2D-=20 Linux 2.6.9 #1 Mon Nov 1 12:01:23 CET 2004 i686 16:03:15 up 4:53, 1 user, load average: 0.03, 0.25, 0.59 |
Update of /cvsroot/phpsqliteadmin/phpsqliteadmin In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv13694 Modified Files: check_login.php dbaction.php include.php login.php mainframe.php set_session.php todo.txt Removed Files: phpsla.sqlite Log Message: removed phpsla.sqlite from / Index: login.php =================================================================== RCS file: /cvsroot/phpsqliteadmin/phpsqliteadmin/login.php,v retrieving revision 1.3 retrieving revision 1.4 diff -u -d -r1.3 -r1.4 --- login.php 23 May 2004 13:33:16 -0000 1.3 +++ login.php 14 Nov 2004 15:08:31 -0000 1.4 @@ -3,7 +3,7 @@ include_once("login.class.php"); $obj =& new login($_POST['user'], $_POST['pass']); -$obj->SPSQLite("phpsla.sqlite"); +$obj->SPSQLite("db/phpsla.sqlite"); if ((isset($_GET['logoff'])) && ($_GET['logoff'] == '1')) { $obj->logOff(); @@ -45,8 +45,9 @@ if ($obj->isEmpty()) { echo "</td></tr>"; - echo "<tr><td>Realname:</td><td><input type=\"text\" name=\"realname\"></td></tr>\n"; - echo "<tr><td>Email:</td><td><input type=\"text\" name=\"email\">\n"; +// echo "<tr><th>Password (confirm):</td><td><input type=\"password\" name=\"realname\" size=\"24\" maxlength=\"24\"></td></tr>\n"; + echo "<tr><th>Realname:</td><td><input type=\"text\" name=\"realname\" size=\"24\" maxlength=\"24\"></td></tr>\n"; + echo "<tr><th>Email:</td><td><input type=\"text\" name=\"email\" size=\"24\" maxlength=\"24\">\n"; echo "<input type=\"hidden\" name=\"empty\">\n"; } else { echo "<input type=\"hidden\" name=\"notempty\">\n"; Index: todo.txt =================================================================== RCS file: /cvsroot/phpsqliteadmin/phpsqliteadmin/todo.txt,v retrieving revision 1.5 retrieving revision 1.6 diff -u -d -r1.5 -r1.6 --- todo.txt 23 May 2004 13:32:32 -0000 1.5 +++ todo.txt 14 Nov 2004 15:08:31 -0000 1.6 @@ -26,3 +26,20 @@ - add multi-language support - add ui to manager user accounts + + + + +THERE IS A BUG: + +when you change the path to the file in an alias, the cookie gets not updated, and you still point to the +old database file!!! +Changing to another alias and coming back helps. + + +Notes about Steves branch: +------------------------------------------------------------------------------------------------ + +dbaction.php: this should go away: +$object = $_GET['object']; +$action = $_GET['action']; Index: check_login.php =================================================================== RCS file: /cvsroot/phpsqliteadmin/phpsqliteadmin/check_login.php,v retrieving revision 1.2 retrieving revision 1.3 diff -u -d -r1.2 -r1.3 --- check_login.php 27 Jun 2004 21:34:36 -0000 1.2 +++ check_login.php 14 Nov 2004 15:08:31 -0000 1.3 @@ -3,7 +3,7 @@ require_once("login.class.php"); $obj =& new login($_SESSION['user'], $_SESSION['pass']); -$obj->SPSQLite("phpsla.sqlite"); +$obj->SPSQLite("db/phpsla.sqlite"); if (!$obj->isLogged()) { header("Location: login.php"); --- phpsla.sqlite DELETED --- Index: dbaction.php =================================================================== RCS file: /cvsroot/phpsqliteadmin/phpsqliteadmin/dbaction.php,v retrieving revision 1.3 retrieving revision 1.4 diff -u -d -r1.3 -r1.4 --- dbaction.php 27 Jun 2004 21:34:36 -0000 1.3 +++ dbaction.php 14 Nov 2004 15:08:31 -0000 1.4 @@ -68,7 +68,7 @@ if ($action == 'drop') { // system db may not be dropped - if ($current_db == 'phpsla.sqlite') { + if ($current_db == 'db/phpsla.sqlite') { header("Location: index.php"); exit; } @@ -84,7 +84,7 @@ $sysdbh->query("delete from databases where user = {$alias->user} and alias = '{$alias->alias}'"); unset($userdbh); unlink($current_db); - $_SESSION['phpSQLiteAdmin_currentdb'] = "phpsla.sqlite"; + $_SESSION['phpSQLiteAdmin_currentdb'] = 'db/phpsla.sqlite'; header("Location: index.php"); exit; } Index: set_session.php =================================================================== RCS file: /cvsroot/phpsqliteadmin/phpsqliteadmin/set_session.php,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -d -r1.1.1.1 -r1.2 --- set_session.php 11 May 2004 18:23:19 -0000 1.1.1.1 +++ set_session.php 14 Nov 2004 15:08:31 -0000 1.2 @@ -5,7 +5,7 @@ if (isset($_POST['sessionname'])) { $_SESSION['phpSQLiteAdmin_currentdb'] = $_POST['sessionvalue']; } else { - $_SESSION['phpSQLiteAdmin_currentdb'] = "phpsla.slqite"; + $_SESSION['phpSQLiteAdmin_currentdb'] = "db/phpsla.slqite"; } header("Location: index.php"); Index: include.php =================================================================== RCS file: /cvsroot/phpsqliteadmin/phpsqliteadmin/include.php,v retrieving revision 1.2 retrieving revision 1.3 diff -u -d -r1.2 -r1.3 --- include.php 27 Jun 2004 21:34:36 -0000 1.2 +++ include.php 14 Nov 2004 15:08:31 -0000 1.3 @@ -7,7 +7,7 @@ if($_SESSION['phpSQLiteAdmin_currentdb'] == '') { - $_SESSION['phpSQLiteAdmin_currentdb'] = 'phpsla.sqlite'; + $_SESSION['phpSQLiteAdmin_currentdb'] = 'db/phpsla.sqlite'; } elseif(isset($_POST['sessionname'])) { $_SESSION['phpSQLiteAdmin_currentdb'] = $_POST['sessionvalue']; } @@ -26,8 +26,8 @@ // connect to the system database -if (!is_writable('phpsla.sqlite')) die("<br />System database 'phpsla.sqlite' is not writeable by webserver account."); -$sysdbh =& new SPSQLite('phpsla.sqlite'); +if (!is_writable('db/phpsla.sqlite')) die("<br />System database 'phpsla.sqlite' is not writeable by webserver account."); +$sysdbh =& new SPSQLite('db/phpsla.sqlite'); $current_db = $_SESSION['phpSQLiteAdmin_currentdb']; $current_user = 1; Index: mainframe.php =================================================================== RCS file: /cvsroot/phpsqliteadmin/phpsqliteadmin/mainframe.php,v retrieving revision 1.2 retrieving revision 1.3 diff -u -d -r1.2 -r1.3 --- mainframe.php 27 Jun 2004 21:34:36 -0000 1.2 +++ mainframe.php 14 Nov 2004 15:08:31 -0000 1.3 @@ -109,7 +109,7 @@ <li><a href="dbaction.php?action=vacuum" target="_top" onclick="return confirm_vacuum_db();">Vacuum Database</a></li> EOT; -if ($current_db != 'phpsla.sqlite') print "<li><a href=\"dbaction.php?action=drop\" target=\"_top\" onclick=\"return confirm_drop_db();\">Drop Database</a></li>\n"; +if ($current_db != 'db/phpsla.sqlite') print "<li><a href=\"dbaction.php?action=drop\" target=\"_top\" onclick=\"return confirm_drop_db();\">Drop Database</a></li>\n"; print "</ul>\n"; |
|
From: Yves G. <yg...@us...> - 2004-11-14 15:02:41
|
Update of /cvsroot/phpsqliteadmin/phpsqliteadmin/db In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12131 Added Files: phpsla.sqlite Log Message: added db/phpsla.sqlite --- NEW FILE: phpsla.sqlite --- (This appears to be a binary file; contents omitted.) |
|
From: Yves G. <yg...@us...> - 2004-11-14 15:01:01
|
Update of /cvsroot/phpsqliteadmin/phpsqliteadmin/db In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11748/db Log Message: Directory /cvsroot/phpsqliteadmin/phpsqliteadmin/db added to the repository |
|
From: Yves G. <yg...@us...> - 2004-11-14 15:00:51
|
Update of /cvsroot/phpsqliteadmin/phpsqliteadmin/images In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11692/images Log Message: Directory /cvsroot/phpsqliteadmin/phpsqliteadmin/images added to the repository |
|
From: Yves G. <yg...@mi...> - 2004-11-13 09:42:46
|
On Friday 12 November 2004 03:45, Steve Dibb wrote: > Ok guys, > > I've been spouting this dream of mine to use PEAR's native DB class > as the backend API for connecting to the SQLite database, and here's > how I think it can be done. > > There's two reasons I want to use the DB class though -- one, it's > installed with almost every php installation and it's very nice class > (well documented too), and two, I'm already really familiar with it. > :) > > Anyway, this email is my proposal on ditching the old class, and > integrating the parts that PEAR's doesnt support into PSA, and how it > can be done. > > http://sdibb.frogcircus.org/psa/psa_class_conversion.html > > I put together a quick spreadsheet that has four columns: > > SPLSQLite - has the functions of the old class you guys were using, > and as nice as I think it is, I have no problems about abandoning it > since DB.php already supports half the functions (as you'll see), and > the other half can be put into the PSA class. > > DB - If there's an entry in the column, then that value can replace > that function of the old class. In almost every case it's probably > going to take a bit of manipulation and code cleanup to use DB > instead. > > PSA - The new class I already started working on, which will pick up > any slack that DB can't handle, and at the same time pick up any > functions that psa is using right now and integrate them in as well. > The PSA class of course won't be limited to just that stuff, but that > will be some if of its main functions. > > PHP - The actual php functions that the PSA class would use. > > What do you guys think? I hope my little spreadsheet makes some > sense. :) After reading this I for myself would probably like using the pear class, but I never tried pear before I must admit. What I like about is that it's a maintained class, and the one we use right now is unmaintained by the original author. What I don't like is the work that would have to be done to go from the spsqlite to the pear/psa classes. Steve, would you volunteer doing it? Right now we have a simple (but working!) phpsla in cvs, and it should stay like that... ;-) If we do it, we must ship all the necessary files with phpsla, because, as Felipe pointed out, right now phpsla works right out of the box, and that should not change. Not everybody (including me) has pear installed, and by shipping it we would also avoid any kind of version-problems. Btw, is there no license problem shipping (unmodified) php-licsensed files within gpl app? http://pear.php.net/manual/en/faq.licenses.php cu, Yves p.s. After we will all be on the same page, IMO Steve should get cvs access to allow him easy coding. However I would like ot request that important or bigger changes, whoever wants to do them, should be discussed on this list. > I can go ahead and start on the class conversion, but I just wanted > to make sure we're all on the same page, and you guys don't think > it's a bad idea using PEAR instead or anything. > > Steve > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Phpsqliteadmin-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpsqliteadmin-devel -- Linux 2.6.9 #1 Mon Nov 1 12:01:23 CET 2004 i686 10:25:26 up 12:33, 1 user, load average: 0.75, 0.57, 0.57 |
|
From: Yves G. <yg...@mi...> - 2004-11-13 09:23:20
|
On Friday 12 November 2004 03:52, mai...@li... wrote: > Content-type: text/plain; charset=us-ascii > > This is a Mailman mailing list bounce action notice: > > List: Phpsqliteadmin-devel > Member: sd...@wo... > Action: Subscription removed. > Reason: Excessive or fatal bounces. > > > > The triggering bounce notice is attached below. > > Questions? Contact the Mailman site administrator at > mai...@li.... Steve are you still on the list after I got this message?? If not, please resubscribe -- Linux 2.6.9 #1 Mon Nov 1 12:01:23 CET 2004 i686 10:22:17 up 12:30, 1 user, load average: 0.32, 0.47, 0.56 |
|
From: Yves G. <yg...@mi...> - 2004-11-13 09:19:44
|
On Wednesday 10 November 2004 16:05, Steve Dibb wrote:
> > * what is "import_request_variables("pg");" good for? At first
> > sight I could not see any reason :-(
>
> import_request_variables dumps all $_GET and $_POST variables to
> their own variables. So if you have db.php?database=psa, a variable
> is automatically set for querystring $database to value $psa. It's
> the same as saying $_GET['database'], but without $_GET['...'] or
> $_POST['...'].
OK I suspected that... ;-)
I fact I always liked to user the $_GET['...'] and $_POST['...'] way of
writing because you can immediataly see where the variable comes from,
cookie, session, get or post, somehow they stay in their "namespace".
> Also a cool thing you can do with it is prepend variable names to the
> variables you're importing.
>
> For example:
>
> page: view.php?table=users&limit=50
> code: import_request_variables("g", "psa_"); ("g" for get, "p" for
> post") result: $psa_table = "users", $psa_limit = 50;
This is also a possibility to have some kind of "namespace" in the
variable name... In that case we should probably have get_, post_,
session_ and cookie_ as "prefix".
If you could use that in your code it would be really appreciated :-)
Maybe we can agree on either using the $_GET or $_POST notation, or in
case you work with miport_request_variables, use the get_ and post_
notation. What do you think?
(I know dbaction.php is bad in terms of code in that way, my bad...)
> > * I like the "require_once "inc.header.php";", it was longely
> > overdue :-)
> >
> > * I like the class, it's overdue as well
>
> Well, like I said, there's still a lot I'm hacking on. Dont think of
> my change as final at all. Transitional to say the least. :)
>
> Steve
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Phpsqliteadmin-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpsqliteadmin-devel
--
Linux 2.6.9 #1 Mon Nov 1 12:01:23 CET 2004 i686
10:07:47 up 12:16, 1 user, load average: 1.04, 0.71, 0.62
|
|
From: Felipe L. <wi...@ig...> - 2004-11-12 18:41:06
|
Em 12 Nov 2004, Felipe Lopes escreveu: >Hi there Steve! > >Well....Honestly I dun like the idea of using PEAR's native DB class for >some reasons: >1) Our class is more then enough - yes, we must clean it up a bit (a lot?); >2) Professional servers do have PEAR installed most probably, but personal >servers, just some (maybe a few) have; >3) I like the idea of phpsqliteadmin been an easy to install thing that >would work almost out of the box; >4) Never used PEAR and had trobles the time I tried LOL > >As I said to you on ICQ, I'd rather get DB class out of PEAR and use it, but >then it would be the same of using our class. I do understand that it is a >key decision since if we change it down the road we will have to edit more >stuff. IMO, changing it equals time lost. > >Felipe Lopes > >Em 11 Nov 2004, Steve Dibb escreveu: > >>Ok guys, >> >>I've been spouting this dream of mine to use PEAR's native DB class as >>the backend API for connecting to the SQLite database, and here's how I >>think it can be done. >> >>There's two reasons I want to use the DB class though -- one, it's >>installed with almost every php installation and it's very nice class >>(well documented too), and two, I'm already really familiar with it. :) >> >>Anyway, this email is my proposal on ditching the old class, and >>integrating the parts that PEAR's doesnt support into PSA, and how it >>can be done. >> >>http://sdibb.frogcircus.org/psa/psa_class_conversion.html >> >>I put together a quick spreadsheet that has four columns: >> >>SPLSQLite - has the functions of the old class you guys were using, and >>as nice as I think it is, I have no problems about abandoning it since >>DB.php already supports half the functions (as you'll see), and the >>other half can be put into the PSA class. >> >>DB - If there's an entry in the column, then that value can replace that >>function of the old class. In almost every case it's probably going to >>take a bit of manipulation and code cleanup to use DB instead. >> >>PSA - The new class I already started working on, which will pick up any >>slack that DB can't handle, and at the same time pick up any functions >>that psa is using right now and integrate them in as well. The PSA >>class of course won't be limited to just that stuff, but that will be >>some if of its main functions. >> >>PHP - The actual php functions that the PSA class would use. >> >>What do you guys think? I hope my little spreadsheet makes some sense. >:) >> >>I can go ahead and start on the class conversion, but I just wanted to >>make sure we're all on the same page, and you guys don't think it's a >>bad idea using PEAR instead or anything. >> >>Steve >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: >>Sybase ASE Linux Express Edition - download now for FREE >>LinuxWorld Reader's Choice Award Winner for best database on Linux. >>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click >>_______________________________________________ >>Phpsqliteadmin-devel mailing list >>Php...@li... >>https://lists.sourceforge.net/lists/listinfo/phpsqliteadmin-devel >> >>---------- > >Felipe Lopes. > >_________________________________________________________________________________ >Quer mais velocidade? >Só com o acesso Aditivado iG, a velocidade que você quer na hora que você >precisa. >Clique aqui: http://www.acessoaditivado.ig.com.br > >---------- Felipe Lopes. _________________________________________________________________________________ Quer mais velocidade? Só com o acesso Aditivado iG, a velocidade que você quer na hora que você precisa. Clique aqui: http://www.acessoaditivado.ig.com.br |
|
From: Felipe L. <wi...@ig...> - 2004-11-12 17:06:29
|
Hi there Steve! Well....Honestly I dun like the idea of using PEAR's native DB class for some reasons: 1) Our class is more then enough - yes, we must clean it up a bit (a lot?); 2) Professional servers do have PEAR installed most probably, but personal servers, just some (maybe a few) have; 3) I like the idea of phpsqliteadmin been an easy to install thing that would work almost out of the box; 4) Never used PEAR and had trobles the time I tried LOL As I said to you on ICQ, I'd rather get DB class out of PEAR and use it, but then it would be the same of using our class. I do understand that it is a key decision since if we change it down the road we will have to edit more stuff. IMO, changing it equals time lost. Felipe Lopes Em 11 Nov 2004, Steve Dibb escreveu: >Ok guys, > >I've been spouting this dream of mine to use PEAR's native DB class as >the backend API for connecting to the SQLite database, and here's how I >think it can be done. > >There's two reasons I want to use the DB class though -- one, it's >installed with almost every php installation and it's very nice class >(well documented too), and two, I'm already really familiar with it. :) > >Anyway, this email is my proposal on ditching the old class, and >integrating the parts that PEAR's doesnt support into PSA, and how it >can be done. > >http://sdibb.frogcircus.org/psa/psa_class_conversion.html > >I put together a quick spreadsheet that has four columns: > >SPLSQLite - has the functions of the old class you guys were using, and >as nice as I think it is, I have no problems about abandoning it since >DB.php already supports half the functions (as you'll see), and the >other half can be put into the PSA class. > >DB - If there's an entry in the column, then that value can replace that >function of the old class. In almost every case it's probably going to >take a bit of manipulation and code cleanup to use DB instead. > >PSA - The new class I already started working on, which will pick up any >slack that DB can't handle, and at the same time pick up any functions >that psa is using right now and integrate them in as well. The PSA >class of course won't be limited to just that stuff, but that will be >some if of its main functions. > >PHP - The actual php functions that the PSA class would use. > >What do you guys think? I hope my little spreadsheet makes some sense. :) > >I can go ahead and start on the class conversion, but I just wanted to >make sure we're all on the same page, and you guys don't think it's a >bad idea using PEAR instead or anything. > >Steve > >------------------------------------------------------- >This SF.Net email is sponsored by: >Sybase ASE Linux Express Edition - download now for FREE >LinuxWorld Reader's Choice Award Winner for best database on Linux. >http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click >_______________________________________________ >Phpsqliteadmin-devel mailing list >Php...@li... >https://lists.sourceforge.net/lists/listinfo/phpsqliteadmin-devel > >---------- Felipe Lopes. _________________________________________________________________________________ Quer mais velocidade? Só com o acesso Aditivado iG, a velocidade que você quer na hora que você precisa. Clique aqui: http://www.acessoaditivado.ig.com.br _________________________________________________________________________________ Quer mais velocidade? Só com o acesso Aditivado iG, a velocidade que você quer na hora que você precisa. Clique aqui: http://www.acessoaditivado.ig.com.br |
|
From: Felipe L. <wi...@ig...> - 2004-11-12 04:11:53
|
Hi there Steve! Well....Honestly I dun like the idea of using PEAR's native DB class for some reasons: 1) Our class is more then enough - yes, we must clean it up a bit (a lot?); 2) Professional servers do have PEAR installed most probably, but personal servers, just some (maybe a few) have; 3) I like the idea of phpsqliteadmin been an easy to install thing that would work almost out of the box; 4) Never used PEAR and had trobles the time I tried LOL As I said to you on ICQ, I'd rather get DB class out of PEAR and use it, but then it would be the same of using our class. I do understand that it is a key decision since if we change it down the road we will have to edit more stuff. IMO, changing it equals time lost. Felipe Lopes Em 11 Nov 2004, Steve Dibb escreveu: >Ok guys, > >I've been spouting this dream of mine to use PEAR's native DB class as >the backend API for connecting to the SQLite database, and here's how I >think it can be done. > >There's two reasons I want to use the DB class though -- one, it's >installed with almost every php installation and it's very nice class >(well documented too), and two, I'm already really familiar with it. :) > >Anyway, this email is my proposal on ditching the old class, and >integrating the parts that PEAR's doesnt support into PSA, and how it >can be done. > >http://sdibb.frogcircus.org/psa/psa_class_conversion.html > >I put together a quick spreadsheet that has four columns: > >SPLSQLite - has the functions of the old class you guys were using, and >as nice as I think it is, I have no problems about abandoning it since >DB.php already supports half the functions (as you'll see), and the >other half can be put into the PSA class. > >DB - If there's an entry in the column, then that value can replace that >function of the old class. In almost every case it's probably going to >take a bit of manipulation and code cleanup to use DB instead. > >PSA - The new class I already started working on, which will pick up any >slack that DB can't handle, and at the same time pick up any functions >that psa is using right now and integrate them in as well. The PSA >class of course won't be limited to just that stuff, but that will be >some if of its main functions. > >PHP - The actual php functions that the PSA class would use. > >What do you guys think? I hope my little spreadsheet makes some sense. :) > >I can go ahead and start on the class conversion, but I just wanted to >make sure we're all on the same page, and you guys don't think it's a >bad idea using PEAR instead or anything. > >Steve > >------------------------------------------------------- >This SF.Net email is sponsored by: >Sybase ASE Linux Express Edition - download now for FREE >LinuxWorld Reader's Choice Award Winner for best database on Linux. >http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click >_______________________________________________ >Phpsqliteadmin-devel mailing list >Php...@li... >https://lists.sourceforge.net/lists/listinfo/phpsqliteadmin-devel > >---------- Felipe Lopes. _________________________________________________________________________________ Quer mais velocidade? Só com o acesso Aditivado iG, a velocidade que você quer na hora que você precisa. Clique aqui: http://www.acessoaditivado.ig.com.br |
|
From: Steve D. <sd...@wo...> - 2004-11-12 02:50:33
|
Btw, Just look at all the cool functions DB already provides! The get* functions alone are worth the switch. :) http://pear.php.net/manual/en/package.database.db.php Steve |
|
From: Steve D. <sd...@wo...> - 2004-11-12 02:45:05
|
Ok guys, I've been spouting this dream of mine to use PEAR's native DB class as the backend API for connecting to the SQLite database, and here's how I think it can be done. There's two reasons I want to use the DB class though -- one, it's installed with almost every php installation and it's very nice class (well documented too), and two, I'm already really familiar with it. :) Anyway, this email is my proposal on ditching the old class, and integrating the parts that PEAR's doesnt support into PSA, and how it can be done. http://sdibb.frogcircus.org/psa/psa_class_conversion.html I put together a quick spreadsheet that has four columns: SPLSQLite - has the functions of the old class you guys were using, and as nice as I think it is, I have no problems about abandoning it since DB.php already supports half the functions (as you'll see), and the other half can be put into the PSA class. DB - If there's an entry in the column, then that value can replace that function of the old class. In almost every case it's probably going to take a bit of manipulation and code cleanup to use DB instead. PSA - The new class I already started working on, which will pick up any slack that DB can't handle, and at the same time pick up any functions that psa is using right now and integrate them in as well. The PSA class of course won't be limited to just that stuff, but that will be some if of its main functions. PHP - The actual php functions that the PSA class would use. What do you guys think? I hope my little spreadsheet makes some sense. :) I can go ahead and start on the class conversion, but I just wanted to make sure we're all on the same page, and you guys don't think it's a bad idea using PEAR instead or anything. Steve |
|
From: Steve D. <sd...@wo...> - 2004-11-10 15:05:34
|
> * what is "import_request_variables("pg");" good for? At first sight I
> could not see any reason :-(
import_request_variables dumps all $_GET and $_POST variables to their
own variables. So if you have db.php?database=psa, a variable is
automatically set for querystring $database to value $psa. It's the
same as saying $_GET['database'], but without $_GET['...'] or $_POST['...'].
Also a cool thing you can do with it is prepend variable names to the
variables you're importing.
For example:
page: view.php?table=users&limit=50
code: import_request_variables("g", "psa_"); ("g" for get, "p" for post")
result: $psa_table = "users", $psa_limit = 50;
> * I like the "require_once "inc.header.php";", it was longely
> overdue :-)
>
> * I like the class, it's overdue as well
Well, like I said, there's still a lot I'm hacking on. Dont think of my
change as final at all. Transitional to say the least. :)
Steve
|
|
From: Yves G. <yg...@mi...> - 2004-11-10 11:12:42
|
On Friday 05 November 2004 20:14, Steve Dibb wrote: > Here's my minor changes, since I'm not gonna have time to finish this > up today. Hi Steve, > http://sdibb.frogcircus.org/psa_20041105.tgz I had half a day off this morning and took a deeper look into your work and I think we should include it into the phpsla cvs. I have just a few questions/propositions: * what is "import_request_variables("pg");" good for? At first sight I could not see any reason :-( * the symlink phpsla.sqlite -> db/phpsla.sqlite should go away and the code be changed to refer to "db/phpsla.sqlite" because of filesystems that don't support symlinks. I did the changes in my local tree. * I like the "require_once "inc.header.php";", it was longely overdue :-) * I like the class, it's overdue as well I'm sorry I took so much time, I really want phpsla to advance and so does Felipe. I should be able to find more free time for PHP soon. I also want to thank you very much in the name of Felipe and me for your work! cu soon, Yves p.s. If ever you are artistically talented... :-) phpsla needs a logo :-) > You can see the diffs by running rcsdiff -r1.1 -r1.2 * > > I also stole phpmyadmin's images and put them in img/ > > Also created a basic phpdocumenation from the SQLite class in phpdoc/ > > I think the class needs to be tweaked a little bit. I havent looked > at all of it, but I don't like how on $class->query it returns an > HTML error if there's a problem. I'd rather have it return bool > true/false, and then output the error to an object variable, and be > able to display it with another function (similar to PEAR's DB > class). > > Steve > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Phpsqliteadmin-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpsqliteadmin-devel -- Linux 2.6.9 #1 Mon Nov 1 12:01:23 CET 2004 i686 11:23:07 up 1:03, 1 user, load average: 0.34, 0.08, 0.08 |
|
From: Felipe L. <wi...@ig...> - 2004-11-08 03:05:14
|
>On Friday 05 November 2004 19:56, Steve Dibb wrote: >> Hey guys, > >Hi Steve, > Hi there! >> I'm working on an edit row patch right now. I've actually got it >> working, and I'll submit it once you can delete a row, too. > >Thats great news! > Indeed! >> The only bad side effect that I noticed is that SQLite doesn't allow >> the LIMIT clause when using DELETE or UPDATE unlike MySQL. Bummer. >> So what happens is when you update a row there's no way to tell it to >> limit it to one instance. The workaround I coded was to update the >> row where the old values match. That'll work, but it will also >> update/delete if there's more than one row. If you guys know a >> workaround to create a safety net, that'd be cool. Of course, it's a >> rare occurence it'd be needed, but still. > >well right now I don't know a real workaround for that... maybe we >should disable row edit/delete in case a table has no primary key, or >an other possibility would be to show an intermediary page that shows >the user which rows are to be updated/deleted (in case more than 1 row >would be affected) > IMO, we should lok for a primary key, if not found return error. >> The other thing is that in order to access SQLite through the web on >> linux, the database AND it's directory need to be world writeable. >> So I created a new directory named db and dumped phpsla.sqilte in >> there. > >very good idea, thank you! Good idea to organize things (including the other folders u created) > >> What's the best way to submit patches anyway? > >right now I'd say, send them to this list as an attachment. In case you >want to contribute regurlarly, using cvs would be the best. > >hope to hear from you soon, >Yves > >> Steve >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: >> Sybase ASE Linux Express Edition - download now for FREE >> LinuxWorld Reader's Choice Award Winner for best database on Linux. >> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click >> _______________________________________________ >> Phpsqliteadmin-devel mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpsqliteadmin-devel > >-- >Linux 2.6.8.1 #1 Sun Oct 31 11:27:19 CET 2004 i686 > 11:04:26 up 57 min, 1 user, load average: 2.13, 1.09, 1.22 > >------------------------------------------------------- >This SF.Net email is sponsored by: >Sybase ASE Linux Express Edition - download now for FREE >LinuxWorld Reader's Choice Award Winner for best database on Linux. >http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click >_______________________________________________ >Phpsqliteadmin-devel mailing list >Php...@li... >https://lists.sourceforge.net/lists/listinfo/phpsqliteadmin-devel > >------- _________________________________________________________________________________ Quer mais velocidade? Só com o acesso Aditivado iG, a velocidade que você quer na hora que você precisa. Clique aqui: http://www.acessoaditivado.ig.com.br |
|
From: Yves G. <yg...@mi...> - 2004-11-07 19:04:38
|
On Sunday 07 November 2004 18:47, Steve Dibb wrote: > Here, its probably easier to show you what I'm up to, though it's > halfway functional. :) wow, it looks great :-) are you using any IM as icq, that would make communication easier...? > uname: sdibb > pwd: sdibb > > http://sdibb.frogcircus.org/psa/psa_20041107.tgz > > Steve > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick > _______________________________________________ > Phpsqliteadmin-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpsqliteadmin-devel =2D-=20 Linux 2.6.9 #1 Mon Nov 1 12:01:23 CET 2004 i686 20:03:31 up 41 min, 1 user, load average: 0.74, 0.72, 0.81 |
|
From: Steve D. <sd...@wo...> - 2004-11-07 18:46:59
|
Here, its probably easier to show you what I'm up to, though it's halfway functional. :) uname: sdibb pwd: sdibb http://sdibb.frogcircus.org/psa/psa_20041107.tgz Steve |
2 messages has been excluded from this view by a project administrator.
