Robert Cummings wrote:
I can't remember what sort of environment the OP was in, but if any
sort of organised testing is done, the use of two different APIs will
just about double the test-effort. Which is why I still think the
best option is to mandate _one_ of the APIs and choose your
On Dec 12, 2007 4:47 AM, Per Jessen [EMAIL PROTECTED] wrote:
Robert Cummings wrote:
I can't remember what sort of environment the OP was in, but if any
sort of organised testing is done, the use of two different APIs will
just about double the test-effort. Which is why I still think the
On Wed, 2007-12-12 at 10:47 +0100, Per Jessen wrote:
Robert Cummings wrote:
I can't remember what sort of environment the OP was in, but if any
sort of organised testing is done, the use of two different APIs will
just about double the test-effort. Which is why I still think the
best
You use a session variable for that?
Why not?
That's entirely the wrong place to
store something like which database API is installed.
Not really. You could even wrap a function called (for example)
Feature() around it.
It should a class
variable or global configuration variable. Heck,
Richard Heyes wrote:
You use a session variable for that?
Why not?
Because it's not user data, it's server data.
That's entirely the wrong place to
store something like which database API is installed.
Not really. You could even wrap a function called (for example)
Feature() around it.
Stut wrote:
Richard Heyes wrote:
You use a session variable for that?
Why not?
Because it's not user data, it's server data.
That's entirely the wrong place to
store something like which database API is installed.
Not really. You could even wrap a function called (for example)
Stut wrote:
However, I'd expect a stat on that
file will be more expensive than calling extension_loaded.
Difficult to say, but a stat() is cheap, especially if the inode is
cached already.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit:
Because it's not user data, it's server data.
So? It's there - use it.
That's entirely the wrong place to
store something like which database API is installed.
Not really. You could even wrap a function called (for example)
Feature() around it.
Yeah, really. Sessions are for user data.
Richard Heyes wrote:
Because it's not user data, it's server data.
So? It's there - use it.
So are cookies, would you stuff this into a cookie? No, because that's
not what cookies are there for.
Because it's there is never a good reason to do something.
That's entirely the wrong place
On Tue, 2007-12-11 at 15:25 +, Stut wrote:
Richard Heyes wrote:
Because it's not user data, it's server data.
So? It's there - use it.
So are cookies, would you stuff this into a cookie? No, because that's
not what cookies are there for.
Because it's there is never a good
So? It's there - use it.
So are cookies, would you stuff this into a cookie? No, because that's
not what cookies are there for.
Not because it's not what cookies are for - but because sessions are a
more efficient and easier to use storage medium.
You could potentially be pointlessly
Sre, sessions are for whatever you choose to put in them. That's
like saying bodies are for whatever a crazed murderer chooses to put in
them...
No it's not.
the statement is true, but it's not optimal.
Real life is rarely optimal.
--
Richard Heyes
On Tue, 2007-12-11 at 16:31 +, Richard Heyes wrote:
Sre, sessions are for whatever you choose to put in them. That's
like saying bodies are for whatever a crazed murderer chooses to put in
them...
No it's not.
Yes it is. Neither is a good argument.
the statement is true,
Real life is rarely optimal.
That's not a valid excuse for taking the sloppy pig route to
development. Sloppy pig's give conscientious developers a bad name. And
when they use PHP to create their slop, they give PHP a bad name.
Well I err towards actually doing something useful. Businesses
Richard Heyes wrote:
Real life is rarely optimal.
That's not a valid excuse for taking the sloppy pig route to
development. Sloppy pig's give conscientious developers a bad name. And
when they use PHP to create their slop, they give PHP a bad name.
Well I err towards actually doing something
I don't see a reason to compromise. It would take no longer to call
extension_loaded on each page request than it will to put the variable
in the session. You're right in saying that there's a balance to be
struck, but in this particular case I personally see a right way and a
wrong way and no
Stut wrote:
I couldn't care less what your domain name is, you're still advocating
a poor choice IMHO.
I have been trying hard not to join this thread, but ... apart from the
principle, what's _really_ so poor about it? Having to write
application code that needs to work with two different
On Tue, 2007-12-11 at 17:01 +, Richard Heyes wrote:
Real life is rarely optimal.
That's not a valid excuse for taking the sloppy pig route to
development. Sloppy pig's give conscientious developers a bad name. And
when they use PHP to create their slop, they give PHP a bad name.
On Tue, 2007-12-11 at 18:14 +0100, Per Jessen wrote:
Stut wrote:
I couldn't care less what your domain name is, you're still advocating
a poor choice IMHO.
I have been trying hard not to join this thread, but ... apart from the
principle, what's _really_ so poor about it? Having to
On Tue, 2007-12-11 at 22:11 +0100, Per Jessen wrote:
Robert Cummings wrote:
On Tue, 2007-12-11 at 18:14 +0100, Per Jessen wrote:
I have been trying hard not to join this thread, but ... apart from
the principle, what's _really_ so poor about it? Having to write
application code that
On Dec 11, 2007 4:11 PM, Per Jessen [EMAIL PROTECTED] wrote:
I can't remember what sort of environment the OP was in, but if any sort
of organised testing is done, the use of two different APIs will just
about double the test-effort. Which is why I still think the best
option is to mandate
Robert Cummings wrote:
On Tue, 2007-12-11 at 18:14 +0100, Per Jessen wrote:
I have been trying hard not to join this thread, but ... apart from
the principle, what's _really_ so poor about it? Having to write
application code that needs to work with two different APIs is poor
enough, using
On Tuesday 11 December 2007, Per Jessen wrote:
Stut wrote:
I couldn't care less what your domain name is, you're still advocating
a poor choice IMHO.
I have been trying hard not to join this thread, but ... apart from the
principle, what's _really_ so poor about it? Having to write
PHP List,
Based on what seemed to be good advice to switch to using mysqli for
interacting with a MySQL database, I built a content management system
that uses mysqli for all it's calls.
It works great on a lot of my servers. However, I just discovered that
one web hosting service I use
Dave M G wrote:
One is based on the assumption that mysqli is as likely not to be
available as it is to be installed. In this case I should write my
scripts to test whether it exists and then use either mysqli or
straight mysql commands as appropriate. If this is the way to go, what
do I do
One is based on the assumption that mysqli is as likely not to be
available as it is to be installed. In this case I should write my
scripts to test whether it exists and then use either mysqli or straight
mysql commands as appropriate. If this is the way to go, what do I do to
test for the
-Original Message-
From: Per Jessen [mailto:[EMAIL PROTECTED]
Dave M G wrote:
One is based on the assumption that mysqli is as likely not to be
available as it is to be installed. In this case I should write my
scripts to test whether it exists and then use either mysqli or
Richard, Per, Andres,
Thank you for responding.
If it were entirely my web site to dictate what to do with, I would just
switch for a server that has mysqli available to me.
However, in this one case, the web site is owned by a small, not very
profitable group that has reasons to stay with
2007. 12. 10, hétfő keltezéssel 21.58-kor Dave M G ezt írta:
Richard, Per, Andres,
Thank you for responding.
If it were entirely my web site to dictate what to do with, I would just
switch for a server that has mysqli available to me.
However, in this one case, the web site is owned by
Dave M G wrote:
Richard said:
Alter your program to support both - use mysqi if it's avilable,
mysql if it's not.
How exactly do I test for the presence of mysqli from within a script?
Or are you saying I have two different versions of my script?
I think you can test for the
How exactly do I test for the presence of mysqli from within a script?
IIRC there's a function called extension_loaded(). Or something similar.
Or are you saying I have two different versions of my script?
Not at all. Taking PEAR::DB for example, you could test for the
existence of
Richard Heyes wrote:
another. This is one of the reasons abstraction layers exist.
Which brings us to alternative #3 - odbc.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Dec 10, 2007 3:16 AM, Dave M G [EMAIL PROTECTED] wrote:
Which assumption should I be proceeding with?
Rather than assume (because we all know what happens then), why
not build for both scenarios? Here's an example of one way
?
// inc/include_files.php
#
# Includes all files
Per Jessen wrote:
Richard Heyes wrote:
another. This is one of the reasons abstraction layers exist.
Which brings us to alternative #3 - odbc.
That's probably less likely to be available than mysqli. If you're
targetting php5 then you could use pdo::mysql as well (and there's even
the
On Monday 10 December 2007, Dave M G wrote:
One is based on the assumption that mysqli is as likely not to be
available as it is to be installed. In this case I should write my
scripts to test whether it exists and then use either mysqli or straight
mysql commands as appropriate. If this is
Zoltan, Per, Richard, Chris, Daniel, Larry,
Thank you for responding.
I have created a method in the class that handles my database
connections that will first test on extension_loaded(mysqli) before
connecting to the database.
Then I store the result in a session variable for reference, so
On Tue, 2007-12-11 at 13:02 +0900, Dave M G wrote:
Zoltan, Per, Richard, Chris, Daniel, Larry,
Thank you for responding.
I have created a method in the class that handles my database
connections that will first test on extension_loaded(mysqli) before
connecting to the database.
Then
37 matches
Mail list logo
