phplib-users — A list for users of phplib to talk / discuss phplib

Re: [Phplib-users] RE: sys_procedures

[nathan r. h. <na...@ds...>]

On Thu, 15 Nov 2001, Frank Bax wrote:

> Where should Bob's sys_procedure code go within phplib?
>
> I just had a look at this.  It didn't take me long to find that phplib has
> a fundamental problem.  I only supports a single database per installation!
>  Excuse me if this has been observed before, but I just realised it; I
> never went much beyond local.inc before today.
>

Woah!  It does, you just need multiple local.inc's and / or prepend.php3's
So, it does, just not within the same instance.

> Here's my suggestion:
>
> 1) DB_Sql in each of the db_*.inc files should be named specific to the
> database being supported (like DB_Sql_pgsql or DB_Sql_mysql).
>
> 2) _prepend.php should be allowed to 'require' multiple database inc's if a
> site wishes; and then add:
> 	class DB_SQL extends DB_Sql_xxx {
> 		/* include Bob's sys_procedure code here */
> 	}
> Many of the one-liner functions could be moved here too, when they are
> identical in all databases supported.
>
> Or maybe I've got it backwards.  Should the common stuff be in the base
> class and DB_Sql_PG and DB_Sql_mysql extend that one?  Then DB_Sql (as
> above) will empty just for compatibility with existing versions.  This OO
> stuff hurts my head.
>

Yes, it's backwards :)

class db_skel {
  foo
  bar
}

class db_mysql extends db_skel {
  mysqlSpecficFoo
}

class My_Example_db extends db_mysql {
  connect
  username
  password
  my_exmaple_mysql_specfic_foo
}

Etc.. the db interface needs serious help, as since everything a lot of
stuff is repeated in the various classes.  the ideal would be to define
the base API in a skel class with the helper functions already defined and
have the db specfic classes ("drivers" if you will, for lack of a better
term) extend the API to provide what's needed.  This will also allow for
better support for the various db specfic things.

[snipping rest, must read it later.. looks cool]

-n
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
nathan hruby / digital statement
na...@ds...
http://www.dstatement.com/

Public GPG key can be found at:
http://www.dstatement.com/nathan-gpg-key.txt
ED54 9A5E 132D BD01 9103  EEF3 E1B9 4738 EC90 801B
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [Phplib-users] RE: sys_procedures

[Frank B. <fb...@sy...>]

Where should Bob's sys_procedure code go within phplib?  

I just had a look at this.  It didn't take me long to find that phplib has
a fundamental problem.  I only supports a single database per installation!
 Excuse me if this has been observed before, but I just realised it; I
never went much beyond local.inc before today.

Here's my suggestion:

1) DB_Sql in each of the db_*.inc files should be named specific to the
database being supported (like DB_Sql_pgsql or DB_Sql_mysql).

2) _prepend.php should be allowed to 'require' multiple database inc's if a
site wishes; and then add:
	class DB_SQL extends DB_Sql_xxx {
		/* include Bob's sys_procedure code here */
	}
Many of the one-liner functions could be moved here too, when they are
identical in all databases supported.

Or maybe I've got it backwards.  Should the common stuff be in the base
class and DB_Sql_PG and DB_Sql_mysql extend that one?  Then DB_Sql (as
above) will empty just for compatibility with existing versions.  This OO
stuff hurts my head.

In the meantime, I've decided that the interesting part of execproc()
should be a separate function, as in:

  function subsql($sql, $argv="") {
    if (is_array($argv)) {
      foreach ($argv as $key=>$val) {
        $sql = ereg_replace("{".strtoupper($key)."}", $val, $sql);
      }
    }
    return $sql;
  }

Frank


At 11:03 PM 11/9/01 -0800, Philip Strnad wrote:
>Bob,
>
>For the include file I was thinking of something like this:
>
><?
>$queries = array("get_2_specials" => "select * from table where x =
{variable}",
>...);
>?>
>
>Then you could access the query in $queries easily by looking it up by its
name and
>you could have your function to replace the variables with real values
passed to
>the function in a hash or whatever.  I think this would be pretty
organized, but
>again it's just a matter of preference.
>
>About the databases and which class this stuff could be added to:  the
only reason
>I said it would be good for the MySQL class is that for other databases that
>support exectuion of server-side code in the database itself (Oracle, SQL
Server,
>etc), it would probably be preferable to use the database's built in language
>instead of doing the sys_procedures thing.  Although the sys_procedure
thing would
>work in these other databases it would probably not add much value, unless of
>course you want to make your code really database independent.  I think
the general
>direction for database abstraction classes is always to make them generic
so they
>work with different databases so that might be the way to go.
>
>Anyway, those are just my thoughts on this.  Since I do use MySQL for my
PHP stuff
>I would probably take advantage of this if it were available.
>
>Philip
>
>
>Bob Bowker wrote:
>
>> Philip --
>>
>> Yes, an include file could contain the SQL, but I think that managing this
>> storage scheme would soon become counter-productive ... keeping track of
>> which file contains which procedure, then committing the extra clock cycles
>> to open and parse every needed text file (vs the clock cycles for MySQL to
>> do the same thing) ... but yes, this would work ...
>>
>> I'm not very knowledgeable when it comes to the other DBs supported by PHP
>> and phpLib, but I'm sure that a similar - or even cross-DB - version could
>> be written.  But I think that, if anything, an example class extension in
>> local.inc may be preferable to adding everything to one DB class ... two
>> advantages:
>>
>> 1. if a user understands the sys_procedures concepts, they'll be used, and
>> if not, they'll be ignored.  To me this is better than more posts that "...
>> the distribution is broken because I can't get it to work" ...
>>
>> 2. users with the ability to apply the concepts to other DB packages will
>> be able to do so - if we commit the code to mysql.inc then others are
left out.
>>
>> Just my 2 cents worth ... but I'm glad this methodology seems to be useful
>> to a few others.
>>
>> This methodology is indeed probably a direct descendent of functions built
>> into other databases ... I haven't credited Cheng-Wei Cheng enough in these
>> posts.  He worked for us about 2 years ago, making major contributions to
>> what is still the biggest site we've done.  He built the framework for much
>> of the database schema, and in fact wrote the original version of our DB
>> class functions which handle the procedures.  And his Computer Sciences
>> degree probably laid the foundation for this ...
>>
>> Bob.
>>
>> At 12:08 AM 11/9/2001 -0800, you wrote:
>> >This is pretty cool.  It looks similar to real stored procedures ala
PL/SQL in
>> >Oracle, except that the procedures are pure SQL queries and they are not
>> >executed
>> >directly in the database (you have to query to get the query into your PHP
>> >script, and then send it back to the database for it to get executed).  It
>> >also
>> >reminds me of the Perl DBI or any other db interface that makes use of
"bind
>> >variables."
>> >
>> >I guess you could also store the queries in an include file right?  But
some
>> >people prefer to have stuff in the database.  I agree that this might be a
>> >useful
>> >addition to the db class, especially for MySQL users.
>> >
>> >Philip
>> >
>> >
>> >Bob Bowker wrote:
>> >
>> > > Brian --
>> > >
>> > > Nope, no reason at all ... except that the two-step seemed a bit more
>> > > logical at the time - my only defence is, "that's the way my mind
works"
>> > > ...!  It also makes subsequent use of the procedure in the same
script easy
>> > > - the procedure is already loaded and the class' variables are already
>> > > initialized.  Something to think about if you call the procedure
within a
>> > > loop ...
>> > >
>> > > Adding this to phpLib might be possible, but as you say, it's not yer
>> > > Daddy's Chevrolet, and there are already enough complaints that "...
the
>> > > distribution is busted cause I can't make it work".  Adding a couple of
>> > > vars and 2 functions to your DB class is easy, and upgrades to
phpLib are
>> > > simpler to install ...
>> > >
>> > > Maybe an "Example_SysProcedures_DB extends DB_Poe" in the local.inc as
>> > > distributed would do the trick, but ...
>> > >
>> > > My version of this code is available for anyone to fix up, improve, or
>> > > include in phpLib ... just give me a shout if you make it better so
I can
>> > > benefit, too!
>> > >
>> > > Bob.
>> > >
>> > > At 01:25 PM 11/8/2001 -0600, you wrote:
>> > > >Very nice.. not to complicate things, but is there any reason why you
>> > > >couldn't/wouldn't combine proc and execproc? Something like this:
>> > > >
>> > > >$parameters[FORMAT] = "CD";
>> > > >$parameters[TRACK]  = "Smells Like Teen Spirit";
>> > > >$parameters[ARTIST] = "Nirvana";
>> > > >
>> > > >$db->execproc ( "get_2_specials", $parameters );
>> > > >
>> > > >Regardless, I think this is a VERY powerful concept. Anybody else
up for
>> > > >adding it to PHPLib officially? Granted, it's a little
high(er)-level, but
>> > > >it wouldn't affect the class in the slightest for those that didn't
choose
>> > > >to use it.
>> > > >
>> > > >BPopp
>> > > >
>> > > >
>> > > >-----Original Message-----
>> > > >From: Bob Bowker [mailto:bo...@iN...]
>> > > >Sent: Thursday, November 08, 2001 12:02 PM
>> > > >To: Php...@li...
>> > > >Cc: jwi...@ma...; bp...@ct...;
>> > > >Kar...@co...
>> > > >Subject: sys_procedures
>> > > >
>> > > >
>> > > >Hi --
>> > > >
>> > > >OK, here goes ...
>> > > >
>> > > >==================================================
>> > > >"sys_procedures" is a table which contains the actual SQL queries ...
>> > > >
>> > > >CREATE TABLE sys_procedures (
>> > > >    id int(11) NOT NULL auto_increment,
>> > > >    name varchar(20) NOT NULL default '',
>> > > >    description varchar(40) default NULL,
>> > > >    sql text,
>> > > >    dt_create datetime NOT NULL default '0000-00-00 00:00:00',
>> > > >    dt_modify timestamp(14) NOT NULL,
>> > > >    argc int(2) unsigned NOT NULL default '0',
>> > > >    PRIMARY KEY  (id),
>> > > >    KEY name (name,dt_create,dt_modify)
>> > > >) TYPE=MyISAM;
>> > > >
>> > > >==================================================
>> > > >Within your DB class, add the following:
>> > > >
>> > > >    /* Store procedure enhancement: configurable*/
>> > > >    var $procedure_table = "sys_procedures";
>> > > >    var $proc_name;
>> > > >    var $sql = array();
>> > > >    var $argc;
>> > > >    var $finalQuery;
>> > > >
>> > > >     function proc($name) {
>> > > >        if ( !is_array($this->sql) ) {
>> > > >           $this->sql[$name] = "";
>> > > >           $this->argc[$name] = 0;
>> > > >        }
>> > > >        if ( strlen($name) > 0) {
>> > > >           ##This should be the only line of embedded Sql in the
>> > application
>> > > >           $qry = "SELECT sql, argc FROM ".$this->procedure_table."
WHERE
>> > > >name = '".$name."' ";
>> > > >           if (strlen($this->sql[$name]) == 0  && $this->query($qry)){
>> > > >              $this->next_record();
>> > > >              $this->sql[$name] = $this->f("sql");
>> > > >              $this->argc[$name] = $this->f("argc");
>> > > >           }
>> > > >           $this->proc_name = $name;
>> > > >           return true;
>> > > >        }
>> > > >        return false;
>> > > >     }
>> > > >
>> > > >     function execproc($argv="") {
>> > > >        $this->finalQuery = $this->sql[$this->proc_name];
>> > > >        if (is_array($argv)) {
>> > > >           reset($argv);
>> > > >           $c = count($argv);
>> > > >           for ($i=0 ; $i<$c ; $i++) {
>> > > >              $value = $argv[key($argv)];
>> > > >              $this->finalQuery =
>> > > >ereg_replace("{".strtoupper(key($argv))."}", $value,
$this->finalQuery);
>> > > >              next($argv);
>> > > >           }
>> > > >        }
>> > > >        $qry = $this->finalQuery;
>> > > >        if (( count($argv) >= $this->argc[$this->proc_name] ) ||
>> > > >($this->argc[$this->proc_name] == 0) ) {
>> > > >           return $this->query($qry);
>> > > >        } else {
>> > > >           return false;
>> > > >        }
>> > > >     }
>> > > >
>> > > >==================================================
>> > > >Let's say you have an SQL query that searches 400,000 records for
>> > "Madonna"
>> > > >and "DVD" ... the data is normalized across a half-dozen tables,
and the
>> > > >query uses JOIN and every MySQL trick I know to speed things up.
I'm also
>> > > >going to want to search (elsewhere) for "CD", and "Collector", and
>> > > >"VHS".  I used to debug the query in DVDs, then cut-and-paste it
into the
>> > > >CD script, change the variables, and debug it all over again ...
ditto for
>> > > >Collector, VHS, and so on.
>> > > >
>> > > >Or, in the CD PHP code, you can do the following:
>> > > >           $word = "Madonna"; $fmt = "CD";
>> > > >           $query = $db->proc("get_2_specials");
>> > > >           $argv = array(FORMAT=>"$fmt",TYPE=>"$word");
>> > > >           $db->execproc($argv);
>> > > >
>> > > >Or, in the DVD "department", the following:
>> > > >           $word = "Madonna"; $fmt = "DVD";
>> > > >           $query = $db->proc("get_2_specials");
>> > > >           $argv = array(FORMAT=>"$fmt",TYPE=>"$word");
>> > > >           $db->execproc($argv);
>> > > >
>> > > >For clarity, I've deleted a dozen other members of the array which get
>> > > >passed to the class function ... but I'm sure you get the idea.  The
>> > > >"finalQuery" variable, by the way, is *very* useful for debugging!
>> > > >
>> > > >==================================================
>> > > >In practice ...
>> > > >
>> > > >1. I write the query and test it using hard values and "explain" in
>> > > >PhpMyAdmin ...
>> > > >
>> > > >2. when the tables are optimized and the query is working the way I
>> > want, I
>> > > >copy the query into my PHP script and substitute variables for the
hard
>> > > >values ...
>> > > >
>> > > >3. when that's working the way I want, I re-write the query
substituting
>> > > >placeholders for the variables and store that in the sys_procedures
table
>> > > >...
>> > > >
>> > > >4. finally, I substitute the 3 lines (or so) of PHP code for the query
>> > > >itself in my script, and I'm done.
>> > > >
>> > > >The tables are now optimized for the query, and the debugged query is
>> > > >available to all other scripts (I can cut-and-paste just the 3
lines of
>> > > >code) ... and I may get out of here on time tonight!
>> > > >
>> > > >==================================================
>> > > >
>> > > >Please let me know if I've left anything out ... and give a shout
if I can
>> > > >help ...
>> > > >
>> > > >Bob.

RE: [Phplib-users] minor problem(?) with Auth feature

[Brian P. <bp...@ct...>]

That's not a PHPLib thing. If anything, it would be PHP related. I am
guessing it was probably neither. It was most likely just a =
coincidence.=20

Are you remembering to put page_close() at the bottom of the page?

<?=20
	page_open(...);
=09
	<actual code here>

	page_close();
?>

-----Original Message-----
From: Manuel Aristaran [mailto:mpa...@so...]
Sent: Wednesday, November 14, 2001 8:27 PM
To: php...@li...
Subject: [Phplib-users] minor problem(?) with Auth feature


Hi...

I have some protected pages using the Auth feature of PHPLIB.
When i first tested it, it didn't work, but making an apparently =
harmless=20
change made it work:

The version of the script that failed looked like this:

<?php
   page_open(array("sess" =3D> "Gili_Session", "auth" =3D> =
"Gili_auth"));

   <actual code here>
?>

And with the "harmless" change:

<?php
   page_open(array("sess" =3D> "Gili_Session", "auth" =3D> =
"Gili_auth"));
?>
<?php
   <actual code here>
?>

Of course this isn't really a problem, but i'm really curious of why =
this=20
happens. PHP interpreter gotchas perhaps?

Manuel Aristar=E1n
mpa...@so...
Bah=EDa Blanca, Argentina


_______________________________________________
Phplib-users mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] Re: PHPlib double login

[Lazaro F. <la...@ii...>]

Hi

Can you share with us, those way of doing it without cookies

Thanks
Lazaro

----- Original Message -----
From: Guneshwar Mayanglambam <may...@pe...>
To: Donncha O Caoimh <don...@tr...>;
<php...@li...>
Sent: Wednesday, November 14, 2001 2:33 PM
Subject: [Phplib-users] Re: PHPlib double login


> Hello Donncha,
>
> Thanks a lot for the insight. I got my script working. But I found out a
way
> to avoid using cookies.
> It just works without cookies, so that browsers where cookies are not
> enabled are also not affected.
>
> Thanks a lot.
>
> Guneshwar.M
>
>
> ----- Original Message -----
> From: "Donncha O Caoimh" <don...@tr...>
> To: "Guneshwar Mayanglambam" <may...@pe...>;
> <php...@li...>
> Sent: Tuesday, November 13, 2001 6:57 PM
> Subject: Re: PHPlib double login
>
>
> > oh.. ok, when a user revists your site, instead of *ONLY* matching the
> > SID, you also match the UID that's in the same record as that SID. If
> > they don't match then another user has logged in using that UID.
> > Example:
> > user1 logs in with username: "joe"
> > He gets sent the following in a cookie:
> >   uid: 111
> >   sid: 222
> > Each time he revists those two values are checked.
> >
> > Now, user2, who knows the password for "joe" logs in and is sent the
> > following via the cookie:
> >   uid: 111
> >   sid: 333
> > This guy now uses the site away..
> >
> > user1 comes back after a cup of tea to his PC and attempts to use your
> > site.
> > His PC sends uid 111 and sid 222 to your server. Your server checks the
> > sid for uid 111, finds that it's now set to 333 and tells the user to
> > login again. When he logs in user2 gets logged out..
> >
> > ---
> > session database table:
> > uid char(32)
> > sid char(32)
> > ---
> >
> > Posting to the mailing list too in case anyone else was confused... (and
> > because this is such a long email!)
> >
> > Donncha.
> >
> > Guneshwar Mayanglambam wrote:
> > >
> > > Hello,
> > >
> > > In the mailing list you wrote the following
> > > -----------------------------------
> > > When someone logs in, set a cookie on their machine with a session
> > > ID(SID) and record this session ID in a table along with their UID.
> > > There's only one record in that table per user. Each time they visit
the
> > > site you check that table so that the UID matches the SID, if not,
they
> > > must be logged in twice!
> > > --------------------------------------
> > >
> > > Here, what is a bit confusing for me is that the cookie stored in the
> usres
> > > machine is the SID, then i store the sid and the UID in a table.
> > >
> > > But when a user visits the site i will check the table for the SID
that
> is
> > > the SID of the cookie and the SID in the table for that user. But you
> have
> > > mentioned that "so that the UID matches the SID". This is a bit
> confusing
> > > for me.
> > >
> > > Thanks again for the reply and for your help.
> > >
> > > Guneshwar.M
>
>
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>

Re: [Phplib-users] minor problem(?) with Auth feature

[kalle \(Camelot\) <ka...@ca...>]

> The version of the script that failed looked like this:
> 
> <?php
>    page_open(array("sess" => "Gili_Session", "auth" => "Gili_auth"));
> 
>    <actual code here>
> ?>
> 
> And with the "harmless" change:
> 
> <?php
>    page_open(array("sess" => "Gili_Session", "auth" => "Gili_auth"));
> ?>
> <?php
>    <actual code here>
> ?>
so what happend?
Not asking anything  triggers no aks.

[Phplib-users] minor problem(?) with Auth feature

[Manuel A. <mpa...@so...>]

Hi...

I have some protected pages using the Auth feature of PHPLIB.
When i first tested it, it didn't work, but making an apparently harmless=20
change made it work:

The version of the script that failed looked like this:

<?php
   page_open(array("sess" =3D> "Gili_Session", "auth" =3D> "Gili_auth"));

   <actual code here>
?>

And with the "harmless" change:

<?php
   page_open(array("sess" =3D> "Gili_Session", "auth" =3D> "Gili_auth"));
?>
<?php
   <actual code here>
?>

Of course this isn't really a problem, but i'm really curious of why this=20
happens. PHP interpreter gotchas perhaps?

Manuel Aristar=E1n
mpa...@so...
Bah=EDa Blanca, Argentina

[Phplib-users] Re: PHPlib double login

[Guneshwar M. <may...@pe...>]

Hello Donncha,

Thanks a lot for the insight. I got my script working. But I found out a way
to avoid using cookies.
It just works without cookies, so that browsers where cookies are not
enabled are also not affected.

Thanks a lot.

Guneshwar.M


----- Original Message -----
From: "Donncha O Caoimh" <don...@tr...>
To: "Guneshwar Mayanglambam" <may...@pe...>;
<php...@li...>
Sent: Tuesday, November 13, 2001 6:57 PM
Subject: Re: PHPlib double login


> oh.. ok, when a user revists your site, instead of *ONLY* matching the
> SID, you also match the UID that's in the same record as that SID. If
> they don't match then another user has logged in using that UID.
> Example:
> user1 logs in with username: "joe"
> He gets sent the following in a cookie:
>   uid: 111
>   sid: 222
> Each time he revists those two values are checked.
>
> Now, user2, who knows the password for "joe" logs in and is sent the
> following via the cookie:
>   uid: 111
>   sid: 333
> This guy now uses the site away..
>
> user1 comes back after a cup of tea to his PC and attempts to use your
> site.
> His PC sends uid 111 and sid 222 to your server. Your server checks the
> sid for uid 111, finds that it's now set to 333 and tells the user to
> login again. When he logs in user2 gets logged out..
>
> ---
> session database table:
> uid char(32)
> sid char(32)
> ---
>
> Posting to the mailing list too in case anyone else was confused... (and
> because this is such a long email!)
>
> Donncha.
>
> Guneshwar Mayanglambam wrote:
> >
> > Hello,
> >
> > In the mailing list you wrote the following
> > -----------------------------------
> > When someone logs in, set a cookie on their machine with a session
> > ID(SID) and record this session ID in a table along with their UID.
> > There's only one record in that table per user. Each time they visit the
> > site you check that table so that the UID matches the SID, if not, they
> > must be logged in twice!
> > --------------------------------------
> >
> > Here, what is a bit confusing for me is that the cookie stored in the
usres
> > machine is the SID, then i store the sid and the UID in a table.
> >
> > But when a user visits the site i will check the table for the SID that
is
> > the SID of the cookie and the SID in the table for that user. But you
have
> > mentioned that "so that the UID matches the SID". This is a bit
confusing
> > for me.
> >
> > Thanks again for the reply and for your help.
> >
> > Guneshwar.M

[Phplib-users] Re: PHPlib double login

[Donncha O C. <don...@tr...>]

oh.. ok, when a user revists your site, instead of *ONLY* matching the
SID, you also match the UID that's in the same record as that SID. If
they don't match then another user has logged in using that UID.
Example:
user1 logs in with username: "joe"
He gets sent the following in a cookie:
  uid: 111
  sid: 222
Each time he revists those two values are checked.

Now, user2, who knows the password for "joe" logs in and is sent the
following via the cookie:
  uid: 111
  sid: 333
This guy now uses the site away..

user1 comes back after a cup of tea to his PC and attempts to use your
site.
His PC sends uid 111 and sid 222 to your server. Your server checks the
sid for uid 111, finds that it's now set to 333 and tells the user to
login again. When he logs in user2 gets logged out..

---
session database table:
uid char(32)
sid char(32)
---

Posting to the mailing list too in case anyone else was confused... (and
because this is such a long email!)

Donncha.

Guneshwar Mayanglambam wrote:
> 
> Hello,
> 
> In the mailing list you wrote the following
> -----------------------------------
> When someone logs in, set a cookie on their machine with a session
> ID(SID) and record this session ID in a table along with their UID.
> There's only one record in that table per user. Each time they visit the
> site you check that table so that the UID matches the SID, if not, they
> must be logged in twice!
> --------------------------------------
> 
> Here, what is a bit confusing for me is that the cookie stored in the usres
> machine is the SID, then i store the sid and the UID in a table.
> 
> But when a user visits the site i will check the table for the SID that is
> the SID of the cookie and the SID in the table for that user. But you have
> mentioned that "so that the UID matches the SID". This is a bit confusing
> for me.
> 
> Thanks again for the reply and for your help.
> 
> Guneshwar.M

Re: [Phplib-users] user-behavior tracking

[Pisica V. <pis...@al...>]

Thank you for your answer - it was the end of my worries :-)





>search for phpOpenTracker
>should have it all....
>



________________________________________________________________________
Singurul serviciu 100% confidential din Romania : http://mail.alabala.ro

Re: [Phplib-users] New to PHP and PHPLIB

[Dr T. S. <ta...@na...>]

On Mon, 12 Nov 2001, Lazaro Ferreira wrote:
Hi Lazaro,

try www.soysal.com/PHPEd/ and www.phpedit.com 

a new IDE is available from www.pentap.net 

a Linux based one was available from www.nexidion.org but the site looks
off line now

Any of the above should suffice your requirement

Cheers
Tarique

> Hi
> 
> I'm a two years old PHPLIB programmer
> 
> Do you know where to find a review for the most popular PHP IDEs, or at
> least some TIPS on it, I should try a PHP IDE, because productivity begins
> to be critical for me, but I would like to know which of them better match
> my requirements
> 
> My Development Environment
> WIN98/ Apache 1.3.19 / PHP4.0.4Pl1 / MYSQL 3.23.29 / PHPLIB7.2c
> 
> My Production Environment
> RedHat7.1 / Apache 1.3.14 / PHP4.0.4Pl1 / MYSQL 3.23.32 / PHPLIB7.2c
> 
> A primary goal for me, is debugging on my windows local Apache instead of
> doing it on the server
> 
> Thanks
> Lazaro
> 
> 
> ----- Original Message -----
> From: Tarique Sani <ta...@sa...> <ro...@sa...>
> To: Thomas Widlar <tw...@cr...>
> Cc: <Php...@li...>
> Sent: Saturday, November 10, 2001 5:28 AM
> Subject: Re: [Phplib-users] New to PHP and PHPLIB
> 
> 
> > On Fri, 9 Nov 2001, Thomas Widlar wrote:
> >
> > > I am not at all new to programming, but I am just
> > > starting with PHP and web programming beyond simple
> > > HTML.
> >
> > Welcome!
> >
> > > 2. I have obtained the Zend-IDE
> > > 'ZendIDEClient-TestDrive-1.1.0-Windows'. The Zend website
> > > says the ZendIDE is only for Win2000. I saw somewhere that
> > > the Zend-IDE is written in Java, which probably means it
> > > was developed from NetBeans, which does run in WinME.
> > > So, will the Zend-IDE work on my WinME PHPTriad setup?
> >
> > Forget ZendIDEClient! I never got it to work ...
> >
> > if you are using windows use PHPed, yes I know the
> > later versions are commercial but older versions are still available and
> > perfectly usable, you can also try PHPedit
> >
> > With PHPed thoug you would like to upgarde the debugger to a later
> > version.
> >
> > Cheers
> >
> > Tarique
> >
> > --
> > ==========================================================
> > PHP Applications for E-Biz : http://www.sanisoft.com
> >
> > The Ultimate Ghazal Lexicon: http://www.aaina-e-ghazal.com
> > ==========================================================
> >
> >
> > _______________________________________________
> > Phplib-users mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phplib-users
> >
> >
> 
> 
> 
> 
> 

-- 
==========================================================
PHP Applications for E-Biz : http://www.sanisoft.com

The Ultimate Ghazal Lexicon: http://www.aaina-e-ghazal.com
==========================================================

Re: [Phplib-users] New to PHP and PHPLIB

[Lazaro F. <la...@ii...>]

Hi

I'm a two years old PHPLIB programmer

Do you know where to find a review for the most popular PHP IDEs, or at
least some TIPS on it, I should try a PHP IDE, because productivity begins
to be critical for me, but I would like to know which of them better match
my requirements

My Development Environment
WIN98/ Apache 1.3.19 / PHP4.0.4Pl1 / MYSQL 3.23.29 / PHPLIB7.2c

My Production Environment
RedHat7.1 / Apache 1.3.14 / PHP4.0.4Pl1 / MYSQL 3.23.32 / PHPLIB7.2c

A primary goal for me, is debugging on my windows local Apache instead of
doing it on the server

Thanks
Lazaro


----- Original Message -----
From: Tarique Sani <ta...@sa...> <ro...@sa...>
To: Thomas Widlar <tw...@cr...>
Cc: <Php...@li...>
Sent: Saturday, November 10, 2001 5:28 AM
Subject: Re: [Phplib-users] New to PHP and PHPLIB


> On Fri, 9 Nov 2001, Thomas Widlar wrote:
>
> > I am not at all new to programming, but I am just
> > starting with PHP and web programming beyond simple
> > HTML.
>
> Welcome!
>
> > 2. I have obtained the Zend-IDE
> > 'ZendIDEClient-TestDrive-1.1.0-Windows'. The Zend website
> > says the ZendIDE is only for Win2000. I saw somewhere that
> > the Zend-IDE is written in Java, which probably means it
> > was developed from NetBeans, which does run in WinME.
> > So, will the Zend-IDE work on my WinME PHPTriad setup?
>
> Forget ZendIDEClient! I never got it to work ...
>
> if you are using windows use PHPed, yes I know the
> later versions are commercial but older versions are still available and
> perfectly usable, you can also try PHPedit
>
> With PHPed thoug you would like to upgarde the debugger to a later
> version.
>
> Cheers
>
> Tarique
>
> --
> ==========================================================
> PHP Applications for E-Biz : http://www.sanisoft.com
>
> The Ultimate Ghazal Lexicon: http://www.aaina-e-ghazal.com
> ==========================================================
>
>
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>

Re: [Phplib-users] RE: sys_procedures

[Philip S. <ph...@st...>]

Bob,

For the include file I was thinking of something like this:

<?
$queries = array("get_2_specials" => "select * from table where x = {variable}",
...);
?>

Then you could access the query in $queries easily by looking it up by its name and
you could have your function to replace the variables with real values passed to
the function in a hash or whatever.  I think this would be pretty organized, but
again it's just a matter of preference.

About the databases and which class this stuff could be added to:  the only reason
I said it would be good for the MySQL class is that for other databases that
support exectuion of server-side code in the database itself (Oracle, SQL Server,
etc), it would probably be preferable to use the database's built in language
instead of doing the sys_procedures thing.  Although the sys_procedure thing would
work in these other databases it would probably not add much value, unless of
course you want to make your code really database independent.  I think the general
direction for database abstraction classes is always to make them generic so they
work with different databases so that might be the way to go.

Anyway, those are just my thoughts on this.  Since I do use MySQL for my PHP stuff
I would probably take advantage of this if it were available.

Philip


Bob Bowker wrote:

> Philip --
>
> Yes, an include file could contain the SQL, but I think that managing this
> storage scheme would soon become counter-productive ... keeping track of
> which file contains which procedure, then committing the extra clock cycles
> to open and parse every needed text file (vs the clock cycles for MySQL to
> do the same thing) ... but yes, this would work ...
>
> I'm not very knowledgeable when it comes to the other DBs supported by PHP
> and phpLib, but I'm sure that a similar - or even cross-DB - version could
> be written.  But I think that, if anything, an example class extension in
> local.inc may be preferable to adding everything to one DB class ... two
> advantages:
>
> 1. if a user understands the sys_procedures concepts, they'll be used, and
> if not, they'll be ignored.  To me this is better than more posts that "...
> the distribution is broken because I can't get it to work" ...
>
> 2. users with the ability to apply the concepts to other DB packages will
> be able to do so - if we commit the code to mysql.inc then others are left out.
>
> Just my 2 cents worth ... but I'm glad this methodology seems to be useful
> to a few others.
>
> This methodology is indeed probably a direct descendent of functions built
> into other databases ... I haven't credited Cheng-Wei Cheng enough in these
> posts.  He worked for us about 2 years ago, making major contributions to
> what is still the biggest site we've done.  He built the framework for much
> of the database schema, and in fact wrote the original version of our DB
> class functions which handle the procedures.  And his Computer Sciences
> degree probably laid the foundation for this ...
>
> Bob.
>
> At 12:08 AM 11/9/2001 -0800, you wrote:
> >This is pretty cool.  It looks similar to real stored procedures ala PL/SQL in
> >Oracle, except that the procedures are pure SQL queries and they are not
> >executed
> >directly in the database (you have to query to get the query into your PHP
> >script, and then send it back to the database for it to get executed).  It
> >also
> >reminds me of the Perl DBI or any other db interface that makes use of "bind
> >variables."
> >
> >I guess you could also store the queries in an include file right?  But some
> >people prefer to have stuff in the database.  I agree that this might be a
> >useful
> >addition to the db class, especially for MySQL users.
> >
> >Philip
> >
> >
> >Bob Bowker wrote:
> >
> > > Brian --
> > >
> > > Nope, no reason at all ... except that the two-step seemed a bit more
> > > logical at the time - my only defence is, "that's the way my mind works"
> > > ...!  It also makes subsequent use of the procedure in the same script easy
> > > - the procedure is already loaded and the class' variables are already
> > > initialized.  Something to think about if you call the procedure within a
> > > loop ...
> > >
> > > Adding this to phpLib might be possible, but as you say, it's not yer
> > > Daddy's Chevrolet, and there are already enough complaints that "... the
> > > distribution is busted cause I can't make it work".  Adding a couple of
> > > vars and 2 functions to your DB class is easy, and upgrades to phpLib are
> > > simpler to install ...
> > >
> > > Maybe an "Example_SysProcedures_DB extends DB_Poe" in the local.inc as
> > > distributed would do the trick, but ...
> > >
> > > My version of this code is available for anyone to fix up, improve, or
> > > include in phpLib ... just give me a shout if you make it better so I can
> > > benefit, too!
> > >
> > > Bob.
> > >
> > > At 01:25 PM 11/8/2001 -0600, you wrote:
> > > >Very nice.. not to complicate things, but is there any reason why you
> > > >couldn't/wouldn't combine proc and execproc? Something like this:
> > > >
> > > >$parameters[FORMAT] = "CD";
> > > >$parameters[TRACK]  = "Smells Like Teen Spirit";
> > > >$parameters[ARTIST] = "Nirvana";
> > > >
> > > >$db->execproc ( "get_2_specials", $parameters );
> > > >
> > > >Regardless, I think this is a VERY powerful concept. Anybody else up for
> > > >adding it to PHPLib officially? Granted, it's a little high(er)-level, but
> > > >it wouldn't affect the class in the slightest for those that didn't choose
> > > >to use it.
> > > >
> > > >BPopp
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: Bob Bowker [mailto:bo...@iN...]
> > > >Sent: Thursday, November 08, 2001 12:02 PM
> > > >To: Php...@li...
> > > >Cc: jwi...@ma...; bp...@ct...;
> > > >Kar...@co...
> > > >Subject: sys_procedures
> > > >
> > > >
> > > >Hi --
> > > >
> > > >OK, here goes ...
> > > >
> > > >==================================================
> > > >"sys_procedures" is a table which contains the actual SQL queries ...
> > > >
> > > >CREATE TABLE sys_procedures (
> > > >    id int(11) NOT NULL auto_increment,
> > > >    name varchar(20) NOT NULL default '',
> > > >    description varchar(40) default NULL,
> > > >    sql text,
> > > >    dt_create datetime NOT NULL default '0000-00-00 00:00:00',
> > > >    dt_modify timestamp(14) NOT NULL,
> > > >    argc int(2) unsigned NOT NULL default '0',
> > > >    PRIMARY KEY  (id),
> > > >    KEY name (name,dt_create,dt_modify)
> > > >) TYPE=MyISAM;
> > > >
> > > >==================================================
> > > >Within your DB class, add the following:
> > > >
> > > >    /* Store procedure enhancement: configurable*/
> > > >    var $procedure_table = "sys_procedures";
> > > >    var $proc_name;
> > > >    var $sql = array();
> > > >    var $argc;
> > > >    var $finalQuery;
> > > >
> > > >     function proc($name) {
> > > >        if ( !is_array($this->sql) ) {
> > > >           $this->sql[$name] = "";
> > > >           $this->argc[$name] = 0;
> > > >        }
> > > >        if ( strlen($name) > 0) {
> > > >           ##This should be the only line of embedded Sql in the
> > application
> > > >           $qry = "SELECT sql, argc FROM ".$this->procedure_table." WHERE
> > > >name = '".$name."' ";
> > > >           if (strlen($this->sql[$name]) == 0  && $this->query($qry)){
> > > >              $this->next_record();
> > > >              $this->sql[$name] = $this->f("sql");
> > > >              $this->argc[$name] = $this->f("argc");
> > > >           }
> > > >           $this->proc_name = $name;
> > > >           return true;
> > > >        }
> > > >        return false;
> > > >     }
> > > >
> > > >     function execproc($argv="") {
> > > >        $this->finalQuery = $this->sql[$this->proc_name];
> > > >        if (is_array($argv)) {
> > > >           reset($argv);
> > > >           $c = count($argv);
> > > >           for ($i=0 ; $i<$c ; $i++) {
> > > >              $value = $argv[key($argv)];
> > > >              $this->finalQuery =
> > > >ereg_replace("{".strtoupper(key($argv))."}", $value, $this->finalQuery);
> > > >              next($argv);
> > > >           }
> > > >        }
> > > >        $qry = $this->finalQuery;
> > > >        if (( count($argv) >= $this->argc[$this->proc_name] ) ||
> > > >($this->argc[$this->proc_name] == 0) ) {
> > > >           return $this->query($qry);
> > > >        } else {
> > > >           return false;
> > > >        }
> > > >     }
> > > >
> > > >==================================================
> > > >Let's say you have an SQL query that searches 400,000 records for
> > "Madonna"
> > > >and "DVD" ... the data is normalized across a half-dozen tables, and the
> > > >query uses JOIN and every MySQL trick I know to speed things up.  I'm also
> > > >going to want to search (elsewhere) for "CD", and "Collector", and
> > > >"VHS".  I used to debug the query in DVDs, then cut-and-paste it into the
> > > >CD script, change the variables, and debug it all over again ... ditto for
> > > >Collector, VHS, and so on.
> > > >
> > > >Or, in the CD PHP code, you can do the following:
> > > >           $word = "Madonna"; $fmt = "CD";
> > > >           $query = $db->proc("get_2_specials");
> > > >           $argv = array(FORMAT=>"$fmt",TYPE=>"$word");
> > > >           $db->execproc($argv);
> > > >
> > > >Or, in the DVD "department", the following:
> > > >           $word = "Madonna"; $fmt = "DVD";
> > > >           $query = $db->proc("get_2_specials");
> > > >           $argv = array(FORMAT=>"$fmt",TYPE=>"$word");
> > > >           $db->execproc($argv);
> > > >
> > > >For clarity, I've deleted a dozen other members of the array which get
> > > >passed to the class function ... but I'm sure you get the idea.  The
> > > >"finalQuery" variable, by the way, is *very* useful for debugging!
> > > >
> > > >==================================================
> > > >In practice ...
> > > >
> > > >1. I write the query and test it using hard values and "explain" in
> > > >PhpMyAdmin ...
> > > >
> > > >2. when the tables are optimized and the query is working the way I
> > want, I
> > > >copy the query into my PHP script and substitute variables for the hard
> > > >values ...
> > > >
> > > >3. when that's working the way I want, I re-write the query substituting
> > > >placeholders for the variables and store that in the sys_procedures table
> > > >...
> > > >
> > > >4. finally, I substitute the 3 lines (or so) of PHP code for the query
> > > >itself in my script, and I'm done.
> > > >
> > > >The tables are now optimized for the query, and the debugged query is
> > > >available to all other scripts (I can cut-and-paste just the 3 lines of
> > > >code) ... and I may get out of here on time tonight!
> > > >
> > > >==================================================
> > > >
> > > >Please let me know if I've left anything out ... and give a shout if I can
> > > >help ...
> > > >
> > > >Bob.
> > >
> > > _______________________________________________
> > > Phplib-users mailing list
> > > Php...@li...
> > > https://lists.sourceforge.net/lists/listinfo/phplib-users
> >
> >
> >_______________________________________________
> >Phplib-users mailing list
> >Php...@li...
> >https://lists.sourceforge.net/lists/listinfo/phplib-users
>
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] New to PHP and PHPLIB

[Tarique S. <ta...@sa...>]

On Fri, 9 Nov 2001, Thomas Widlar wrote:

> I am not at all new to programming, but I am just
> starting with PHP and web programming beyond simple
> HTML. 

Welcome!
 
> 2. I have obtained the Zend-IDE
> 'ZendIDEClient-TestDrive-1.1.0-Windows'. The Zend website 
> says the ZendIDE is only for Win2000. I saw somewhere that 
> the Zend-IDE is written in Java, which probably means it 
> was developed from NetBeans, which does run in WinME.
> So, will the Zend-IDE work on my WinME PHPTriad setup?

Forget ZendIDEClient! I never got it to work ...

if you are using windows use PHPed, yes I know the
later versions are commercial but older versions are still available and
perfectly usable, you can also try PHPedit

With PHPed thoug you would like to upgarde the debugger to a later
version.

Cheers

Tarique 

-- 
==========================================================
PHP Applications for E-Biz : http://www.sanisoft.com

The Ultimate Ghazal Lexicon: http://www.aaina-e-ghazal.com
==========================================================

[Phplib-users] New to PHP and PHPLIB

[Thomas W. <tw...@cr...>]

I have just joined the list. I like the quality of
the few messages I've seen.

I am not at all new to programming, but I am just
starting with PHP and web programming beyond simple
HTML. 

I want to set up a website using PHP, PHPLIB and MySQL.
I am going to develop the application on my own WinME
system before moving to an ISP with Unix, Apache, and PHP.

I have installed PHPTriad, which consists of Apache, PHP,
and MySQL. This sets up a 'localhost' server with the
home directory in C:\apache\htdocs.

1. I have extracted 'phplib-7.2d.tar/gz' into
c:\apache\php\phplib-7.2d. Right?

2. I have obtained the Zend-IDE
'ZendIDEClient-TestDrive-1.1.0-Windows'. The Zend website 
says the ZendIDE is only for Win2000. I saw somewhere that 
the Zend-IDE is written in Java, which probably means it 
was developed from NetBeans, which does run in WinME.
So, will the Zend-IDE work on my WinME PHPTriad setup?

3. There seems to be no way to contact Zend to ask 
questions. My questions to the two Zenders whose names
I got from the phplib mail archives have gone on answered. 
Is this list or somewhere else the place to get answers?

I like the practical nature of this list.

Thank you.

Tom Widlar.

Re: [Phplib-users] user-behavior tracking

[kalle \(Camelot\) <ka...@ca...>]

> The site grew fast, and now there are enough users to make a user profile.
For this I need an application to track the user behavior during his visit.
I mean, the most visited entry page, the percent of hit-and-run visits, the
most used entryway and exitway, etc, etc, etc.
>
> I think that the Apache logs are far not enough, but a system like phpLib
should be ok (with its ability to track individual requests for pages).
>
> Does anyone know such an application ? I started working for this program,
but maybe there's already one made.
search for phpOpenTracker
should have it all....

[Phplib-users] user-behavior tracking

[Pisica V. <pis...@al...>]

Hello,

I have a website ( http://www.alabala.ro ) , with the session management based entirely on PhpLib.

The site grew fast, and now there are enough users to make a user profile. For this I need an application to track the user behavior during his visit. I mean, the most visited entry page, the percent of hit-and-run visits, the most used entryway and exitway, etc, etc, etc.

I think that the Apache logs are far not enough, but a system like phpLib should be ok (with its ability to track individual requests for pages).

Does anyone know such an application ? I started working for this program, but maybe there's already one made.


Best regards,

Ciprian








________________________________________________________________________
Singurul serviciu 100% confidential din Romania : http://mail.alabala.ro

Re: [Phplib-users] RE: sys_procedures

[Bob B. <bo...@iN...>]

Philip --

Yes, an include file could contain the SQL, but I think that managing this 
storage scheme would soon become counter-productive ... keeping track of 
which file contains which procedure, then committing the extra clock cycles 
to open and parse every needed text file (vs the clock cycles for MySQL to 
do the same thing) ... but yes, this would work ...

I'm not very knowledgeable when it comes to the other DBs supported by PHP 
and phpLib, but I'm sure that a similar - or even cross-DB - version could 
be written.  But I think that, if anything, an example class extension in 
local.inc may be preferable to adding everything to one DB class ... two 
advantages:

1. if a user understands the sys_procedures concepts, they'll be used, and 
if not, they'll be ignored.  To me this is better than more posts that "... 
the distribution is broken because I can't get it to work" ...

2. users with the ability to apply the concepts to other DB packages will 
be able to do so - if we commit the code to mysql.inc then others are left out.

Just my 2 cents worth ... but I'm glad this methodology seems to be useful 
to a few others.

This methodology is indeed probably a direct descendent of functions built 
into other databases ... I haven't credited Cheng-Wei Cheng enough in these 
posts.  He worked for us about 2 years ago, making major contributions to 
what is still the biggest site we've done.  He built the framework for much 
of the database schema, and in fact wrote the original version of our DB 
class functions which handle the procedures.  And his Computer Sciences 
degree probably laid the foundation for this ...

Bob.

At 12:08 AM 11/9/2001 -0800, you wrote:
>This is pretty cool.  It looks similar to real stored procedures ala PL/SQL in
>Oracle, except that the procedures are pure SQL queries and they are not 
>executed
>directly in the database (you have to query to get the query into your PHP
>script, and then send it back to the database for it to get executed).  It 
>also
>reminds me of the Perl DBI or any other db interface that makes use of "bind
>variables."
>
>I guess you could also store the queries in an include file right?  But some
>people prefer to have stuff in the database.  I agree that this might be a 
>useful
>addition to the db class, especially for MySQL users.
>
>Philip
>
>
>Bob Bowker wrote:
>
> > Brian --
> >
> > Nope, no reason at all ... except that the two-step seemed a bit more
> > logical at the time - my only defence is, "that's the way my mind works"
> > ...!  It also makes subsequent use of the procedure in the same script easy
> > - the procedure is already loaded and the class' variables are already
> > initialized.  Something to think about if you call the procedure within a
> > loop ...
> >
> > Adding this to phpLib might be possible, but as you say, it's not yer
> > Daddy's Chevrolet, and there are already enough complaints that "... the
> > distribution is busted cause I can't make it work".  Adding a couple of
> > vars and 2 functions to your DB class is easy, and upgrades to phpLib are
> > simpler to install ...
> >
> > Maybe an "Example_SysProcedures_DB extends DB_Poe" in the local.inc as
> > distributed would do the trick, but ...
> >
> > My version of this code is available for anyone to fix up, improve, or
> > include in phpLib ... just give me a shout if you make it better so I can
> > benefit, too!
> >
> > Bob.
> >
> > At 01:25 PM 11/8/2001 -0600, you wrote:
> > >Very nice.. not to complicate things, but is there any reason why you
> > >couldn't/wouldn't combine proc and execproc? Something like this:
> > >
> > >$parameters[FORMAT] = "CD";
> > >$parameters[TRACK]  = "Smells Like Teen Spirit";
> > >$parameters[ARTIST] = "Nirvana";
> > >
> > >$db->execproc ( "get_2_specials", $parameters );
> > >
> > >Regardless, I think this is a VERY powerful concept. Anybody else up for
> > >adding it to PHPLib officially? Granted, it's a little high(er)-level, but
> > >it wouldn't affect the class in the slightest for those that didn't choose
> > >to use it.
> > >
> > >BPopp
> > >
> > >
> > >-----Original Message-----
> > >From: Bob Bowker [mailto:bo...@iN...]
> > >Sent: Thursday, November 08, 2001 12:02 PM
> > >To: Php...@li...
> > >Cc: jwi...@ma...; bp...@ct...;
> > >Kar...@co...
> > >Subject: sys_procedures
> > >
> > >
> > >Hi --
> > >
> > >OK, here goes ...
> > >
> > >==================================================
> > >"sys_procedures" is a table which contains the actual SQL queries ...
> > >
> > >CREATE TABLE sys_procedures (
> > >    id int(11) NOT NULL auto_increment,
> > >    name varchar(20) NOT NULL default '',
> > >    description varchar(40) default NULL,
> > >    sql text,
> > >    dt_create datetime NOT NULL default '0000-00-00 00:00:00',
> > >    dt_modify timestamp(14) NOT NULL,
> > >    argc int(2) unsigned NOT NULL default '0',
> > >    PRIMARY KEY  (id),
> > >    KEY name (name,dt_create,dt_modify)
> > >) TYPE=MyISAM;
> > >
> > >==================================================
> > >Within your DB class, add the following:
> > >
> > >    /* Store procedure enhancement: configurable*/
> > >    var $procedure_table = "sys_procedures";
> > >    var $proc_name;
> > >    var $sql = array();
> > >    var $argc;
> > >    var $finalQuery;
> > >
> > >     function proc($name) {
> > >        if ( !is_array($this->sql) ) {
> > >           $this->sql[$name] = "";
> > >           $this->argc[$name] = 0;
> > >        }
> > >        if ( strlen($name) > 0) {
> > >           ##This should be the only line of embedded Sql in the 
> application
> > >           $qry = "SELECT sql, argc FROM ".$this->procedure_table." WHERE
> > >name = '".$name."' ";
> > >           if (strlen($this->sql[$name]) == 0  && $this->query($qry)){
> > >              $this->next_record();
> > >              $this->sql[$name] = $this->f("sql");
> > >              $this->argc[$name] = $this->f("argc");
> > >           }
> > >           $this->proc_name = $name;
> > >           return true;
> > >        }
> > >        return false;
> > >     }
> > >
> > >     function execproc($argv="") {
> > >        $this->finalQuery = $this->sql[$this->proc_name];
> > >        if (is_array($argv)) {
> > >           reset($argv);
> > >           $c = count($argv);
> > >           for ($i=0 ; $i<$c ; $i++) {
> > >              $value = $argv[key($argv)];
> > >              $this->finalQuery =
> > >ereg_replace("{".strtoupper(key($argv))."}", $value, $this->finalQuery);
> > >              next($argv);
> > >           }
> > >        }
> > >        $qry = $this->finalQuery;
> > >        if (( count($argv) >= $this->argc[$this->proc_name] ) ||
> > >($this->argc[$this->proc_name] == 0) ) {
> > >           return $this->query($qry);
> > >        } else {
> > >           return false;
> > >        }
> > >     }
> > >
> > >==================================================
> > >Let's say you have an SQL query that searches 400,000 records for 
> "Madonna"
> > >and "DVD" ... the data is normalized across a half-dozen tables, and the
> > >query uses JOIN and every MySQL trick I know to speed things up.  I'm also
> > >going to want to search (elsewhere) for "CD", and "Collector", and
> > >"VHS".  I used to debug the query in DVDs, then cut-and-paste it into the
> > >CD script, change the variables, and debug it all over again ... ditto for
> > >Collector, VHS, and so on.
> > >
> > >Or, in the CD PHP code, you can do the following:
> > >           $word = "Madonna"; $fmt = "CD";
> > >           $query = $db->proc("get_2_specials");
> > >           $argv = array(FORMAT=>"$fmt",TYPE=>"$word");
> > >           $db->execproc($argv);
> > >
> > >Or, in the DVD "department", the following:
> > >           $word = "Madonna"; $fmt = "DVD";
> > >           $query = $db->proc("get_2_specials");
> > >           $argv = array(FORMAT=>"$fmt",TYPE=>"$word");
> > >           $db->execproc($argv);
> > >
> > >For clarity, I've deleted a dozen other members of the array which get
> > >passed to the class function ... but I'm sure you get the idea.  The
> > >"finalQuery" variable, by the way, is *very* useful for debugging!
> > >
> > >==================================================
> > >In practice ...
> > >
> > >1. I write the query and test it using hard values and "explain" in
> > >PhpMyAdmin ...
> > >
> > >2. when the tables are optimized and the query is working the way I 
> want, I
> > >copy the query into my PHP script and substitute variables for the hard
> > >values ...
> > >
> > >3. when that's working the way I want, I re-write the query substituting
> > >placeholders for the variables and store that in the sys_procedures table
> > >...
> > >
> > >4. finally, I substitute the 3 lines (or so) of PHP code for the query
> > >itself in my script, and I'm done.
> > >
> > >The tables are now optimized for the query, and the debugged query is
> > >available to all other scripts (I can cut-and-paste just the 3 lines of
> > >code) ... and I may get out of here on time tonight!
> > >
> > >==================================================
> > >
> > >Please let me know if I've left anything out ... and give a shout if I can
> > >help ...
> > >
> > >Bob.
> >
> > _______________________________________________
> > Phplib-users mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>
>_______________________________________________
>Phplib-users mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] Is there somewhere a archive of this mailing list?

[Donncha O C. <don...@tr...>]

I sent him the mails..

Donncha.


Sascha Ragtschaa wrote:
> 
> Cause I need all mailings from yesterday...
> 
> Thanks!
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] RE: sys_procedures

[Philip S. <ph...@st...>]

This is pretty cool.  It looks similar to real stored procedures ala PL/SQL in
Oracle, except that the procedures are pure SQL queries and they are not executed
directly in the database (you have to query to get the query into your PHP
script, and then send it back to the database for it to get executed).  It also
reminds me of the Perl DBI or any other db interface that makes use of "bind
variables."

I guess you could also store the queries in an include file right?  But some
people prefer to have stuff in the database.  I agree that this might be a useful
addition to the db class, especially for MySQL users.

Philip


Bob Bowker wrote:

> Brian --
>
> Nope, no reason at all ... except that the two-step seemed a bit more
> logical at the time - my only defence is, "that's the way my mind works"
> ...!  It also makes subsequent use of the procedure in the same script easy
> - the procedure is already loaded and the class' variables are already
> initialized.  Something to think about if you call the procedure within a
> loop ...
>
> Adding this to phpLib might be possible, but as you say, it's not yer
> Daddy's Chevrolet, and there are already enough complaints that "... the
> distribution is busted cause I can't make it work".  Adding a couple of
> vars and 2 functions to your DB class is easy, and upgrades to phpLib are
> simpler to install ...
>
> Maybe an "Example_SysProcedures_DB extends DB_Poe" in the local.inc as
> distributed would do the trick, but ...
>
> My version of this code is available for anyone to fix up, improve, or
> include in phpLib ... just give me a shout if you make it better so I can
> benefit, too!
>
> Bob.
>
> At 01:25 PM 11/8/2001 -0600, you wrote:
> >Very nice.. not to complicate things, but is there any reason why you
> >couldn't/wouldn't combine proc and execproc? Something like this:
> >
> >$parameters[FORMAT] = "CD";
> >$parameters[TRACK]  = "Smells Like Teen Spirit";
> >$parameters[ARTIST] = "Nirvana";
> >
> >$db->execproc ( "get_2_specials", $parameters );
> >
> >Regardless, I think this is a VERY powerful concept. Anybody else up for
> >adding it to PHPLib officially? Granted, it's a little high(er)-level, but
> >it wouldn't affect the class in the slightest for those that didn't choose
> >to use it.
> >
> >BPopp
> >
> >
> >-----Original Message-----
> >From: Bob Bowker [mailto:bo...@iN...]
> >Sent: Thursday, November 08, 2001 12:02 PM
> >To: Php...@li...
> >Cc: jwi...@ma...; bp...@ct...;
> >Kar...@co...
> >Subject: sys_procedures
> >
> >
> >Hi --
> >
> >OK, here goes ...
> >
> >==================================================
> >"sys_procedures" is a table which contains the actual SQL queries ...
> >
> >CREATE TABLE sys_procedures (
> >    id int(11) NOT NULL auto_increment,
> >    name varchar(20) NOT NULL default '',
> >    description varchar(40) default NULL,
> >    sql text,
> >    dt_create datetime NOT NULL default '0000-00-00 00:00:00',
> >    dt_modify timestamp(14) NOT NULL,
> >    argc int(2) unsigned NOT NULL default '0',
> >    PRIMARY KEY  (id),
> >    KEY name (name,dt_create,dt_modify)
> >) TYPE=MyISAM;
> >
> >==================================================
> >Within your DB class, add the following:
> >
> >    /* Store procedure enhancement: configurable*/
> >    var $procedure_table = "sys_procedures";
> >    var $proc_name;
> >    var $sql = array();
> >    var $argc;
> >    var $finalQuery;
> >
> >     function proc($name) {
> >        if ( !is_array($this->sql) ) {
> >           $this->sql[$name] = "";
> >           $this->argc[$name] = 0;
> >        }
> >        if ( strlen($name) > 0) {
> >           ##This should be the only line of embedded Sql in the application
> >           $qry = "SELECT sql, argc FROM ".$this->procedure_table." WHERE
> >name = '".$name."' ";
> >           if (strlen($this->sql[$name]) == 0  && $this->query($qry)){
> >              $this->next_record();
> >              $this->sql[$name] = $this->f("sql");
> >              $this->argc[$name] = $this->f("argc");
> >           }
> >           $this->proc_name = $name;
> >           return true;
> >        }
> >        return false;
> >     }
> >
> >     function execproc($argv="") {
> >        $this->finalQuery = $this->sql[$this->proc_name];
> >        if (is_array($argv)) {
> >           reset($argv);
> >           $c = count($argv);
> >           for ($i=0 ; $i<$c ; $i++) {
> >              $value = $argv[key($argv)];
> >              $this->finalQuery =
> >ereg_replace("{".strtoupper(key($argv))."}", $value, $this->finalQuery);
> >              next($argv);
> >           }
> >        }
> >        $qry = $this->finalQuery;
> >        if (( count($argv) >= $this->argc[$this->proc_name] ) ||
> >($this->argc[$this->proc_name] == 0) ) {
> >           return $this->query($qry);
> >        } else {
> >           return false;
> >        }
> >     }
> >
> >==================================================
> >Let's say you have an SQL query that searches 400,000 records for "Madonna"
> >and "DVD" ... the data is normalized across a half-dozen tables, and the
> >query uses JOIN and every MySQL trick I know to speed things up.  I'm also
> >going to want to search (elsewhere) for "CD", and "Collector", and
> >"VHS".  I used to debug the query in DVDs, then cut-and-paste it into the
> >CD script, change the variables, and debug it all over again ... ditto for
> >Collector, VHS, and so on.
> >
> >Or, in the CD PHP code, you can do the following:
> >           $word = "Madonna"; $fmt = "CD";
> >           $query = $db->proc("get_2_specials");
> >           $argv = array(FORMAT=>"$fmt",TYPE=>"$word");
> >           $db->execproc($argv);
> >
> >Or, in the DVD "department", the following:
> >           $word = "Madonna"; $fmt = "DVD";
> >           $query = $db->proc("get_2_specials");
> >           $argv = array(FORMAT=>"$fmt",TYPE=>"$word");
> >           $db->execproc($argv);
> >
> >For clarity, I've deleted a dozen other members of the array which get
> >passed to the class function ... but I'm sure you get the idea.  The
> >"finalQuery" variable, by the way, is *very* useful for debugging!
> >
> >==================================================
> >In practice ...
> >
> >1. I write the query and test it using hard values and "explain" in
> >PhpMyAdmin ...
> >
> >2. when the tables are optimized and the query is working the way I want, I
> >copy the query into my PHP script and substitute variables for the hard
> >values ...
> >
> >3. when that's working the way I want, I re-write the query substituting
> >placeholders for the variables and store that in the sys_procedures table
> >...
> >
> >4. finally, I substitute the 3 lines (or so) of PHP code for the query
> >itself in my script, and I'm done.
> >
> >The tables are now optimized for the query, and the debugged query is
> >available to all other scripts (I can cut-and-paste just the 3 lines of
> >code) ... and I may get out of here on time tonight!
> >
> >==================================================
> >
> >Please let me know if I've left anything out ... and give a shout if I can
> >help ...
> >
> >Bob.
>
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] OT: Database Design Help

[Philip S. <ph...@st...>]

I agree that having all those columns in one table would get messy and wouldn't be a
great idea in terms of database design.  On the other hand, with the attributes
table each attribute value would have to be of the same data type.  In most
situations this would not be an issue but it's worth taking note of.  I'd be
interested to see how amazon.com handles this sort of stuff (or any other big
e-commerce site for that matter), but I don't think we'll come across this info
anytime soon.

Philip


Jesse Swensen wrote:

> Yes, this is a dilemma.  I am sure there are lots of ways to solve this
> problem and a lot depends on the way the data is being used.  The way you
> suggest is probably the best for speed.  But, I can make a mess of a table
> by having lots of extra columns.
>
> Another way would be to create a table of attributes.  The columns would be
> something like
>
> Product_attributes
>     product_id
>     attr_type
>     attr_value
>
> It makes queries a little harder because you have to join in this table and
> you may want to add other columns to better describe the attribute.  But
> this is how I would do it.
> --
> Jesse
>
> > From: Philip Strnad <ph...@st...>
> > Date: Wed, 07 Nov 2001 22:28:54 -0800
> > To: Jesse Swensen <ph...@sw...>
> > Cc: Bob Bowker <bo...@iN...>, "php...@li..."
> > <Php...@li...>
> > Subject: Re: [Phplib-users] OT: Database Design Help
> >
> > How would you go about storing attributes for the products?  Let's say you
> > have
> > three product types:
> >
> > - books
> > - CDs
> > - electronics
> >
> > Each of these categories could have many attributes, and to make matters
> > worse,
> > each one can have different attributes.  For example, a book would have an
> > ISBN
> > number, which a CD wouldn't have.  The electronics might have a color
> > attribute,
> > which CDs and books wouldn't have (at least there would be no point in storing
> > this attribute).
> >
> > I've run into this situation a few times and have never found an ideal
> > solution.  The only solution I see is to have lots of attribute columns in the
> > products table and for every product a bunch of these would have null values
> > since certain attributes wouldn't be applicable.

[Fwd: Re: [Phplib-users] preauth using cidr]

[Paul W. <pa...@zz...>]

I spoke too soon. I still cannot get a function that checks if an ip is
within a network block to work. I have done some more research and found
a description on how to solve this problem by Kristian Koehntopp.
Somehow I've botched this as well. It would be great to hear from
someone that has pulled this off.

Input:
remote_ip = 192.75.242.88
cidr = 192.75.242.0/24 

Output:
ip = -1068764584 
start = -1068764672 
mask = -16777216 


function within ($remote_ip, $cidr) {
        ## within function checks whether an ip is within a network
block
        ## example with("192.75.242.157", "192.75.242.0/24") 
        ## returns true if ip is within range
                
        $ip=ip2long($remote_ip); 
        list ($quad, $nbits) = split ("/", $cidr, 2);
        $shift_mask = (integer) $nbits;         
        $start=ip2long($quad);
                
        $mask = -1<<$shift_mask;

        return $ip & $start == $mask;
}



-------- Original Message --------
Subject: Re: [Phplib-users] preauth using cidr
Date: Thu, 08 Nov 2001 12:27:04 -0800
From: Paul Wolstenholme <pa...@zz...>
Organization: SMA WebWare
To: Php...@li...
References: <3BE...@zz...>

I fixed my own problem. I forgot to convert the remote host ip. This
code appears to work for anyone interested:


$cidr = $valid_client; /* db value 192.55.192.0/24 */
list ($quad, $nbits) = split ("/", $cidr, 2);
$byte = explode (".", $quad);
$address_required = ($byte[0] << 24) | ($byte[1] << 16) | ($byte[2] <<
8) | $byte[3];
				
/* remote host info */
$byte = explode(".", $ip); /* ip from $HTTP_SERVER_VARS['REMOTE_ADDR']
*/
$address_client = ($byte[0] << 24) | ($byte[1] << 16) | ($byte[2] << 8)
| $byte[3];
				
$bitmask = 0xffffffff << (32 - $nbits);			
if (($address_client & $bitmask) == ($address_required & $bitmask)) {
	$this->auth['uname'] = $this->dbAuth->f('ID');
	$this->auth['perm'][$this->dbAuth->f('Service')] = 1;
	$success = 1;
}

Paul Wolstenholme wrote:
> 
> Hi,
> 
> I am trying to do a preauth using cidr to allow some institutional
> subscribers to access info that is normally password protected. I found
> some Perl code that does this but it does not work in php. Does anyone
> know how one could accomplish this?
> 
> $cidr = $valid_client; /* eg 192.55.192.0/24 */
> list ($quad, $nbits) = split ("/", $cidr, 2);
> $byte = explode (".", $quad);
> 
> $address = ($byte[0] << 24) | ($byte[1] << 16) | ($byte[2] << 8) |
> $byte[3];
> $bitmask = 0xffffffff << (32 - $nbits);
> 
> if ($ip & $bitmask == $address & $bitmask) {
>         $this->auth['uname'] = $this->dbAuth->f('ID');
>         $this->auth['perm'][$this->dbAuth->f('Service')] = 1;
> }
> 
> --
> ________________________________________________________________
> Paul Wolstenholme
> SMA Webware
> http://www.zzube.com/
> What do you know?
> http://make.zzube.com/
> Vancouver, BC Canada

-- 
________________________________________________________________
Paul Wolstenholme
SMA Webware
http://www.zzube.com/
What do you know?
http://make.zzube.com/
Vancouver, BC Canada

Re: [Phplib-users] preauth using cidr

[Paul W. <pa...@zz...>]

I fixed my own problem. I forgot to convert the remote host ip. This
code appears to work for anyone interested:


$cidr = $valid_client; /* db value 192.55.192.0/24 */
list ($quad, $nbits) = split ("/", $cidr, 2);
$byte = explode (".", $quad);
$address_required = ($byte[0] << 24) | ($byte[1] << 16) | ($byte[2] <<
8) | $byte[3];
				
/* remote host info */
$byte = explode(".", $ip); /* ip from $HTTP_SERVER_VARS['REMOTE_ADDR']
*/
$address_client = ($byte[0] << 24) | ($byte[1] << 16) | ($byte[2] << 8)
| $byte[3];
				
$bitmask = 0xffffffff << (32 - $nbits);			
if (($address_client & $bitmask) == ($address_required & $bitmask)) {
	$this->auth['uname'] = $this->dbAuth->f('ID');
	$this->auth['perm'][$this->dbAuth->f('Service')] = 1;
	$success = 1;
}

Paul Wolstenholme wrote:
> 
> Hi,
> 
> I am trying to do a preauth using cidr to allow some institutional
> subscribers to access info that is normally password protected. I found
> some Perl code that does this but it does not work in php. Does anyone
> know how one could accomplish this?
> 
> $cidr = $valid_client; /* eg 192.55.192.0/24 */
> list ($quad, $nbits) = split ("/", $cidr, 2);
> $byte = explode (".", $quad);
> 
> $address = ($byte[0] << 24) | ($byte[1] << 16) | ($byte[2] << 8) |
> $byte[3];
> $bitmask = 0xffffffff << (32 - $nbits);
> 
> if ($ip & $bitmask == $address & $bitmask) {
>         $this->auth['uname'] = $this->dbAuth->f('ID');
>         $this->auth['perm'][$this->dbAuth->f('Service')] = 1;
> }
> 
> --
> ________________________________________________________________
> Paul Wolstenholme
> SMA Webware
> http://www.zzube.com/
> What do you know?
> http://make.zzube.com/
> Vancouver, BC Canada

-- 
________________________________________________________________
Paul Wolstenholme
SMA Webware
http://www.zzube.com/
What do you know?
http://make.zzube.com/
Vancouver, BC Canada

[Phplib-users] RE: sys_procedures

[Bob B. <bo...@iN...>]

Brian --

Nope, no reason at all ... except that the two-step seemed a bit more 
logical at the time - my only defence is, "that's the way my mind works" 
...!  It also makes subsequent use of the procedure in the same script easy 
- the procedure is already loaded and the class' variables are already 
initialized.  Something to think about if you call the procedure within a 
loop ...

Adding this to phpLib might be possible, but as you say, it's not yer 
Daddy's Chevrolet, and there are already enough complaints that "... the 
distribution is busted cause I can't make it work".  Adding a couple of 
vars and 2 functions to your DB class is easy, and upgrades to phpLib are 
simpler to install ...

Maybe an "Example_SysProcedures_DB extends DB_Poe" in the local.inc as 
distributed would do the trick, but ...

My version of this code is available for anyone to fix up, improve, or 
include in phpLib ... just give me a shout if you make it better so I can 
benefit, too!

Bob.

At 01:25 PM 11/8/2001 -0600, you wrote:
>Very nice.. not to complicate things, but is there any reason why you
>couldn't/wouldn't combine proc and execproc? Something like this:
>
>$parameters[FORMAT] = "CD";
>$parameters[TRACK]  = "Smells Like Teen Spirit";
>$parameters[ARTIST] = "Nirvana";
>
>$db->execproc ( "get_2_specials", $parameters );
>
>Regardless, I think this is a VERY powerful concept. Anybody else up for
>adding it to PHPLib officially? Granted, it's a little high(er)-level, but
>it wouldn't affect the class in the slightest for those that didn't choose
>to use it.
>
>BPopp
>
>
>-----Original Message-----
>From: Bob Bowker [mailto:bo...@iN...]
>Sent: Thursday, November 08, 2001 12:02 PM
>To: Php...@li...
>Cc: jwi...@ma...; bp...@ct...;
>Kar...@co...
>Subject: sys_procedures
>
>
>Hi --
>
>OK, here goes ...
>
>==================================================
>"sys_procedures" is a table which contains the actual SQL queries ...
>
>CREATE TABLE sys_procedures (
>    id int(11) NOT NULL auto_increment,
>    name varchar(20) NOT NULL default '',
>    description varchar(40) default NULL,
>    sql text,
>    dt_create datetime NOT NULL default '0000-00-00 00:00:00',
>    dt_modify timestamp(14) NOT NULL,
>    argc int(2) unsigned NOT NULL default '0',
>    PRIMARY KEY  (id),
>    KEY name (name,dt_create,dt_modify)
>) TYPE=MyISAM;
>
>==================================================
>Within your DB class, add the following:
>
>    /* Store procedure enhancement: configurable*/
>    var $procedure_table = "sys_procedures";
>    var $proc_name;
>    var $sql = array();
>    var $argc;
>    var $finalQuery;
>
>     function proc($name) {
>        if ( !is_array($this->sql) ) {
>           $this->sql[$name] = "";
>           $this->argc[$name] = 0;
>        }
>        if ( strlen($name) > 0) {
>           ##This should be the only line of embedded Sql in the application
>           $qry = "SELECT sql, argc FROM ".$this->procedure_table." WHERE
>name = '".$name."' ";
>           if (strlen($this->sql[$name]) == 0  && $this->query($qry)){
>              $this->next_record();
>              $this->sql[$name] = $this->f("sql");
>              $this->argc[$name] = $this->f("argc");
>           }
>           $this->proc_name = $name;
>           return true;
>        }
>        return false;
>     }
>
>     function execproc($argv="") {
>        $this->finalQuery = $this->sql[$this->proc_name];
>        if (is_array($argv)) {
>           reset($argv);
>           $c = count($argv);
>           for ($i=0 ; $i<$c ; $i++) {
>              $value = $argv[key($argv)];
>              $this->finalQuery =
>ereg_replace("{".strtoupper(key($argv))."}", $value, $this->finalQuery);
>              next($argv);
>           }
>        }
>        $qry = $this->finalQuery;
>        if (( count($argv) >= $this->argc[$this->proc_name] ) ||
>($this->argc[$this->proc_name] == 0) ) {
>           return $this->query($qry);
>        } else {
>           return false;
>        }
>     }
>
>==================================================
>Let's say you have an SQL query that searches 400,000 records for "Madonna"
>and "DVD" ... the data is normalized across a half-dozen tables, and the
>query uses JOIN and every MySQL trick I know to speed things up.  I'm also
>going to want to search (elsewhere) for "CD", and "Collector", and
>"VHS".  I used to debug the query in DVDs, then cut-and-paste it into the
>CD script, change the variables, and debug it all over again ... ditto for
>Collector, VHS, and so on.
>
>Or, in the CD PHP code, you can do the following:
>           $word = "Madonna"; $fmt = "CD";
>           $query = $db->proc("get_2_specials");
>           $argv = array(FORMAT=>"$fmt",TYPE=>"$word");
>           $db->execproc($argv);
>
>Or, in the DVD "department", the following:
>           $word = "Madonna"; $fmt = "DVD";
>           $query = $db->proc("get_2_specials");
>           $argv = array(FORMAT=>"$fmt",TYPE=>"$word");
>           $db->execproc($argv);
>
>For clarity, I've deleted a dozen other members of the array which get
>passed to the class function ... but I'm sure you get the idea.  The
>"finalQuery" variable, by the way, is *very* useful for debugging!
>
>==================================================
>In practice ...
>
>1. I write the query and test it using hard values and "explain" in
>PhpMyAdmin ...
>
>2. when the tables are optimized and the query is working the way I want, I
>copy the query into my PHP script and substitute variables for the hard
>values ...
>
>3. when that's working the way I want, I re-write the query substituting
>placeholders for the variables and store that in the sys_procedures table
>...
>
>4. finally, I substitute the 3 lines (or so) of PHP code for the query
>itself in my script, and I'm done.
>
>The tables are now optimized for the query, and the debugged query is
>available to all other scripts (I can cut-and-paste just the 3 lines of
>code) ... and I may get out of here on time tonight!
>
>==================================================
>
>Please let me know if I've left anything out ... and give a shout if I can
>help ...
>
>Bob.

[Phplib-users] preauth using cidr

[Paul W. <pa...@zz...>]

Hi,

I am trying to do a preauth using cidr to allow some institutional
subscribers to access info that is normally password protected. I found
some Perl code that does this but it does not work in php. Does anyone
know how one could accomplish this?

$cidr = $valid_client; /* eg 192.55.192.0/24 */
list ($quad, $nbits) = split ("/", $cidr, 2);
$byte = explode (".", $quad);
	
$address = ($byte[0] << 24) | ($byte[1] << 16) | ($byte[2] << 8) |
$byte[3];
$bitmask = 0xffffffff << (32 - $nbits);
				
if ($ip & $bitmask == $address & $bitmask) {
	$this->auth['uname'] = $this->dbAuth->f('ID');
	$this->auth['perm'][$this->dbAuth->f('Service')] = 1;
}


-- 
________________________________________________________________
Paul Wolstenholme
SMA Webware
http://www.zzube.com/
What do you know?
http://make.zzube.com/
Vancouver, BC Canada

[Phplib-users] RE: sys_procedures

[Brian P. <bp...@ct...>]

Very nice.. not to complicate things, but is there any reason why you
couldn't/wouldn't combine proc and execproc? Something like this:

$parameters[FORMAT] = "CD";
$parameters[TRACK]  = "Smells Like Teen Spirit";
$parameters[ARTIST] = "Nirvana";

$db->execproc ( "get_2_specials", $parameters );

Regardless, I think this is a VERY powerful concept. Anybody else up for
adding it to PHPLib officially? Granted, it's a little high(er)-level, but
it wouldn't affect the class in the slightest for those that didn't choose
to use it.

BPopp 


-----Original Message-----
From: Bob Bowker [mailto:bo...@iN...]
Sent: Thursday, November 08, 2001 12:02 PM
To: Php...@li...
Cc: jwi...@ma...; bp...@ct...;
Kar...@co...
Subject: sys_procedures


Hi --

OK, here goes ...

==================================================
"sys_procedures" is a table which contains the actual SQL queries ...

CREATE TABLE sys_procedures (
   id int(11) NOT NULL auto_increment,
   name varchar(20) NOT NULL default '',
   description varchar(40) default NULL,
   sql text,
   dt_create datetime NOT NULL default '0000-00-00 00:00:00',
   dt_modify timestamp(14) NOT NULL,
   argc int(2) unsigned NOT NULL default '0',
   PRIMARY KEY  (id),
   KEY name (name,dt_create,dt_modify)
) TYPE=MyISAM;

==================================================
Within your DB class, add the following:

   /* Store procedure enhancement: configurable*/
   var $procedure_table = "sys_procedures";
   var $proc_name;
   var $sql = array();
   var $argc;
   var $finalQuery;

    function proc($name) {
       if ( !is_array($this->sql) ) {
          $this->sql[$name] = "";
          $this->argc[$name] = 0;
       }
       if ( strlen($name) > 0) {
          ##This should be the only line of embedded Sql in the application
          $qry = "SELECT sql, argc FROM ".$this->procedure_table." WHERE 
name = '".$name."' ";
          if (strlen($this->sql[$name]) == 0  && $this->query($qry)){
             $this->next_record();
             $this->sql[$name] = $this->f("sql");
             $this->argc[$name] = $this->f("argc");
          }
          $this->proc_name = $name;
          return true;
       }
       return false;
    }

    function execproc($argv="") {
       $this->finalQuery = $this->sql[$this->proc_name];
       if (is_array($argv)) {
          reset($argv);
          $c = count($argv);
          for ($i=0 ; $i<$c ; $i++) {
             $value = $argv[key($argv)];
             $this->finalQuery = 
ereg_replace("{".strtoupper(key($argv))."}", $value, $this->finalQuery);
             next($argv);
          }
       }
       $qry = $this->finalQuery;
       if (( count($argv) >= $this->argc[$this->proc_name] ) || 
($this->argc[$this->proc_name] == 0) ) {
          return $this->query($qry);
       } else {
          return false;
       }
    }

==================================================
Let's say you have an SQL query that searches 400,000 records for "Madonna" 
and "DVD" ... the data is normalized across a half-dozen tables, and the 
query uses JOIN and every MySQL trick I know to speed things up.  I'm also 
going to want to search (elsewhere) for "CD", and "Collector", and 
"VHS".  I used to debug the query in DVDs, then cut-and-paste it into the 
CD script, change the variables, and debug it all over again ... ditto for 
Collector, VHS, and so on.

Or, in the CD PHP code, you can do the following:
          $word = "Madonna"; $fmt = "CD";
          $query = $db->proc("get_2_specials");
          $argv = array(FORMAT=>"$fmt",TYPE=>"$word");
          $db->execproc($argv);

Or, in the DVD "department", the following:
          $word = "Madonna"; $fmt = "DVD";
          $query = $db->proc("get_2_specials");
          $argv = array(FORMAT=>"$fmt",TYPE=>"$word");
          $db->execproc($argv);

For clarity, I've deleted a dozen other members of the array which get 
passed to the class function ... but I'm sure you get the idea.  The 
"finalQuery" variable, by the way, is *very* useful for debugging!

==================================================
In practice ...

1. I write the query and test it using hard values and "explain" in 
PhpMyAdmin ...

2. when the tables are optimized and the query is working the way I want, I 
copy the query into my PHP script and substitute variables for the hard 
values ...

3. when that's working the way I want, I re-write the query substituting 
placeholders for the variables and store that in the sys_procedures table
...

4. finally, I substitute the 3 lines (or so) of PHP code for the query 
itself in my script, and I'm done.

The tables are now optimized for the query, and the debugged query is 
available to all other scripts (I can cut-and-paste just the 3 lines of 
code) ... and I may get out of here on time tonight!

==================================================

Please let me know if I've left anything out ... and give a shout if I can 
help ...

Bob.