php-general Digest 5 Mar 2011 05:41:35 -0000 Issue 7211
Topics (messages 311667 through 311682):
Re: Somewhat OT - Stored Procedures
311667 by: Nathan Rixham
311668 by: Nathan Rixham
Re: Overriding session length in existing session?
311669 by: Scott Baker
311676 by: Marc Guay
Re: something about dates in mysql
311670 by: Florin Jurcovici
Double method access (Hi everyone! :))
311671 by: Paola Alvarez
311672 by: alex
311673 by: larry.garfieldtech.com
311675 by: Paola Alvarez
Possible bug in PHP 5.3.5 with OAuth extension?
311674 by: Daniel Hong
311679 by: Daniel Hong
311680 by: Jim Lucas
311681 by: Daniel Hong
311682 by: Daniel Hong
Returning a recordset to a desktop app
311677 by: Ken Watkins
311678 by: larry.garfieldtech.com
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
Hi Nathan,
Nathan Nobbe wrote:
Also, bear in mind that personally I tend to favor OO paradigms for
application development so would prefer feedback that incorporates that
tendency.
Initial thoughts are
Bad:
. Not well suited for ORM, particularly procedures which return multiple
result sets consisting of columns from multiple tables
. Greater potential for duplicated logic, I think this comes down to a well
defined set of rules for any given application, read: convention required
for success
. Scripting languages are vendor specific, and likely most application
developers have a limited understanding thereof
Good:
. Better performance
. <Fill in blank on convincing bullets here>
It's a trade-off thing, and to be looked at on a case by case basis. The
major factors are
- closer to the iron (better performance, as you said)
- information hiding and security
- code portability
If you have multiple clients all doing the same procedure/routine then
it can be wise to used stored procedures/routines, even just for things
like administration and optimization, because the routine is decoupled
from the app tier, with just the interface exposed, you can optimize
without having to change app tier code, delegate to db admins and suchlike.
Likewise, information hiding is also a property of security, you can
expose the bare minimum without letting developers, or those with access
to the code, see the full database layout and structure. Similarly you
can set up logging at procedure level, and ensure acidity of
transactions at db level.
Some of the key factors though, are design choices in the way you code
applications, OO and using ORMs is a significant choice, and perhaps
you're better staying with what's familiar and delegating / trusting the
ORM layer + visible code which you're used to and can tweak easily.
If you were developing C/++ and running on pl-sql over virtuoso or
something the advice may be different.
Do remember that you aren't tied to RDBMS in any way though, there's a
huge world of [ http://nosql-database.org/ choices and styles ] out
there that also should/could be considered, many of which suit the OO
style far better ;)
Best,
Nathan (namesake)
--- End Message ---
--- Begin Message ---
Richard Quadling wrote:
At a fundamental level, my PHP code isn't concerning itself with any
physical data structures. As much as possible my PHP code treats the
sql data source as a processor ready to supply data in a standardized
form (even hierarchical) and to accept data for storage (again
hierarchical). My PHP code knows next to nothing about the table
structure (why should it - it isn't a database).
Exactly - separation of concerns, a core principal to learn and apply
wherever you can.
--- End Message ---
--- Begin Message ---
On 03/04/2011 05:37 AM, Marc Guay wrote:
> Howdy. Don't sessions expire when the browser closes as a rule? Do
> you mean the session cookie? Why not store the cookie, if one exists,
> in a $_SESSION variable in your header file and then refer to that in
> the rest of your code, rather than the cookie. Then when you want to
> destroy the session cookie, you can overwrite it and the existing
> session will still flow using the $_SESSION vars until the browser
> closes.
>
> It's early here, I hope that sort of makes sense and that I've at
> least sort of understood the problem.
I'm setting my session cookies, and my session data on the server to
expire X days in the future. That's set globally in my header.php file.
When the use logs in it stores their login information in the session
and it's good for 7 days. I have an option on the login page "public
terminal" that I want to make clear the session on browser close. The
problem is that I've already (in header.php) told the session cookie
that it's good for 7 days. I was just trying to override that already
established session cookie.
- Scott
--- End Message ---
--- Begin Message ---
I think that my suggestion is still a valid solution, someone correct
me if I'm wrong. Let's say your code went like this:
session_start();
// Check to see if the session variable has already been set, if not
if (!isset($_SESSION['var'])){
// Check to see if it's been stored in a cookie
if (isset($_COOKIE['var'])){
$_SESSION['var'] = $_COOKIE['var'];
}
// If not, set the session variable and store it in a cookie for 7 days
else{
$_SESSION['var'] = "value";
setcookie ("var", $_SESSION['var'], time()+86400 * 7, "/",
".domain.com");
}
}
echo "Here I am using my session variable, it's value is ".$_SESSION['var'];
So if that's in the header of every page, but you want to make an
acception if the person is using a public computer, you just add
something like:
if ($_POST['public_terminal'] === TRUE){
// "Delete" the cookie
setcookie("var","",time() - 3600);
}
echo "Here I am *still* using my session variable, it's value is
".$_SESSION['var']." and it will expire when the browser closes";
Marc
--- End Message ---
--- Begin Message ---
Why don't you use mysqli or PDO, when passing dates as parameters?
If it's just about the right SQL, you _should_ actually use dates as
strings - this is how mysql is able to handle them properly. However,
you absolutely need to use a format of 'yyyy-mm-dd', or else MySQL may
fail on interpreting them properly.
(Had a similar problem recently, that's how I came to remember this.)
--- End Message ---
--- Begin Message ---
Hi there!,
I have been reading this list before but this is my first post.
Reading some code from Symfony I got this: $this->getTable()->getColumns()
...when you can use this double method access?, I used before the
regular $this->getTable(), but two?. I mean I have been trying but I got an
error*
* Fatal error: Call to a member function ... on a non-object in ...
Thanks!
Paola
PS: BTW, sorry my english isnt really good
--- End Message ---
--- Begin Message ---
On 03/04/2011 09:25 PM, Paola Alvarez wrote:
Hi there!,
I have been reading this list before but this is my first post.
Reading some code from Symfony I got this: $this->getTable()->getColumns()
...when you can use this double method access?, I used before the
regular $this->getTable(), but two?. I mean I have been trying but I got an
error*
* Fatal error: Call to a member function ... on a non-object in ...
I think the problem is $this->getTable() returns non-object.
There is nothing wrong with using multiply "->" as long as return-value
from previous call is an object.
Alex
--- End Message ---
--- Begin Message ---
That's called method chaining. ->getColumns() will get called on the
object returned by ->getTable(). That is, getTable() returns an object
(presumably representing an SQL table, I guess), and that object has a
getColumns() method, which you call.
This is an extremely common style in Javascript code that has been
gaining widespread use in PHP OO circles in recent years. If leveraged
properly it can create very compact, very readable, very powerful code.
(And if done stupidly can lead to a horrid mess, but that's true of
any coding style.)
--Larry Garfield
On 3/4/11 1:25 PM, Paola Alvarez wrote:
Hi there!,
I have been reading this list before but this is my first post.
Reading some code from Symfony I got this: $this->getTable()->getColumns()
...when you can use this double method access?, I used before the
regular $this->getTable(), but two?. I mean I have been trying but I got an
error*
* Fatal error: Call to a member function ... on a non-object in ...
Thanks!
Paola
PS: BTW, sorry my english isnt really good
--- End Message ---
--- Begin Message ---
Hi, thanks a lot Alex and Larry for your very clear answer!
Paola,
On Fri, Mar 4, 2011 at 4:33 PM, [email protected] <
[email protected]> wrote:
> That's called method chaining. ->getColumns() will get called on the
> object returned by ->getTable(). That is, getTable() returns an object
> (presumably representing an SQL table, I guess), and that object has a
> getColumns() method, which you call.
>
> This is an extremely common style in Javascript code that has been gaining
> widespread use in PHP OO circles in recent years. If leveraged properly it
> can create very compact, very readable, very powerful code. (And if done
> stupidly can lead to a horrid mess, but that's true of any coding style.)
>
> --Larry Garfield
>
>
> On 3/4/11 1:25 PM, Paola Alvarez wrote:
>
>> Hi there!,
>> I have been reading this list before but this is my first post.
>> Reading some code from Symfony I got this: $this->getTable()->getColumns()
>> ...when you can use this double method access?, I used before the
>> regular $this->getTable(), but two?. I mean I have been trying but I got
>> an
>> error*
>>
>> * Fatal error: Call to a member function ... on a non-object in ...
>>
>> Thanks!
>>
>> Paola
>>
>> PS: BTW, sorry my english isnt really good
>>
>>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Hello,
I'm using the PHP OAuth extension and running into a strange issue. I'm not
sure if it's a bug in PHP 5.3.5, or if it's a bug in the OAuth extension
when installed on a system with PHP 5.3.5.
On a machine with PHP 5.3.5, when I call OAuth::fetch() with http method of
POST, the debug info is showing that it is sending as a GET request. As a
result, the resource that I'm fetching returns with failure since it will
only respond to a POST request. I tested this out on two different machines,
and getting the same result on both. One machine is Ubuntu 10.04 with nginx
0.8.54 and PHP 5.3.5. The other is CentOS 5.5 with apache 2.2 and PHP 5.3.5.
I have another Ubuntu 10.04 machine with PHP 5.3.3, and I am not having this
issue on that machine. The OAuth debug info is correctly showing http method
of POST.
I guess I'll need to use PHP 5.3.3 in the mean time, but it would be great
to know what the problem is.
Thanks,
daniel
--- End Message ---
--- Begin Message ---
Correction:
I stated the incorrect version of PHP that does not seem to have this issue.
The version of PHP that works correctly is 5.3.2, not 5.3.3.
Thanks,
daniel
On Fri, Mar 4, 2011 at 11:40 AM, Daniel Hong <[email protected]> wrote:
> Hello,
>
> I'm using the PHP OAuth extension and running into a strange issue. I'm not
> sure if it's a bug in PHP 5.3.5, or if it's a bug in the OAuth extension
> when installed on a system with PHP 5.3.5.
>
> On a machine with PHP 5.3.5, when I call OAuth::fetch() with http method of
> POST, the debug info is showing that it is sending as a GET request. As a
> result, the resource that I'm fetching returns with failure since it will
> only respond to a POST request. I tested this out on two different machines,
> and getting the same result on both. One machine is Ubuntu 10.04 with nginx
> 0.8.54 and PHP 5.3.5. The other is CentOS 5.5 with apache 2.2 and PHP 5.3.5.
>
> I have another Ubuntu 10.04 machine with PHP 5.3.3, and I am not having
> this issue on that machine. The OAuth debug info is correctly showing http
> method of POST.
>
> I guess I'll need to use PHP 5.3.3 in the mean time, but it would be great
> to know what the problem is.
>
> Thanks,
> daniel
>
--- End Message ---
--- Begin Message ---
On 3/4/2011 5:18 PM, Daniel Hong wrote:
> Correction:
>
> I stated the incorrect version of PHP that does not seem to have this issue.
> The version of PHP that works correctly is 5.3.2, not 5.3.3.
Can you give us an example of what you are doing?
Jim Lucas
>
> Thanks,
> daniel
>
> On Fri, Mar 4, 2011 at 11:40 AM, Daniel Hong <[email protected]> wrote:
>
>> Hello,
>>
>> I'm using the PHP OAuth extension and running into a strange issue. I'm not
>> sure if it's a bug in PHP 5.3.5, or if it's a bug in the OAuth extension
>> when installed on a system with PHP 5.3.5.
>>
>> On a machine with PHP 5.3.5, when I call OAuth::fetch() with http method of
>> POST, the debug info is showing that it is sending as a GET request. As a
>> result, the resource that I'm fetching returns with failure since it will
>> only respond to a POST request. I tested this out on two different machines,
>> and getting the same result on both. One machine is Ubuntu 10.04 with nginx
>> 0.8.54 and PHP 5.3.5. The other is CentOS 5.5 with apache 2.2 and PHP 5.3.5.
>>
>> I have another Ubuntu 10.04 machine with PHP 5.3.3, and I am not having
>> this issue on that machine. The OAuth debug info is correctly showing http
>> method of POST.
>>
>> I guess I'll need to use PHP 5.3.3 in the mean time, but it would be great
>> to know what the problem is.
>>
>> Thanks,
>> daniel
>>
>
--- End Message ---
--- Begin Message ---
Hi Jim,
I'm using oauth to connect to Dropbox. The OAuth::getRequestToken()
and OAuth::getAccessToken()
works without a problem since (assuming) those are sent over the wire as a
GET request. When I try to issue a fetch command, for example:
$oauth->enableDebug()
$oauth->fetch('https://api.dropbox.com/0/account', array(),
OAUTH_HTTP_METHOD_POST);
print_r($oauth->debugInfo);
In the debug info, the SBS string is showing that the http request method
was GET, not POST.
When I execute the same code on a machine running PHP 5.3.2, the SBS string
shows POST.
I took a look at the source for the oauth extension, it looks like requests
could be made with PHP streams or with curl, but I couldn't tell what was
the default. There is an OAuth::setRequestEngine() which you can pass in a
constant for using either PHP streams or curl. The constant for using curl
(OAUTH_REQENGINE_CURL) doesn't exist. When I try to print the constant, it
just shows the "undefined" error message. I have the latest version of the
oauth extension installed, so not sure what's wrong.
When I view phpinfo, under oauth, it shows "Request engine support" is
php_streams. But I'm not sure this entirely matters since on the server that
does work, phpinfo shows that "Request engine support" is also php_streams.
On a side question, why is it only showing that php_streams is supported?
Why not curl as well? The php curl package is installed...
Thanks,
daniel
On Fri, Mar 4, 2011 at 5:30 PM, Jim Lucas <[email protected]> wrote:
> On 3/4/2011 5:18 PM, Daniel Hong wrote:
> > Correction:
> >
> > I stated the incorrect version of PHP that does not seem to have this
> issue.
> > The version of PHP that works correctly is 5.3.2, not 5.3.3.
>
> Can you give us an example of what you are doing?
>
> Jim Lucas
>
> >
> > Thanks,
> > daniel
> >
> > On Fri, Mar 4, 2011 at 11:40 AM, Daniel Hong <[email protected]>
> wrote:
> >
> >> Hello,
> >>
> >> I'm using the PHP OAuth extension and running into a strange issue. I'm
> not
> >> sure if it's a bug in PHP 5.3.5, or if it's a bug in the OAuth extension
> >> when installed on a system with PHP 5.3.5.
> >>
> >> On a machine with PHP 5.3.5, when I call OAuth::fetch() with http method
> of
> >> POST, the debug info is showing that it is sending as a GET request. As
> a
> >> result, the resource that I'm fetching returns with failure since it
> will
> >> only respond to a POST request. I tested this out on two different
> machines,
> >> and getting the same result on both. One machine is Ubuntu 10.04 with
> nginx
> >> 0.8.54 and PHP 5.3.5. The other is CentOS 5.5 with apache 2.2 and PHP
> 5.3.5.
> >>
> >> I have another Ubuntu 10.04 machine with PHP 5.3.3, and I am not having
> >> this issue on that machine. The OAuth debug info is correctly showing
> http
> >> method of POST.
> >>
> >> I guess I'll need to use PHP 5.3.3 in the mean time, but it would be
> great
> >> to know what the problem is.
> >>
> >> Thanks,
> >> daniel
> >>
> >
>
>
--- End Message ---
--- Begin Message ---
Ok, I'm such a dud. Looks like someone had already reported this exact bug
http://pecl.php.net/bugs/bug.php?id=22485
I actually was looking at the problematic method in the source, but didn't
catch the problem. But now that someone has pointed it out, it's so obvious.
I deserve a slap on the back of my head!
I've gone and install version 1.0.0 for the time being, seems to be working
fine.
-daniel
On Fri, Mar 4, 2011 at 6:19 PM, Daniel Hong <[email protected]> wrote:
> Hi Jim,
>
> I'm using oauth to connect to Dropbox. The OAuth::getRequestToken() and
> OAuth::getAccessToken()
> works without a problem since (assuming) those are sent over the wire as a
> GET request. When I try to issue a fetch command, for example:
>
> $oauth->enableDebug()
> $oauth->fetch('https://api.dropbox.com/0/account', array(),
> OAUTH_HTTP_METHOD_POST);
> print_r($oauth->debugInfo);
>
> In the debug info, the SBS string is showing that the http request method
> was GET, not POST.
>
> When I execute the same code on a machine running PHP 5.3.2, the SBS string
> shows POST.
>
> I took a look at the source for the oauth extension, it looks like requests
> could be made with PHP streams or with curl, but I couldn't tell what was
> the default. There is an OAuth::setRequestEngine() which you can pass in a
> constant for using either PHP streams or curl. The constant for using curl
> (OAUTH_REQENGINE_CURL) doesn't exist. When I try to print the constant, it
> just shows the "undefined" error message. I have the latest version of the
> oauth extension installed, so not sure what's wrong.
>
> When I view phpinfo, under oauth, it shows "Request engine support" is
> php_streams. But I'm not sure this entirely matters since on the server that
> does work, phpinfo shows that "Request engine support" is also php_streams.
>
> On a side question, why is it only showing that php_streams is supported?
> Why not curl as well? The php curl package is installed...
>
> Thanks,
> daniel
>
>
> On Fri, Mar 4, 2011 at 5:30 PM, Jim Lucas <[email protected]> wrote:
>
>> On 3/4/2011 5:18 PM, Daniel Hong wrote:
>> > Correction:
>> >
>> > I stated the incorrect version of PHP that does not seem to have this
>> issue.
>> > The version of PHP that works correctly is 5.3.2, not 5.3.3.
>>
>> Can you give us an example of what you are doing?
>>
>> Jim Lucas
>>
>> >
>> > Thanks,
>> > daniel
>> >
>> > On Fri, Mar 4, 2011 at 11:40 AM, Daniel Hong <[email protected]>
>> wrote:
>> >
>> >> Hello,
>> >>
>> >> I'm using the PHP OAuth extension and running into a strange issue. I'm
>> not
>> >> sure if it's a bug in PHP 5.3.5, or if it's a bug in the OAuth
>> extension
>> >> when installed on a system with PHP 5.3.5.
>> >>
>> >> On a machine with PHP 5.3.5, when I call OAuth::fetch() with http
>> method of
>> >> POST, the debug info is showing that it is sending as a GET request. As
>> a
>> >> result, the resource that I'm fetching returns with failure since it
>> will
>> >> only respond to a POST request. I tested this out on two different
>> machines,
>> >> and getting the same result on both. One machine is Ubuntu 10.04 with
>> nginx
>> >> 0.8.54 and PHP 5.3.5. The other is CentOS 5.5 with apache 2.2 and PHP
>> 5.3.5.
>> >>
>> >> I have another Ubuntu 10.04 machine with PHP 5.3.3, and I am not having
>> >> this issue on that machine. The OAuth debug info is correctly showing
>> http
>> >> method of POST.
>> >>
>> >> I guess I'll need to use PHP 5.3.3 in the mean time, but it would be
>> great
>> >> to know what the problem is.
>> >>
>> >> Thanks,
>> >> daniel
>> >>
>> >
>>
>>
>
--- End Message ---
--- Begin Message ---
Hi All.
I have a Windows desktop app that I created using Visual Foxpro (a database
app).
I want to write a PHP script that I will call from my desktop app. The script
will simply
query a MySQL database on my web server and return the recordset to the desktop
app.
My question is simply this: What is the preferred method for passing this
recordset back
to the desktop app? I'm assuming that there's no reasonable way to send a
recordset back
without converting it to an array or XML or an object or something? How do I
return the
data in the recordset to the desktop app?
Thanks for your advice.
Ken Watkins
--- End Message ---
--- Begin Message ---
Assuming you mean that the PHP script is on a web server somewhere and
the desktop app is hitting it over HTTP, it's no different than any
other response. Anything you print will be sent back to the client, in
this case your desktop a.. So if you want to send XML back, you'd build
a string with your XML (either manually or using the DOM or SimpleXML
APIs or a 3rd party like QueryPath or whatever floats your boat) and
print it, just as you would HTML.
Note that you may need to explicitly set headers with header() to make
sure the desktop app reads it properly.
--Larry Garfield
On 3/4/11 5:48 PM, Ken Watkins wrote:
Hi All.
I have a Windows desktop app that I created using Visual Foxpro (a database
app).
I want to write a PHP script that I will call from my desktop app. The script
will simply
query a MySQL database on my web server and return the recordset to the desktop
app.
My question is simply this: What is the preferred method for passing this
recordset back
to the desktop app? I'm assuming that there's no reasonable way to send a
recordset back
without converting it to an array or XML or an object or something? How do I
return the
data in the recordset to the desktop app?
Thanks for your advice.
Ken Watkins
--- End Message ---
