phplib-users

[Phplib-users] extensions to oohforms, table

[Clark F. <cl...@th...>]

Hi Phplibbers,

Way back in 1999, Eric Ries and I made some extensions to the oohforms
component of phplib, version 6.4 to be precise. These included some
fancier validation techniques and some fancier widgets, including a few
types of database-backed widgets. I have just recently re-integrated these
changes into PHPLib version 7.4, and I was wondering if anybody would be
interested in taking a look at them. The code is definitely not at release
level, but there are some nifty features.

Anyway, if people are interested, I'll throw together a little Web page
with the files and some documentation on how to drop them in on top of
your PHPLib installation and how to use them.

I also have made some enhancements to the table class, namely, integrating
it with the DB class and providing sorting via clicking on column
header links and more formatting flexibility. Would love to share that
too.

Keep up the good work on PHPLib. I've been a loyal user for five years
now.

Clark

Re: [Phplib-users] extensions to oohforms, table

[Nathaniel P. <np...@te...>]

On 4/9/2004 3:18 PM, Clark Freifeld wrote :

>Hi Phplibbers,
>
>Way back in 1999, Eric Ries and I made some extensions to the oohforms
>component of phplib, version 6.4 to be precise. These included some
>fancier validation techniques and some fancier widgets, including a few
>types of database-backed widgets. I have just recently re-integrated these
>changes into PHPLib version 7.4, and I was wondering if anybody would be
>interested in taking a look at them. The code is definitely not at release
>level, but there are some nifty features.
>
>Anyway, if people are interested, I'll throw together a little Web page
>with the files and some documentation on how to drop them in on top of
>your PHPLib installation and how to use them.
>
>I also have made some enhancements to the table class, namely, integrating
>it with the DB class and providing sorting via clicking on column
>header links and more formatting flexibility. Would love to share that
>too.
>
>Keep up the good work on PHPLib. I've been a loyal user for five years
>now.
>  
>
I'd be very interested to see what you've come up with... I've worked on 
my own extension to oohforms that I'm using in-house for a few things, 
but it was mostly just a code cleanup with a couple of new features more 
than anything else.

I haven't mucked around with the table class very much, but the 
functionality you've described sounds like it would be a very useful 
addition.

PHPlib development seems to be pretty much stagnant as of late. I'm glad 
to see someone working on it.

This is a bit off of the topic, but one of the main reasons I like 
PHPlib is because its components work together well. However, when 
looking around at other code libraries like PEAR and ADOdb that are 
actively maintained, and seeing PHPlib mostly still using code designed 
to work with PHP3, I'm beginning to wonder if it might be worth 
migrating to get a more fully featured database abstraction layer. 
However, I wouldn't want to sacrifice the flexability that the 
auth/perm/user functionality offers. Does anyone have any thoughts as to 
what code out there to "replace" phplib? Would it be worthwhile to try 
to rewrite PHPlib to get rid of crufty code and add new features, or 
would that be duplicating efforts from other projects too much to be 
worth it?

Thanks in advance...

-- 
___________________________
Nathaniel Price
http://www.tesserportal.net
Webmaster

R: [Phplib-users] extensions to oohforms, table

[Gaetano G. <giu...@se...>]

I've been using PHPlib for a while now, mainly on a single (big) project =
at my company.
Since I had already deployed my own DB abstraction layer, based on phpDB =
code, I retro-fitted phplib to use it.
As a testament to code modularity and good design, I must say it was =
pretty painless.

Since then I tried porting the db code to ADODB.

I like this library because it is well supported (too much in fact, 1 =
release every month or so!) and widely deployed and because the API is =
quite similar to what I used before.
I do not like this library because it tends to be buggy and have =
regressions all the time, even after years of development (and every =
time I post a patch to the author we dissent on design issues ;)...

What I would like to have now is a good framework of modules that =
cooperate together, e.g.
- smarty for templating
- adodb for db access
- phplib for extending the native php session with user/auth/perm
- xmlrpc for inter-application communication (shameless self-promotion: =
I'm writing an extension to adodb to access remote databases thru =
xml-rpc using the phpxmlrpc lib...)

This would imho avoid a lot of duplication of effort and be a solid base =
for higher-level frameworks, such as CMS frameworks.

I must confess never using the 'templating' part of phplib (I was not =
into teplates at the time), so I cannot testity for Smarty against =
phplib, I just downloaded the templating engine with the biggest =
marketshare.

I also never upgraded to the latest version of phplib mostly because:
- never ever fully understood if the lib was 100% ok with =
register_globals off
- never ever fully understood if the lib was 100% fine with php4 =
sessions and which were the good files to use in that case

Cheers
Gaetano

> -----Messaggio originale-----
> Da: php...@li...
> [mailto:php...@li...]Per conto di=20
> Nathaniel
> Price
> Inviato: lunedi 12 aprile 2004 18:30
> A: php...@li...
> Oggetto: Re: [Phplib-users] extensions to oohforms, table
>=20
>=20
> On 4/9/2004 3:18 PM, Clark Freifeld wrote :
>=20
> >Hi Phplibbers,
> >
> >Way back in 1999, Eric Ries and I made some extensions to=20
> the oohforms
> >component of phplib, version 6.4 to be precise. These included some
> >fancier validation techniques and some fancier widgets,=20
> including a few
> >types of database-backed widgets. I have just recently=20
> re-integrated these
> >changes into PHPLib version 7.4, and I was wondering if=20
> anybody would be
> >interested in taking a look at them. The code is definitely=20
> not at release
> >level, but there are some nifty features.
> >
> >Anyway, if people are interested, I'll throw together a=20
> little Web page
> >with the files and some documentation on how to drop them in=20
> on top of
> >your PHPLib installation and how to use them.
> >
> >I also have made some enhancements to the table class,=20
> namely, integrating
> >it with the DB class and providing sorting via clicking on column
> >header links and more formatting flexibility. Would love to=20
> share that
> >too.
> >
> >Keep up the good work on PHPLib. I've been a loyal user for=20
> five years
> >now.
> > =20
> >
> I'd be very interested to see what you've come up with...=20
> I've worked on=20
> my own extension to oohforms that I'm using in-house for a=20
> few things,=20
> but it was mostly just a code cleanup with a couple of new=20
> features more=20
> than anything else.
>=20
> I haven't mucked around with the table class very much, but the=20
> functionality you've described sounds like it would be a very useful=20
> addition.
>=20
> PHPlib development seems to be pretty much stagnant as of=20
> late. I'm glad=20
> to see someone working on it.
>=20
> This is a bit off of the topic, but one of the main reasons I like=20
> PHPlib is because its components work together well. However, when=20
> looking around at other code libraries like PEAR and ADOdb that are=20
> actively maintained, and seeing PHPlib mostly still using=20
> code designed=20
> to work with PHP3, I'm beginning to wonder if it might be worth=20
> migrating to get a more fully featured database abstraction layer.=20
> However, I wouldn't want to sacrifice the flexability that the=20
> auth/perm/user functionality offers. Does anyone have any=20
> thoughts as to=20
> what code out there to "replace" phplib? Would it be=20
> worthwhile to try=20
> to rewrite PHPlib to get rid of crufty code and add new features, or=20
> would that be duplicating efforts from other projects too much to be=20
> worth it?
>=20
> Thanks in advance...
>=20
> --=20
> ___________________________
> Nathaniel Price
> http://www.tesserportal.net
> Webmaster
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

[Phplib-users] random logouts

[Layne W. <la...@dr...>]

The setup:
    Oracle 9i
    Apache 1.3.29
    PHP 4.3.4
    PHPLib latest CVS
        db_oci8.inc
        ct_sql.inc (with customized queries for Oracle for speed & clob
type)
        session.inc
            cookie-based, no fallback mode
        auth.inc

I have users occasionally losing their session and/or auth and getting the
login screen. From the bug reports, this happens immediately after login
about 20-30% of the time. The rest of the time it appears to be random, but
usually when clicking on a link (as opposed to submitting a form and/or
being redirected).

I was using CT_Split_Sql, but was getting occasional primary key violations=
,
so I switched to CT_Sql with modified queries (no changes to the logic) and
the primary key violations stopped, but the dropped session/auth still
continues. I'm logging both PHP warnings (level 15) and SQL errors and am
not seeing any correlations with sessions or auth - whatever is happening i=
s
not throwing a SQL error or a PHP warning or error.

Has anyone seen this kind of behaviour before?

Layne Weathers

Re: [Phplib-users] random logouts

[Nathaniel P. <np...@te...>]

On 4/13/2004 7:50 PM, Layne Weathers wrote :

>[snip]
>
>I have users occasionally losing their session and/or auth and getting the
>login screen. From the bug reports, this happens immediately after login
>about 20-30% of the time. The rest of the time it appears to be random, but
>usually when clicking on a link (as opposed to submitting a form and/or
>being redirected).
>
>[snip]
>
>Has anyone seen this kind of behaviour before?
>  
>
Although I can't be sure without more information, it sounds to me like 
it is an issue with cookies or session/auth lifetimes. If you are using 
the included Challenge-Response auth subclass for example, it has a 
default auth lifetime of only 1 minute, last time I checked.

As for the cookie end of things, make sure that the browsers are 
accepting the cookie (sniffing the HTTP headers can be useful here), and 
make sure that the cookie is being set for the same domain/hostname that 
it is originating from. If you have a situaiton where you want sessions 
to span multiple hosts/domains/subdomains, that will likely cause 
problems as well, which you'd have to work around.

Oh, and just in case... make /absolutely/ sure that each page that uses 
sessions and/or auth is closed with page_close(). The lack of this 
function call at the end of your scripts is often the cause of 
random-looking dropped sessions.

Hope this helps...

-- 
___________________________
Nathaniel Price
http://www.tesserportal.net
Webmaster

Re: [Phplib-users] random logouts

[Layne W. <la...@dr...>]

> As for the cookie end of things, make sure that the browsers are 
> accepting the cookie (sniffing the HTTP headers can be useful here), and=
=20
> make sure that the cookie is being set for the same domain/hostname that=
=20
> it is originating from. If you have a situaiton where you want sessions=
=20
> to span multiple hosts/domains/subdomains, that will likely cause=20
> problems as well, which you'd have to work around.

Many of the users were using the IP address (from when we moved servers,
before DNS switched), but all of the links and redirects are fully qualifie=
d
with the domain name.

> Oh, and just in case... make /absolutely/ sure that each page that uses=
=20
> sessions and/or auth is closed with page_close(). The lack of this=20
> function call at the end of your scripts is often the cause of=20
> random-looking dropped sessions.

It's embarrassing to see that I've overlooked that randomly throughout the
site. Thanks for the reminders.

Layne Weathers

Re: [Phplib-users] extensions to oohforms, table

[Layne W. <la...@dr...>]

Quoth Nathaniel Price:

> This is a bit off of the topic, but one of the main reasons I like=20
> PHPlib is because its components work together well. However, when=20
> looking around at other code libraries like PEAR and ADOdb that are=20
> actively maintained, and seeing PHPlib mostly still using code designed=
=20
> to work with PHP3, I'm beginning to wonder if it might be worth=20
> migrating to get a more fully featured database abstraction layer.=20
> However, I wouldn't want to sacrifice the flexability that the=20
> auth/perm/user functionality offers. Does anyone have any thoughts as to=
=20
> what code out there to "replace" phplib? Would it be worthwhile to try=20
> to rewrite PHPlib to get rid of crufty code and add new features, or=20
> would that be duplicating efforts from other projects too much to be=20
> worth it?

Nathaniel,

I don't know if re-writing PHPLib is "worthwhile" to anyone else - one of
the beauties of OSS is that everyone is allowed to define what is worthwhil=
e
for them. I have been using PHPLib for a few years now and have kept using
it precisely for the interaction of the classes.

(BTW, what is the correct capitalization - PHPLIB, PHPlib, PHPLib, etc?)

I would love to start working on a fresh release of PHPLib. It would be a
bit of an undertaking and will probably take a good while to complete, but
I'd love to get rid of the cruft.

It seems to me that some possible goals could/should be:
- define some basic coding and formatting guidelines
    (preferably, this would be set by the project admin or other designated
    decision-maker so we don't waste time arguing about it)
- completely audit/rewrite the existing code
- only commit classes that have been tested by more than one person
    (e.g., how many current users/developers have used db_msql.inc?)
- require a minimum of (at least) PHP 4.1 - heck, this is going to take a
    while, why not build on PHP 5? (semi-serious)

Anyone else willing to consider taking on the challenge?

Layne Weathers

Re: [Phplib-users] extensions to oohforms, table

[Aric C. <gre...@pe...>]

Layne Weathers wrote:

> Nathaniel,
>
>I don't know if re-writing PHPLib is "worthwhile" to anyone else - one of
>the beauties of OSS is that everyone is allowed to define what is worthwhile
>for them. I have been using PHPLib for a few years now and have kept using
>it precisely for the interaction of the classes.
>
>(BTW, what is the correct capitalization - PHPLIB, PHPlib, PHPLib, etc?)
>
>I would love to start working on a fresh release of PHPLib. It would be a
>bit of an undertaking and will probably take a good while to complete, but
>I'd love to get rid of the cruft.
>
>It seems to me that some possible goals could/should be:
>- define some basic coding and formatting guidelines
>    (preferably, this would be set by the project admin or other designated
>    decision-maker so we don't waste time arguing about it)
>- completely audit/rewrite the existing code
>- only commit classes that have been tested by more than one person
>    (e.g., how many current users/developers have used db_msql.inc?)
>- require a minimum of (at least) PHP 4.1 - heck, this is going to take a
>    while, why not build on PHP 5? (semi-serious)
>
>Anyone else willing to consider taking on the challenge?
>
>Layne Weathers
>
>  
>
I've been using PHPLib since I started with PHP some years ago.  I like 
it.  I haven't found anything else that seems to be as simple and 
lightweight yet powerfull enough to be generaly usefull.

I'd like to see PHPLib updated, in addition to what's listed above:
  * MySQLi support (this is the 'improved' mysql extension in php5.  
Anybody know how to get it to play nice with the old mysql extension on 
windows? ).
  * SQLite support
  * PHP5 only.  Yes, that's right.  Why not?  Take full advantage of 
PHP5 new object oriented features.  I'm exploring some ideas now with 
the db and template objects.
  * Permx built in.
  * Better documentation.  I remember having a tough time with phplib at 
first...

Re: [Phplib-users] extensions to oohforms, table

[Aric C. <gre...@pe...>]

Clark Freifeld wrote:

>Hi Phplibbers,
>
>Way back in 1999, Eric Ries and I made some extensions to the oohforms
>component of phplib, version 6.4 to be precise. These included some
>fancier validation techniques and some fancier widgets, including a few
>types of database-backed widgets. I have just recently re-integrated these
>changes into PHPLib version 7.4, and I was wondering if anybody would be
>interested in taking a look at them. The code is definitely not at release
>level, but there are some nifty features.
>
>Anyway, if people are interested, I'll throw together a little Web page
>with the files and some documentation on how to drop them in on top of
>your PHPLib installation and how to use them.
>
>I also have made some enhancements to the table class, namely, integrating
>it with the DB class and providing sorting via clicking on column
>header links and more formatting flexibility. Would love to share that
>too.
>  
>
I would be interested to see what you've done.

I was looking at the PEAR classes trying to decide if there's a purpose 
for PHPLib anymore.  They have HTML_QuickForm which looks like a very 
advanced version of oohforms.  Naturaly, its much bigger, and has 
probably a lot more functionality.  I'm torn between which one I want to 
use. 

PEAR also has their own DB abstractions.  From what I've read, PHPLib DB 
class is much faster and I can't really think of all that much more 
feature wise I would want.  For me, PHPLib wins here.

There are assorted types of template classes including a PHPLib one.  I 
have no desire for a template engine more complex than PHPLib's and in 
fact I'm of the mind to do things without a template engine at all.

The main thing that seems to be missing from PEAR is something 
equivalent to PHPLib's auth and perm classes. 

I dont know if its worth working on the oohforms or not.  I'm all for it 
if somebody with experience with PEAR could give some good reasons why 
the PEAR version isn't so great, and how oohforms could have certain 
advantages over it (like speed and efficiency and simplicity).

I always like to stick with what already works and improve upon it, but 
always at some point its worth moving on.  Either we can rustle up some 
interest in PHPLib improvements, or perhaps its time to port PHPLib's 
auth, perm and lean DB functionality to PEAR?

Re: [Phplib-users] extensions to oohforms, table

[Matt W. <li...@ye...>]

Quoting Aric Caley <gre...@pe...>:

> There are assorted types of template classes including a PHPLib one.  I 
> have no desire for a template engine more complex than PHPLib's and in 
> fact I'm of the mind to do things without a template engine at all.
> 
> The main thing that seems to be missing from PEAR is something 
> equivalent to PHPLib's auth and perm classes. 

There is already an auth class within PEAR.

I set up a test machine last week using PEAR::Auth, PEAR::DB, native sessions,
although I customised it to use DB storage. I'm gonna bring in PHPLib perm as I
haven't seen anything in PEAR that will do the same thing.
I'm in two minds whether to bring in PHPLib's DB extraction or not and use that
for my stuff or whether to use PEAR::DB, although there are some neat error
handlers for PEAR::DB.

Matt

Re: [Phplib-users] extensions to oohforms, table

[Aric C. <gre...@pe...>]

Matt Williams wrote:

>There is already an auth class within PEAR.
>
>I set up a test machine last week using PEAR::Auth, PEAR::DB, native sessions,
>although I customised it to use DB storage. I'm gonna bring in PHPLib perm as I
>haven't seen anything in PEAR that will do the same thing.
>I'm in two minds whether to bring in PHPLib's DB extraction or not and use that
>for my stuff or whether to use PEAR::DB, although there are some neat error
>handlers for PEAR::DB.
>
>Matt
>  
>
I looked at pear::auth, but it doesn't look nearly as good as PHPLib's 
auth.  Does it have the challenge-response mechanism where the password 
is never transmitted plain-text?  Does it have the ability to register a 
user?  Or is it at least easy and documented on how to do these things?  
I could be wrong I didnt look at it that thoroughly but I dont think it 
does.

The jury is still out on what to do...

>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Phplib-users mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>
>
>  
>

Re: [Phplib-users] extensions to oohforms, table

[Matt W. <li...@ye...>]

Aric Caley wrote:

> I looked at pear::auth, but it doesn't look nearly as good as PHPLib's 
> auth.  Does it have the challenge-response mechanism where the password 
> is never transmitted plain-text?  Does it have the ability to register a 
> user?  Or is it at least easy and documented on how to do these things?  
> I could be wrong I didnt look at it that thoroughly but I dont think it 
> does.
> 
> The jury is still out on what to do...

Yes I agree Aric there does seem to be a lot of stuff missing that 
PHPLib has.

I think this probably is to do with the maturity of PHPLib over 
pear::auth. I can't help feeling though that there may be a lot of dead 
wood so to speak lurking around in the lib now. More or less all of the 
session stuff seems to now be redundant, and there seems to be little 
development currently happening with PHPLIb.

Any thoughts anyone?

Matt

Re: [Phplib-users] extensions to oohforms, table

[Aric C. <gre...@pe...>]

Matt Williams wrote:

> Yes I agree Aric there does seem to be a lot of stuff missing that 
> PHPLib has.
>
> I think this probably is to do with the maturity of PHPLib over 
> pear::auth. I can't help feeling though that there may be a lot of 
> dead wood so to speak lurking around in the lib now. More or less all 
> of the session stuff seems to now be redundant, and there seems to be 
> little development currently happening with PHPLIb.
>
I'm sure there's lots of "cruft" that could/should be gone over.  
Obviously the session stuff is pretty much useless, except where you 
would want to put sessions into a database (php defaults to using files 
I believe) or you already use phplib.  So, we should keep the sessions 
merely as a compatibility layer, and as a *"session_set_save_handler()" 
*extension.

I dont know if you are familiar with phpslash, but they've made some 
nice extensions to the phplib auth/perm which ought to be integrated 
back into phplib (and they are some of the same people too).  There's 
also some other nice things there I think should be part of phplib, like 
a way of handling class files and being able to overide them, which is cool.

I guess the pear::template_phplib has some improvements we could back-port.

Anybody else listening?

> Any thoughts anyone?
>
> Matt

Re: [Phplib-users] extensions to oohforms, table

[Richard A. <rh...@ju...>]

At 1:35 PM -0700 20/4/04, Aric Caley wrote:

>I guess the pear::template_phplib has some improvements we could back-port.

Last time I checked the only difference between the two template libs
was a couple of dubious bug fixes in the pear lib.

I have a couple of user-sumitted enhancements to template which I will
be merging and committing sometime soon, so I'll do another comparison
between the phplib and pear template classes while I'm at it.

 ...R.

Re: [Phplib-users] Template (was: extensions to oohforms, table)

[Richard A. <rh...@ju...>]

At 7:27 AM +1000 21/4/04, Richard Archer wrote:

>Last time I checked the only difference between the two template libs
>was a couple of dubious bug fixes in the pear lib.

I have just compared the pear and phplib template classes. The
differences amount to:

pear has "fallback" directories where it searches for templates.
pear has reverted to str_replace instead of preg_replace.
phplib has clear_var and unset_var.
pear has a couple of extra bugs and missing features.

So, for me the phplib class is the clear winner.

Although reverting to str_replace might be worthwhile for the phplib
class as it results in cleaner code and a 25% speed increase. I wonder
if it would break any existing applications due to the differences in
the way data is stored in varkeys[].

 ...R.