php-general Digest 5 Mar 2011 18:03:03 -0000 Issue 7212
Topics (messages 311683 through 311699):
$GLOBALS example script on php.net
311683 by: Ashim Kapoor
311687 by: Richard Quadling
311688 by: Ashim Kapoor
311689 by: David Hutto
311697 by: Daniel Brown
Re: error message for date()
311684 by: clancy_1.cybec.com.au
311685 by: Simon J Welsh
Re: Returning a recordset to a desktop app
311686 by: Richard Quadling
311692 by: Ken Watkins
311693 by: Ken Watkins
Re: Somewhat OT - Stored Procedures
311690 by: Florin Jurcovici
311694 by: Vivek
311695 by: Vivek
Re: Double method access (Hi everyone! :))
311691 by: Vivek
Regex for extracting quoted strings
311696 by: Mark Kelly
311698 by: Nathan Rixham
Re: Overriding session length in existing session?
311699 by: tedd
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 ---
Dear all,
I was reading this page
http://php.net/manual/en/reserved.variables.globals.php and I found the
following script there : ----
Here's a function which returns an array of all user defined global
variables:
<?php
function globals() {
$globals = $GLOBALS;
foreach (array(
'GLOBALS',
'_ENV',
'HTTP_ENV_VARS',
'_POST',
'HTTP_POST_VARS',
'_GET',
'HTTP_GET_VARS',
'_COOKIE',
'HTTP_COOKIE_VARS',
'_SERVER',
'HTTP_SERVER_VARS',
'_FILES',
'HTTP_POST_FILES',
'_REQUEST'
) as $var) {
unset($globals[$var]);
}
return $globals;
}
?>
I think that this script UNSETS each supergobal variable,but page says that
it returns ALL user defined vars ? Can some one tell me how that is ?
Thank you,
Ashim
--- End Message ---
--- Begin Message ---
On 5 March 2011 05:44, Ashim Kapoor <[email protected]> wrote:
> Dear all,
>
> I was reading this page
> http://php.net/manual/en/reserved.variables.globals.php and I found the
> following script there : ----
>
>
> Here's a function which returns an array of all user defined global
> variables:
>
> <?php
> function globals() {
> $globals = $GLOBALS;
> foreach (array(
> 'GLOBALS',
> '_ENV',
> 'HTTP_ENV_VARS',
> '_POST',
> 'HTTP_POST_VARS',
> '_GET',
> 'HTTP_GET_VARS',
> '_COOKIE',
> 'HTTP_COOKIE_VARS',
> '_SERVER',
> 'HTTP_SERVER_VARS',
> '_FILES',
> 'HTTP_POST_FILES',
> '_REQUEST'
> ) as $var) {
> unset($globals[$var]);
> }
>
> return $globals;
> }
> ?>
>
> I think that this script UNSETS each supergobal variable,but page says that
> it returns ALL user defined vars ? Can some one tell me how that is ?
>
> Thank you,
> Ashim
>
You are right. The user note is incorrect.
I'll remove it.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
>
> I'll remove it.
>
How does one remove user notes from php.net ?
Thank you,
Ashim
--- End Message ---
--- Begin Message ---
On Sat, Mar 5, 2011 at 5:10 AM, Ashim Kapoor <[email protected]> wrote:
>>
>> I'll remove it.
>>
>
> How does one remove user notes from php.net ?
>
I'd guest they had been granted access to the php.net page editor, but
I may be wrong. Not that that site hasn't been scraped by other sites
and added to their content, or been catalogued by google cache or
alexis, etc.
Thank you,
> Ashim
>
--
According to theoretical physics, the division of spatial intervals as
the universe evolves gives rise to the fact that in another timeline,
your interdimensional counterpart received helpful advice from me...so
be eternally pleased for them.
--- End Message ---
--- Begin Message ---
On Sat, Mar 5, 2011 at 05:42, David Hutto <[email protected]> wrote:
>
> I'd guest they had been granted access to the php.net page editor, but
> I may be wrong. Not that that site hasn't been scraped by other sites
> and added to their content, or been catalogued by google cache or
> alexis, etc.
Richard is part of the documentation management team here in the
PHP project. That's the only way you can modify or remove user notes.
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
--- End Message ---
--- Begin Message ---
After a long battle to get my system back on air after a hard disk crash, I got
PHP 5.3.5
running under Apache 2.2.3. I now get a diagnostic every time I call date(),
complaining
about a missing parameter. The manual states that the second parameter is
optional, and
even phpinfo doesn't know about this new requirement, as it contains the same
diagnostic:
"Warning: phpinfo(): It is not safe to rely on the system's timezone settings.
You are
*required* to use the date.timezone setting or the date_default_timezone_set()
function.
In case you used any of those methods and you are still getting this warning,
you most
likely misspelled the timezone identifier. We selected 'Australia/Melbourne' for
'11.0/DST' instead in D:\Websites\index.php on line 1 Warning: phpinfo(): It is
not safe
to rely on the system's timezone settings. You are *required* to use the
date.timezone
setting or the date_default_timezone_set() function. In case you used any of
those methods
and you are still getting this warning, you most likely misspelled the timezone
identifier. We selected 'Australia/Melbourne' for '11.0/DST' instead in
D:\Websites\index.php on line 1 ".
Is this a bug, or a new requirement we will have to get used to?
Roger Riordan AM
--- End Message ---
--- Begin Message ---
On 5/03/2011, at 8:29 PM, [email protected] wrote:
> After a long battle to get my system back on air after a hard disk crash, I
> got PHP 5.3.5
> running under Apache 2.2.3. I now get a diagnostic every time I call date(),
> complaining
> about a missing parameter. The manual states that the second parameter is
> optional, and
> even phpinfo doesn't know about this new requirement, as it contains the same
> diagnostic:
>
> "Warning: phpinfo(): It is not safe to rely on the system's timezone
> settings. You are
> *required* to use the date.timezone setting or the
> date_default_timezone_set() function.
> In case you used any of those methods and you are still getting this warning,
> you most
> likely misspelled the timezone identifier. We selected 'Australia/Melbourne'
> for
> '11.0/DST' instead in D:\Websites\index.php on line 1 Warning: phpinfo(): It
> is not safe
> to rely on the system's timezone settings. You are *required* to use the
> date.timezone
> setting or the date_default_timezone_set() function. In case you used any of
> those methods
> and you are still getting this warning, you most likely misspelled the
> timezone
> identifier. We selected 'Australia/Melbourne' for '11.0/DST' instead in
> D:\Websites\index.php on line 1 ".
>
> Is this a bug, or a new requirement we will have to get used to?
>
>
>
> Roger Riordan AM
It's not complaining about a missing parameter, it's complaining about the lack
of a specified timezone.
This warning was introduced in PHP5.1, and you either need to set the
date.timezone INI setting, either in your php.ini or by using ini_set(), or by
passing a valid timezone to date_default_timezone_set() before calling any
other date-related functions.
---
Simon Welsh
Admin of http://simon.geek.nz/
Who said Microsoft never created a bug-free program? The blue screen never,
ever crashes!
http://www.thinkgeek.com/brain/gimme.cgi?wid=81d520e5e
--- End Message ---
--- Begin Message ---
On 4 March 2011 23:48, Ken Watkins <[email protected]> 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
In general terms, the output of a PHP script is going to be text
(html, xml, csv, etc.) or binary (images).
Getting a PHP script to communicate natively with FoxPro is not going
to be trivial task. It MAY be able to be done, but hopefully FoxPro
has the capability of running a PHP script via the command line ...
C:\PHP5\php.exe -f script.php -- script_arg1 script_arg2
PHP can either output the result set (in an appropriate form) directly
and FoxPro could read it from STDIN (if it has that support) or PHP
can write the answer to a file and FoxPro can use normal file and
string functions to read the data.
If FoxPro has XML support, then use it. It will be much cleaner in the
long run if the data changes. If not, then a tab separated data file
(rather than a CSV file). This assumes that your data does not contain
tabs. If so, choose another separator.
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
Larry,
Yes, the PHP script will reside on my web server along with the MySQL database.
I assumed that I would call the script over HTTP, but I guess that is part of
my question too.
Foxpro allows you to embed controls in its forms, and one of them is a browser
control. But
I don't really want to echo anything to the enduser, I just want to capture the
data behind
the scenes, so to speak. I think I can handle that with the browser control.
If I understand you correctly, when I do an echo statement or a print statement
(or a return()?),
it will return the data to the desktop app. And the best way to return it is in
xml. I'll investigate
the methods you mention for converting xml since I'm not familiar with any of
them.
Thanks!
Ken
On 3/4/2011 6:51 PM, [email protected] wrote:
> 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 ---
--- Begin Message ---
On 3/5/2011 4:30 AM, Richard Quadling wrote:
> On 4 March 2011 23:48, Ken Watkins <[email protected]> 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
> In general terms, the output of a PHP script is going to be text
> (html, xml, csv, etc.) or binary (images).
>
> Getting a PHP script to communicate natively with FoxPro is not going
> to be trivial task. It MAY be able to be done, but hopefully FoxPro
> has the capability of running a PHP script via the command line ...
>
> C:\PHP5\php.exe -f script.php -- script_arg1 script_arg2
>
> PHP can either output the result set (in an appropriate form) directly
> and FoxPro could read it from STDIN (if it has that support) or PHP
> can write the answer to a file and FoxPro can use normal file and
> string functions to read the data.
>
> If FoxPro has XML support, then use it. It will be much cleaner in the
> long run if the data changes. If not, then a tab separated data file
> (rather than a CSV file). This assumes that your data does not contain
> tabs. If so, choose another separator.
>
> Richard.
Richard,
Foxpro does have XML support, so you answered that part of my question, thanks.
And it is capable of calling any other executable on the local machine through
the
local OS shell - which seems to be what you are advocating. But I'm not sure how
I would do that over the internet. I just discussed this issue with Larry, and
I assume
that I would use HTTP? Or is there a way to call a command line script on a
remote
web server without using HTTP? Sorry if this is a stupid question.
Thanks for your help!
Ken
--- End Message ---
--- Begin Message ---
Hi.
I would always recommend stored procedures, as long as there are a
very few rules obeyed:
- keep them simple - they should mostly implement just CRUD operations
plus application-specific searches, and should not encapsulate any
other logic
- use just portable SQL (well, as long as this is possible)
My reasoning for using stored procedures and sticking to these rules
is the following:
- no matter what you do, especially with PHP, you can't achieve the
same performance if you generate your SQL on the fly as when you just
call a precompiled stored procedure
- by keeping stored procedures very simple, and sticking to the
convention of packing just CRUD + specialized searches into them, plus
using just portable SQL, inasmuch as possible, you can easily switch
databases - in most cases, just copying over the stored procedures
does the trick
- for the same reasons listed for the previous point, the readability
of your application is much improved - reading
"users_getByLogin(:login)" is IMO easier to comprehend than "SELECT *
FROM USERS WHERE loginName = :login", without sacrificing any
performance or portability, compared to using inline SQL statements as
strings
The consequences of not sticking to the above listed two criteria can
be very bad:
- packing more than reasonable logic into the database makes your
application incomprehensible - for instance
"company_doMonthEndCalculations()" is likely to include such a huge
quantity of logic, that the PHP code calling it is mostly irrelevant,
and you must actually comprehend both the details of the SQL in the
database (in the stored procedures) and the way PHP is connecting them
to understand an application - obviously harder if you have all your
logic in just one place
- using non-portable SQL may be quite a deterrent from porting to a
new database, or may cause a lot more effort than needed, and isn't in
fact justified in most cases
- whereas if packing only very specific and simple operations into
stored procedures allows you to keep the design of the PHP application
very object-oriented, packing very much logic into stored procedures
may cause your PHP code to be just an adapter to an application
written in SQL, instead of being the application itself; SQL being
procedural, your application will have all the flexibility,
extensibility and maintainability problems that a non-OO design causes
br,
flj
--
Fine counsel is confusing, but example is always clear. (Edgar A.
Guest, The Light of Faith)
PS: I'm not trying to be a smart-ass, but IMO stored procedures are
underrated (not just by PHP programmers), and it's a pity (and it
leads to sub-optimal applications, and to the development of cures for
the symptoms instead of the cause, at least on other platforms than
PHP), and not letting a database do what it does best is simply
stupid. That's why I try advertising their use whenever I have an
opportunity.
--- End Message ---
--- Begin Message ---
Hi Team
I very much agree with the points shared by Florin (esp. the two rules).
But unfortunately, these rules are not standards and that is where the real
problem lies.
The injudicious use of SPs leads to un-manageable code which is rarely
portable (real life situations J which are too common to be overlooked).
Hoping that everyone will stick to and follow the best practices while
creating code.
Regards
NetEmp
On Sat, Mar 5, 2011 at 6:01 PM, Florin Jurcovici <[email protected]
> wrote:
> Hi.
>
> I would always recommend stored procedures, as long as there are a
> very few rules obeyed:
> - keep them simple - they should mostly implement just CRUD operations
> plus application-specific searches, and should not encapsulate any
> other logic
> - use just portable SQL (well, as long as this is possible)
>
> My reasoning for using stored procedures and sticking to these rules
> is the following:
> - no matter what you do, especially with PHP, you can't achieve the
> same performance if you generate your SQL on the fly as when you just
> call a precompiled stored procedure
> - by keeping stored procedures very simple, and sticking to the
> convention of packing just CRUD + specialized searches into them, plus
> using just portable SQL, inasmuch as possible, you can easily switch
> databases - in most cases, just copying over the stored procedures
> does the trick
> - for the same reasons listed for the previous point, the readability
> of your application is much improved - reading
> "users_getByLogin(:login)" is IMO easier to comprehend than "SELECT *
> FROM USERS WHERE loginName = :login", without sacrificing any
> performance or portability, compared to using inline SQL statements as
> strings
>
> The consequences of not sticking to the above listed two criteria can
> be very bad:
> - packing more than reasonable logic into the database makes your
> application incomprehensible - for instance
> "company_doMonthEndCalculations()" is likely to include such a huge
> quantity of logic, that the PHP code calling it is mostly irrelevant,
> and you must actually comprehend both the details of the SQL in the
> database (in the stored procedures) and the way PHP is connecting them
> to understand an application - obviously harder if you have all your
> logic in just one place
> - using non-portable SQL may be quite a deterrent from porting to a
> new database, or may cause a lot more effort than needed, and isn't in
> fact justified in most cases
> - whereas if packing only very specific and simple operations into
> stored procedures allows you to keep the design of the PHP application
> very object-oriented, packing very much logic into stored procedures
> may cause your PHP code to be just an adapter to an application
> written in SQL, instead of being the application itself; SQL being
> procedural, your application will have all the flexibility,
> extensibility and maintainability problems that a non-OO design causes
>
> br,
>
> flj
>
> --
> Fine counsel is confusing, but example is always clear. (Edgar A.
> Guest, The Light of Faith)
>
> PS: I'm not trying to be a smart-ass, but IMO stored procedures are
> underrated (not just by PHP programmers), and it's a pity (and it
> leads to sub-optimal applications, and to the development of cures for
> the symptoms instead of the cause, at least on other platforms than
> PHP), and not letting a database do what it does best is simply
> stupid. That's why I try advertising their use whenever I have an
> opportunity.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Hi Team
I very much agree with the points shared by Florin (esp. the two rules).
But unfortunately, these rules are not standards and that is where the real
problem lies.
The injudicious use of SPs leads to un-manageable code which is rarely
portable (real life situations J which are too common to be overlooked).
Hoping that everyone will stick to and follow the best practices while
creating code.
Regards
NetEmp
On Sat, Mar 5, 2011 at 6:01 PM, Florin Jurcovici <[email protected]
> wrote:
> Hi.
>
> I would always recommend stored procedures, as long as there are a
> very few rules obeyed:
> - keep them simple - they should mostly implement just CRUD operations
> plus application-specific searches, and should not encapsulate any
> other logic
> - use just portable SQL (well, as long as this is possible)
>
> My reasoning for using stored procedures and sticking to these rules
> is the following:
> - no matter what you do, especially with PHP, you can't achieve the
> same performance if you generate your SQL on the fly as when you just
> call a precompiled stored procedure
> - by keeping stored procedures very simple, and sticking to the
> convention of packing just CRUD + specialized searches into them, plus
> using just portable SQL, inasmuch as possible, you can easily switch
> databases - in most cases, just copying over the stored procedures
> does the trick
> - for the same reasons listed for the previous point, the readability
> of your application is much improved - reading
> "users_getByLogin(:login)" is IMO easier to comprehend than "SELECT *
> FROM USERS WHERE loginName = :login", without sacrificing any
> performance or portability, compared to using inline SQL statements as
> strings
>
> The consequences of not sticking to the above listed two criteria can
> be very bad:
> - packing more than reasonable logic into the database makes your
> application incomprehensible - for instance
> "company_doMonthEndCalculations()" is likely to include such a huge
> quantity of logic, that the PHP code calling it is mostly irrelevant,
> and you must actually comprehend both the details of the SQL in the
> database (in the stored procedures) and the way PHP is connecting them
> to understand an application - obviously harder if you have all your
> logic in just one place
> - using non-portable SQL may be quite a deterrent from porting to a
> new database, or may cause a lot more effort than needed, and isn't in
> fact justified in most cases
> - whereas if packing only very specific and simple operations into
> stored procedures allows you to keep the design of the PHP application
> very object-oriented, packing very much logic into stored procedures
> may cause your PHP code to be just an adapter to an application
> written in SQL, instead of being the application itself; SQL being
> procedural, your application will have all the flexibility,
> extensibility and maintainability problems that a non-OO design causes
>
> br,
>
> flj
>
> --
> Fine counsel is confusing, but example is always clear. (Edgar A.
> Guest, The Light of Faith)
>
> PS: I'm not trying to be a smart-ass, but IMO stored procedures are
> underrated (not just by PHP programmers), and it's a pity (and it
> leads to sub-optimal applications, and to the development of cures for
> the symptoms instead of the cause, at least on other platforms than
> PHP), and not letting a database do what it does best is simply
> stupid. That's why I try advertising their use whenever I have an
> opportunity.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Vivek
88 6096 7077
--- End Message ---
--- Begin Message ---
I also totally agree with Larry that if used judiciously then method/object
chaining can give great results, else otherwise, can create a lot of
overhead in the application.
Netemp
On Sat, Mar 5, 2011 at 1:14 AM, Paola Alvarez <[email protected]>wrote:
> 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 ---
Hi.
I'm hoping someone can help me extract text between double quotes from a
string.
$regex = 'some magic';
$r = preg_match($regex, $sentence, $phrases);
So, if
$sentence = 'Dave said "This is it". "Nope, that is the wrong colour" she
replied.';
I want $phrases to contain 'This is it' and 'Nope, that is the wrong colour'.
Can anyone help?
Cheers,
Mark
--- End Message ---
--- Begin Message ---
Mark Kelly wrote:
Hi.
I'm hoping someone can help me extract text between double quotes from a
string.
$regex = 'some magic';
$r = preg_match($regex, $sentence, $phrases);
So, if
$sentence = 'Dave said "This is it". "Nope, that is the wrong colour" she
replied.';
I want $phrases to contain 'This is it' and 'Nope, that is the wrong colour'.
Can anyone help?
$regex = '/"(.*)"/imU';
$r = preg_match_all($regex, $sentence, $phrases);
--- End Message ---
--- Begin Message ---
At 5:00 PM -0800 3/3/11, Scott Baker wrote:
On 03/03/2011 04:31 PM, tedd wrote:
> Simple answer -- put session_start() at the start of your code -- first
line.
Of index.php or header.php? You lost me.
--
Scott Baker - Canby Telcom
Scott:
The statement should be at the start of every php file that has php code in it.
For example, if you have three web pages (index.php, services.php,
and contact.php) AND you have php code in each that share session
data, then the first statement in every page should be:
<?php session_start;
Here's a working example:
http://www.webbytedd.com/b/sessions/index.php
The code is there.
Cheers,
tedd
--
-------
http://sperling.com/
--- End Message ---
