Re: [PHP] switch case - to require the break statements seems strange to me
On Sep 12, 2008, at 5:13 PM, Robert Cummings wrote: On Fri, 2008-09-12 at 16:51 -0400, Eric Gorr wrote: On Sep 12, 2008, at 4:27 PM, Robert Cummings wrote: On Fri, 2008-09-12 at 16:11 -0400, Eric Gorr wrote: On Sep 12, 2008, at 3:44 PM, Robert Cummings wrote: I don't see how that in any way makes an argument for or against. Once still must spend client's money wasting time on code that has questionable merit. Yes, some debugging code is a great boon in any application, but littered everywhere to fulfill someone's subjective philosophical ideal when sometimes it's just plain unnecessary... wasteful IMHO. As far as I know, no one has yet come up with a proof showing when debugging code is and/or is not necessary. The simple fact is that bugs can popup anywhere and spending a client's time and money by spending a few minutes writing all of the simple test cases throughout an application can be well worth it as it can save far more of the client's time and money by not wasting it on tracking down bugs that could have been easily caught. It is impractical to include debugging code for every conditional in a program. I have yet to see any evidence that it is impractical, especially after one has gotten into the habit. After all, for switch statements, adding in a default case takes mere seconds. Yes but if you do for case, you SHOULD do for if/else if/else which is an analagous approach. Doubly impractical to do so in PHP unless you have some way to prevent said debugging code from running in production. It isn't hard to prevent a code path from running in a production environment and allowing it to run in a development environment. Just one example, in PHP, would be globally defining something like PRODUCTION and then testing to see if it has a value of 1 or 0 and then writing an if statement to test the value before executing some code. There you go... you just ran a useless branch. Replacing one code path with another is hardly an optimial solution. What if your case statement is in a tight loop that runs a million times? How could that possibly matter since the code is never supposed to be executed to begin with and if it is executed it would immediately imply there is a bug? Furthermore, the whole point of these test cases is for those parts of the code which are never supposed to be executed to begin with, so that alone will aid in preventing said debugging code from executing in production...and if said debugging code does run in production, would that be such a bad thing (assuming it doesn't interfere with the user)? After all, because it (like the default switch case) was executed, it immediately implies there was a problem... If they're never supposed ot be executed then why are you adding extra code? That sounds like a need for better logic skills, not a need for debugging code. Because, it is never supposed to be ... not never will be. Bug's cause all kind of things to happen...including code paths that aren't supposed to happen. I doubt any client would believe it a good thing that a bug that should have been caught in development wasn't caught until production because mere minutes weren't spent putting in debug code that would have caught these bugs. Maybe you're confusing debugging code with unit tests. As I said earlier, it is far more practical to do so for complex conditions where a reader might easily get lost. Rather useless for simplistic cases. Until one finds it has saved hours because a problem was caught, I can understand why some would think that it is rather useless. I've spent hours on bugs before, they were never once related to not having put debugging fluff into a simple set of case statements. They were almost always related to lack of comments in a complex or hackish chunk of code. Great. I hope that continues. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] localization folder for web site
Hi, mostly (90%) websites are designed to include localization (made in php) folder like following: www.mywebsite.com/en/ www.mywebsite.com/de/ www.mywebsite.com/fr/ why do they not use only 1 folder and use dynamically PHP to change localization of website ? has this something to do with search engine rating ? thanks a lot, Al. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] localization folder for web site
Alain R. schreef: Hi, mostly (90%) websites are designed to include localization (made in php) folder like following: www.mywebsite.com/en/ www.mywebsite.com/de/ www.mywebsite.com/fr/ why do they not use only 1 folder and use dynamically PHP to change localization of website ? who says the 'folders' (directories) en, de, fr et al actually exist? has this something to do with search engine rating ? amongst other things, it's also a way of passing along the requested translation with requiring cookies thanks a lot, Al. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] switch case - to require the break statements seems strange to me
On Sat, 2008-09-13 at 10:09 -0400, Eric Gorr wrote: On Sep 12, 2008, at 5:13 PM, Robert Cummings wrote: On Fri, 2008-09-12 at 16:51 -0400, Eric Gorr wrote: On Sep 12, 2008, at 4:27 PM, Robert Cummings wrote: On Fri, 2008-09-12 at 16:11 -0400, Eric Gorr wrote: On Sep 12, 2008, at 3:44 PM, Robert Cummings wrote: I don't see how that in any way makes an argument for or against. Once still must spend client's money wasting time on code that has questionable merit. Yes, some debugging code is a great boon in any application, but littered everywhere to fulfill someone's subjective philosophical ideal when sometimes it's just plain unnecessary... wasteful IMHO. As far as I know, no one has yet come up with a proof showing when debugging code is and/or is not necessary. The simple fact is that bugs can popup anywhere and spending a client's time and money by spending a few minutes writing all of the simple test cases throughout an application can be well worth it as it can save far more of the client's time and money by not wasting it on tracking down bugs that could have been easily caught. It is impractical to include debugging code for every conditional in a program. I have yet to see any evidence that it is impractical, especially after one has gotten into the habit. After all, for switch statements, adding in a default case takes mere seconds. Yes but if you do for case, you SHOULD do for if/else if/else which is an analagous approach. Doubly impractical to do so in PHP unless you have some way to prevent said debugging code from running in production. It isn't hard to prevent a code path from running in a production environment and allowing it to run in a development environment. Just one example, in PHP, would be globally defining something like PRODUCTION and then testing to see if it has a value of 1 or 0 and then writing an if statement to test the value before executing some code. There you go... you just ran a useless branch. Replacing one code path with another is hardly an optimial solution. What if your case statement is in a tight loop that runs a million times? How could that possibly matter since the code is never supposed to be executed to begin with and if it is executed it would immediately imply there is a bug? This discussion started because you said put a default statement in for debugging purposes rather than leave it empty. This suggests that you have a finite number of case statements that handle a specific set of values and that there may be values that don't need handling. Since they don't need handling the optimal path is not to have a default statement, but you suggest adding one with debugging information even though no processing need occur for some values. Now do you understand? Just because you have a switch doesn't mean all values need handling. Furthermore, the whole point of these test cases is for those parts of the code which are never supposed to be executed to begin with, so that alone will aid in preventing said debugging code from executing in production...and if said debugging code does run in production, would that be such a bad thing (assuming it doesn't interfere with the user)? After all, because it (like the default switch case) was executed, it immediately implies there was a problem... If they're never supposed ot be executed then why are you adding extra code? That sounds like a need for better logic skills, not a need for debugging code. Because, it is never supposed to be ... not never will be. Bug's cause all kind of things to happen...including code paths that aren't supposed to happen. I doubt any client would believe it a good thing that a bug that should have been caught in development wasn't caught until production because mere minutes weren't spent putting in debug code that would have caught these bugs. You're probably one of those people that comments incrementing an index *shrug*. I mean it's mere seconds to add a useless chunk of comments that may someday help someone understand you're incrementing $i. Similarly, for simplistic case statements, there's virtually no need for a block of debug code. Maybe you're confusing debugging code with unit tests. As I said earlier, it is far more practical to do so for complex conditions where a reader might easily get lost. Rather useless for simplistic cases. Until one finds it has saved hours because a problem was caught, I can understand why some would think that it is rather useless. I've spent hours on bugs before, they were never once related to not having put debugging fluff into a simple set of case statements. They were almost always related to lack of comments in a complex or hackish chunk of code. Great. I hope that continues. I'm sure it will. Cheers, Rob. --
Re: [PHP] localization folder for web site
so how can i do the same ? i mean to have 1 single PHP page and to localize, but to have the URI with /en, or /fr or /de ? i know how to localize the complete website i already done it, but what you told ? One would hope that unless it's a pretty small static site those folders actually map to the same place and generate pages in the required language. The reason it's in the URI and not URI agnostic is indeed so that search engines can index multiple languages if they want to. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] localization folder for web site
how can i do the same ? Jochem Maas wrote: Alain R. schreef: Hi, mostly (90%) websites are designed to include localization (made in php) folder like following: www.mywebsite.com/en/ www.mywebsite.com/de/ www.mywebsite.com/fr/ why do they not use only 1 folder and use dynamically PHP to change localization of website ? who says the 'folders' (directories) en, de, fr et al actually exist? has this something to do with search engine rating ? amongst other things, it's also a way of passing along the requested translation with requiring cookies thanks a lot, Al. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] localization folder for web site
Alain R. wrote: so how can i do the same ? i mean to have 1 single PHP page and to localize, but to have the URI with /en, or /fr or /de ? i know how to localize the complete website i already done it, but what you told ? One would hope that unless it's a pretty small static site those folders actually map to the same place and generate pages in the required language. The reason it's in the URI and not URI agnostic is indeed so that search engines can index multiple languages if they want to. -Stut 1. don't top-post please 2. google apache mod_rewrite, that way you can rewrite urls of the form www.example.org/de/whatever to www.example.org/whatever?lang=de or even stick the de part into an environment variable $_ENV['lang'] = 'de' - Tul -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] check if a file is included
Please stop top-posting. Lest you be smitten with a vengeance reserved only for top-posters. A nasty one. :-) -- Richard Heyes HTML5 Graphing for IE7, FF, Chrome, Opera and Safari: http://www.phpguru.org/RGraph -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] localization folder for web site
Maciek Sokolewicz wrote: 2. google apache mod_rewrite, that way you can rewrite urls of the form www.example.org/de/whatever to www.example.org/whatever?lang=de or even stick the de part into an environment variable $_ENV['lang'] = 'de' - Tul the mod_rewrite is possible only if i own/manage the apache server but i my case, i have a provider for that so it is not possible. can you explain a little bit more the $_ENV purpose ? because for me it's like a simple session variable nothing more. how do you use it ? i mean the concept... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] localization folder for web site
Alain R. wrote: Maciek Sokolewicz wrote: 2. google apache mod_rewrite, that way you can rewrite urls of the form www.example.org/de/whatever to www.example.org/whatever?lang=de or even stick the de part into an environment variable $_ENV['lang'] = 'de' - Tul the mod_rewrite is possible only if i own/manage the apache server but i my case, i have a provider for that so it is not possible. can you explain a little bit more the $_ENV purpose ? because for me it's like a simple session variable nothing more. how do you use it ? i mean the concept... the concept is that you use mod_rewrite for apache (also works in litespeed httpd btw). using mod_rewrite you rewrite the request from www.example.com/fr/index.php to www.example.com/index.php and part of that is that it also sets the environment variable _ENV[lang] to 'fr' for example. Please look up the documentation for mod_rewrite if you want more info. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] check if a file is included
On Sat, Sep 13, 2008 at 2:16 PM, Richard Heyes [EMAIL PROTECTED] wrote: Please stop top-posting. Lest you be smitten with a vengeance reserved only for top-posters. A nasty one. :-) -- Richard Heyes HTML5 Graphing for IE7, FF, Chrome, Opera and Safari: http://www.phpguru.org/RGraph It had to be done! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php image and javascript include
On Saturday 13 September 2008 01:34:41 Ashley Sheridan wrote: I've never been a huge fan of Vi or Vim, but I am a fan of coding in a text editor, not a GUI, I just guess I prefer Kate. I know for certain that one thing that really bugs me about Dreamweaver is the fact that it has a tendency to really nerf up the spacing, and it replaces tabs with spaces more often than not. It's all about the tabs to space things out, adding spaces just makes the files bigger! Oh, thats just how you set up DW, options on indentations is througoutly documented inside the preferences pane and quite a few options to go, only thing that is wrong with it is the way it can't handle large projects, say like more than 100 files. nevermind the filesize... Ash www.ashleysheridan.co.uk -- --- Børge Holen http://www.arivene.net -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php image and javascript include
On Sat, 2008-09-13 at 23:24 +0200, Børge Holen wrote: On Saturday 13 September 2008 01:34:41 Ashley Sheridan wrote: I've never been a huge fan of Vi or Vim, but I am a fan of coding in a text editor, not a GUI, I just guess I prefer Kate. I know for certain that one thing that really bugs me about Dreamweaver is the fact that it has a tendency to really nerf up the spacing, and it replaces tabs with spaces more often than not. It's all about the tabs to space things out, adding spaces just makes the files bigger! Oh, thats just how you set up DW, options on indentations is througoutly documented inside the preferences pane and quite a few options to go, only thing that is wrong with it is the way it can't handle large projects, say like more than 100 files. nevermind the filesize... Ash www.ashleysheridan.co.uk -- --- Børge Holen http://www.arivene.net I've worked on projects like that before, but never considered DW, I used Notepad++ instead, as I was forced to use Windows at work at the time. I never really had any reason to try to open all the files at once though... ;) Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] 2 Questions.
Can anybody give me any good reasons not to use a time stamp as an order number in my shopping cart. It seems to me that the number is guaranteed to be random and it saves having to make an extra time column to keep track of the order. The only small concern I have is the chance that somebody orders at the exact same time as somebody else but the chance of that has got to be incredibly small but possible. My second question is I've designed a very simple Postgres database wrapper. The methods are exactly what you would assume to see in any db wrapper a pg_query, pg_fetch_array. My question is in the db wrapper, is there an easy way to always include the table name as an index in all my pg_fetch_array returned results? The reason I ask is when designing my tables I'm delegated to prefixing my column names i.e. users_name instead of just name or forum_posts instead of just posts to make sure there's no collision. Cheers Thomas Shaw [EMAIL PROTECTED]
Re: [PHP] 2 Questions.
On Sat, 2008-09-13 at 17:38 -0500, Tom Shaw wrote: Can anybody give me any good reasons not to use a time stamp as an order number in my shopping cart. It seems to me that the number is guaranteed to be random and it saves having to make an extra time column to keep track of the order. The only small concern I have is the chance that somebody orders at the exact same time as somebody else but the chance of that has got to be incredibly small but possible. My second question is I've designed a very simple Postgres database wrapper. The methods are exactly what you would assume to see in any db wrapper a pg_query, pg_fetch_array. My question is in the db wrapper, is there an easy way to always include the table name as an index in all my pg_fetch_array returned results? The reason I ask is when designing my tables I'm delegated to prefixing my column names i.e. users_name instead of just name or forum_posts instead of just posts to make sure there's no collision. Cheers Thomas Shaw [EMAIL PROTECTED] Well, I think you answered the first part of your question yourself there! Although remotely small, it is entirely possible for two people to do something at the same time on your site. Why don't you use an auto_increment column in your table instead? There are plenty of functions in PHP to retrieve the auto_insert value (although generally different for each type of database you connect to, I only know how to do it in MySQL and MSSQL) This way, you let the database deal with the unique ID's as it's something the databases are very suited to, and you can then use the auto_insert ID in place of the value you would normally generate in PHP. Ash www.ashleysheridan.co.uk
Re: [PHP] 2 Questions.
Tom Shaw schreef:
Can anybody give me any good reasons not to use a time stamp as an order
number in my shopping cart. It seems to me that the number is guaranteed to
be random and it saves having to make an extra time column to keep track of
the order. The only small concern I have is the chance that somebody orders
at the exact same time as somebody else but the chance of that has got to be
incredibly small but possible.
1. order number are often *required* (for accounting purposes) to be consecutive
2. the chance is small, yet it is there ... agravated by the fact that most
orders
are placed during a concentrated period of the day.
I have no idea what you mean by 'extra time column' and/or using it to keep
track of an order... but most DBMSs have the ability to auto store a timestamp
into a field when the given record is created.
oh ... timestamps are hardly random.
My second question is I've designed a very simple Postgres database wrapper.
The methods are exactly what you would assume to see in any db wrapper a
pg_query, pg_fetch_array. My question is in the db wrapper, is there an easy
way to always include the table name as an index in all my pg_fetch_array
returned results? The reason I ask is when designing my tables I'm delegated
to prefixing my column names i.e. users_name instead of just name or
forum_posts instead of just posts to make sure there's no collision.
have your simple wrapper do something like:
$sql = SELECT foo AS {$tablename}_foo FROM {$tablename} WHERE 1;
with regard to generating the query. if your wrapper doesn't generate the
SQL then you'll have to parse the given SQL and rewrite it ... good luck with
that.
Cheers
Thomas Shaw
[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] 2 Questions.
I should have mentioned that I use a *normalized* database wharehousing
pattern where each row represents a distinct item being purchased. There
could be fifty rows corresponding to a single order transaction like what
you would see in something like an itunes music purchase. So using the auto
increment id would not work to differentiate between orders. Another user
mentioned microtime.
-Original Message-
From: Jochem Maas [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 13, 2008 6:06 PM
To: Tom Shaw
Cc: 'PHP General'
Subject: Re: [PHP] 2 Questions.
Tom Shaw schreef:
Can anybody give me any good reasons not to use a time stamp as an order
number in my shopping cart. It seems to me that the number is guaranteed
to
be random and it saves having to make an extra time column to keep track
of
the order. The only small concern I have is the chance that somebody
orders
at the exact same time as somebody else but the chance of that has got to
be
incredibly small but possible.
1. order number are often *required* (for accounting purposes) to be
consecutive
2. the chance is small, yet it is there ... agravated by the fact that most
orders
are placed during a concentrated period of the day.
I have no idea what you mean by 'extra time column' and/or using it to keep
track of an order... but most DBMSs have the ability to auto store a
timestamp
into a field when the given record is created.
oh ... timestamps are hardly random.
My second question is I've designed a very simple Postgres database
wrapper.
The methods are exactly what you would assume to see in any db wrapper a
pg_query, pg_fetch_array. My question is in the db wrapper, is there an
easy
way to always include the table name as an index in all my pg_fetch_array
returned results? The reason I ask is when designing my tables I'm
delegated
to prefixing my column names i.e. users_name instead of just name or
forum_posts instead of just posts to make sure there's no collision.
have your simple wrapper do something like:
$sql = SELECT foo AS {$tablename}_foo FROM {$tablename} WHERE 1;
with regard to generating the query. if your wrapper doesn't generate the
SQL then you'll have to parse the given SQL and rewrite it ... good luck
with that.
Cheers
Thomas Shaw
[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] 2 Questions.
At 5:38 PM -0500 9/13/08, Tom Shaw wrote: Can anybody give me any good reasons not to use a time stamp as an order number in my shopping cart. It seems to me that the number is guaranteed to be random and it saves having to make an extra time column to keep track of the order. The only small concern I have is the chance that somebody orders at the exact same time as somebody else but the chance of that has got to be incredibly small but possible. opinion based upon experience While time stamp is usually unique, it isn't always -- don't assume it will be unique. An order number should be a unique auto increment id (i.e., sequential) in your table. It should be representative of the customer's order -- it should contain the customer id; shipping/billing address; what the customer ordered (all items ordered); the time-date of the transaction; authorization code provided by the clearing house; and payment amount -- and basically nothing else (i.e., No credit card information). While you might think an order number should be something else, keep in mind that an order is simply an order. It is a point in time where a customer has agreed to purchase something and you have accepted and have cleared that purchase for that payment through some sort of purchasing scheme. It makes no difference if your dB is normalized, or relational, or some stock-boy working in a warehouse, or a phone order operator pressing an Done button. It is simply an order number. While you might think a microtime stamp would work, a unique auto increment id will work better. /opinion based upon experience My second question is I've designed a very simple Postgres database wrapper. The methods are exactly what you would assume to see in any db wrapper a pg_query, pg_fetch_array. My question is in the db wrapper, is there an easy way to always include the table name as an index in all my pg_fetch_array returned results? The reason I ask is when designing my tables I'm delegated to prefixing my column names i.e. users_name instead of just name or forum_posts instead of just posts to make sure there's no collision. I'm not sure if I understand your question, but I'll try to answer what I think you are asking. Regardless of the dB, I find it best to have a configuration file that contains and defines all the variables re the dB (i.e., db_name, db_user, db_password, db_tablewhatever, and so on). That way, all you have to do is to include that file in your scripts. If you want to change something, you can change it in just one file. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] 2 Questions.
On Sat, Sep 13, 2008 at 8:14 PM, tedd [EMAIL PROTECTED] wrote: While you might think an order number should be something else, keep in mind that an order is simply an order. It is a point in time where a customer has agreed to purchase something and you have accepted and have cleared that purchase for that payment through some sort of purchasing scheme. One of the best schemes for developing a unique order number that is not only unique to the system, but is also readily human-readable would be to use an auto_increment value appended to a date string. For example: ?php $today = date(Ymd); $increment = $numberFromDB; // This routine would depend on your database (MySQL, PostgreSQL, etc.) $orderNumber = $today.-.$increment; ? From the above, you'd get an order number similar to 20080913-1048. This means that it's not only unique, regardless of how many orders come through in the same second, but ordering by time and date is easier, and on paper, you can easily tell when an order was placed. -- /Daniel P. Brown More full-root dedicated server packages: Intel 2.4GHz/60GB/512MB/2TB $49.99/mo. Intel 3.06GHz/80GB/1GB/2TB $59.99/mo. Intel 2.4GHz/320/GB/1GB/3TB $74.99/mo. Dedicated servers, VPS, and hosting from $2.50/mo. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] 2 Questions.
At 8:26 PM -0400 9/13/08, Daniel Brown wrote: On Sat, Sep 13, 2008 at 8:14 PM, tedd [EMAIL PROTECTED] wrote: While you might think an order number should be something else, keep in mind that an order is simply an order. It is a point in time where a customer has agreed to purchase something and you have accepted and have cleared that purchase for that payment through some sort of purchasing scheme. One of the best schemes for developing a unique order number that is not only unique to the system, but is also readily human-readable would be to use an auto_increment value appended to a date string. For example: ?php $today = date(Ymd); $increment = $numberFromDB; // This routine would depend on your database (MySQL, PostgreSQL, etc.) $orderNumber = $today.-.$increment; ? From the above, you'd get an order number similar to 20080913-1048. This means that it's not only unique, regardless of how many orders come through in the same second, but ordering by time and date is easier, and on paper, you can easily tell when an order was placed. Nice to see you back my friend -- I was worried. An auto-increment field in a table is unique. While it doesn't include any time/date information, it is automatically assigned when the transaction is confirmed (i.e., INSERT). I've used both, but usually when I need a time/date stamp, I add that somewhere else in the table. However, these are just differences in style and not that one is better than the other. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] 2 Questions.
Tom Shaw schreef:
I should have mentioned that I use a *normalized* database wharehousing
pattern where each row represents a distinct item being purchased. There
could be fifty rows corresponding to a single order transaction like what
you would see in something like an itunes music purchase. So using the auto
increment id would not work to differentiate between orders. Another user
mentioned microtime.
whoa, race car hey? let's have a race.
normalized smormalized. every order related system I've looked at, built or
worked with made a clear distinction between an **order** and an **orderline**,
all you seem to have is an order line ... who do they belong to? are you
replicating the customer details and shipping address in each row? (if so
I hardly call that normalized)
use generators or sequences or 'auto increment ids' or whatever your DB calls
it, dump the timestamp/microtime nonsense, and rework you DB schema to
incorporate order **and** orderline entities ... and use a required foreign key
in each orderline to reference the relevant order.
with regard to iTunes store, steve jobs can go shove it ... but I'll wadger
my soul that the guys that built it know the difference between an order
and an order line and that they use both concepts.
-Original Message-
From: Jochem Maas [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 13, 2008 6:06 PM
To: Tom Shaw
Cc: 'PHP General'
Subject: Re: [PHP] 2 Questions.
Tom Shaw schreef:
Can anybody give me any good reasons not to use a time stamp as an order
number in my shopping cart. It seems to me that the number is guaranteed
to
be random and it saves having to make an extra time column to keep track
of
the order. The only small concern I have is the chance that somebody
orders
at the exact same time as somebody else but the chance of that has got to
be
incredibly small but possible.
1. order number are often *required* (for accounting purposes) to be
consecutive
2. the chance is small, yet it is there ... agravated by the fact that most
orders
are placed during a concentrated period of the day.
I have no idea what you mean by 'extra time column' and/or using it to keep
track of an order... but most DBMSs have the ability to auto store a
timestamp
into a field when the given record is created.
oh ... timestamps are hardly random.
My second question is I've designed a very simple Postgres database
wrapper.
The methods are exactly what you would assume to see in any db wrapper a
pg_query, pg_fetch_array. My question is in the db wrapper, is there an
easy
way to always include the table name as an index in all my pg_fetch_array
returned results? The reason I ask is when designing my tables I'm
delegated
to prefixing my column names i.e. users_name instead of just name or
forum_posts instead of just posts to make sure there's no collision.
have your simple wrapper do something like:
$sql = SELECT foo AS {$tablename}_foo FROM {$tablename} WHERE 1;
with regard to generating the query. if your wrapper doesn't generate the
SQL then you'll have to parse the given SQL and rewrite it ... good luck
with that.
Cheers
Thomas Shaw
[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] switch case - to require the break statements seems strange to me
On Sep 13, 2008, at 12:12 PM, Robert Cummings wrote: On Sat, 2008-09-13 at 10:09 -0400, Eric Gorr wrote: On Sep 12, 2008, at 5:13 PM, Robert Cummings wrote: On Fri, 2008-09-12 at 16:51 -0400, Eric Gorr wrote: On Sep 12, 2008, at 4:27 PM, Robert Cummings wrote: On Fri, 2008-09-12 at 16:11 -0400, Eric Gorr wrote: On Sep 12, 2008, at 3:44 PM, Robert Cummings wrote: I don't see how that in any way makes an argument for or against. Once still must spend client's money wasting time on code that has questionable merit. Yes, some debugging code is a great boon in any application, but littered everywhere to fulfill someone's subjective philosophical ideal when sometimes it's just plain unnecessary... wasteful IMHO. As far as I know, no one has yet come up with a proof showing when debugging code is and/or is not necessary. The simple fact is that bugs can popup anywhere and spending a client's time and money by spending a few minutes writing all of the simple test cases throughout an application can be well worth it as it can save far more of the client's time and money by not wasting it on tracking down bugs that could have been easily caught. It is impractical to include debugging code for every conditional in a program. I have yet to see any evidence that it is impractical, especially after one has gotten into the habit. After all, for switch statements, adding in a default case takes mere seconds. Yes but if you do for case, you SHOULD do for if/else if/else which is an analagous approach. Doubly impractical to do so in PHP unless you have some way to prevent said debugging code from running in production. It isn't hard to prevent a code path from running in a production environment and allowing it to run in a development environment. Just one example, in PHP, would be globally defining something like PRODUCTION and then testing to see if it has a value of 1 or 0 and then writing an if statement to test the value before executing some code. There you go... you just ran a useless branch. Replacing one code path with another is hardly an optimial solution. What if your case statement is in a tight loop that runs a million times? How could that possibly matter since the code is never supposed to be executed to begin with and if it is executed it would immediately imply there is a bug? This discussion started because you said put a default statement in for debugging purposes rather than leave it empty. This suggests that you have a finite number of case statements that handle a specific set of values and that there may be values that don't need handling. Since they don't need handling the optimal path is not to have a default statement, but you suggest adding one with debugging information even though no processing need occur for some values. Now do you understand? Just because you have a switch doesn't mean all values need handling. Ah, while I had expected that my initial comments had been misinterpreted, I can see clearly now that they have. Hopefully, the messages the past couple of days have cleared things up. Furthermore, the whole point of these test cases is for those parts of the code which are never supposed to be executed to begin with, so that alone will aid in preventing said debugging code from executing in production...and if said debugging code does run in production, would that be such a bad thing (assuming it doesn't interfere with the user)? After all, because it (like the default switch case) was executed, it immediately implies there was a problem... If they're never supposed ot be executed then why are you adding extra code? That sounds like a need for better logic skills, not a need for debugging code. Because, it is never supposed to be ... not never will be. Bug's cause all kind of things to happen...including code paths that aren't supposed to happen. I doubt any client would believe it a good thing that a bug that should have been caught in development wasn't caught until production because mere minutes weren't spent putting in debug code that would have caught these bugs. You're probably one of those people that comments incrementing an index *shrug*. I mean it's mere seconds to add a useless chunk of comments that may someday help someone understand you're incrementing $i. While there is certainly a time and a place for comments which answer the questions of 'How?' or 'What?', the most useful comments nearly always answer the question of 'why?'. Why? The questions of 'How?' or 'What?' can almost always be easily determined with an analysis of the code. However, such an analysis does not always lead to understanding why code was written in the way it was written and I would strongly recommend people adopt such a comment style. Oh, for those using SCM (Source Code Management - like subversion), this policy applies to the checkin comments as well. Answering the question of
RE: [PHP] 2 Questions.
-Original Message-
From: Tom Shaw [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 13, 2008 9:52 PM
To: 'Jochem Maas'
Subject: RE: [PHP] 2 Questions.
iamjochem wrote:
My second question is I've designed a very simple Postgres database
wrapper.
The methods are exactly what you would assume to see in any db wrapper a
pg_query, pg_fetch_array. My question is in the db wrapper, is there an
easy
way to always include the table name as an index in all my pg_fetch_array
returned results? The reason I ask is when designing my tables I'm
delegated
to prefixing my column names i.e. users_name instead of just name or
forum_posts instead of just posts to make sure there's no collision.
have your simple wrapper do something like:
$sql = SELECT foo AS {$tablename}_foo FROM {$tablename} WHERE 1;
with regard to generating the query. if your wrapper doesn't generate the
SQL then you'll have to parse the given SQL and rewrite it ... good luck
with that.
I'm not sure if my wrapper is a good place for the sql but I bet it's worth
investigating further. I like the web site iamjokem. Im not sure if that's a
jokem too but I couldn't figure it out...
-Original Message-
From: Jochem Maas [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 13, 2008 8:35 PM
To: Tom Shaw
Cc: 'PHP General'
Subject: Re: [PHP] 2 Questions.
Tom Shaw schreef:
I should have mentioned that I use a *normalized* database wharehousing
pattern where each row represents a distinct item being purchased. There
could be fifty rows corresponding to a single order transaction like what
you would see in something like an itunes music purchase. So using the
auto
increment id would not work to differentiate between orders. Another user
mentioned microtime.
whoa, race car hey? let's have a race.
normalized smormalized. every order related system I've looked at, built or
worked with made a clear distinction between an **order** and an
**orderline**,
all you seem to have is an order line ... who do they belong to? are you
replicating the customer details and shipping address in each row? (if so
I hardly call that normalized)
use generators or sequences or 'auto increment ids' or whatever your DB
calls
it, dump the timestamp/microtime nonsense, and rework you DB schema to
incorporate order **and** orderline entities ... and use a required foreign
key
in each orderline to reference the relevant order.
with regard to iTunes store, steve jobs can go shove it ... but I'll wadger
my soul that the guys that built it know the difference between an order
and an order line and that they use both concepts.
-Original Message-
From: Jochem Maas [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 13, 2008 6:06 PM
To: Tom Shaw
Cc: 'PHP General'
Subject: Re: [PHP] 2 Questions.
Tom Shaw schreef:
Can anybody give me any good reasons not to use a time stamp as an order
number in my shopping cart. It seems to me that the number is guaranteed
to
be random and it saves having to make an extra time column to keep track
of
the order. The only small concern I have is the chance that somebody
orders
at the exact same time as somebody else but the chance of that has got to
be
incredibly small but possible.
1. order number are often *required* (for accounting purposes) to be
consecutive
2. the chance is small, yet it is there ... agravated by the fact that
most
orders
are placed during a concentrated period of the day.
I have no idea what you mean by 'extra time column' and/or using it to
keep
track of an order... but most DBMSs have the ability to auto store a
timestamp
into a field when the given record is created.
oh ... timestamps are hardly random.
My second question is I've designed a very simple Postgres database
wrapper.
The methods are exactly what you would assume to see in any db wrapper a
pg_query, pg_fetch_array. My question is in the db wrapper, is there an
easy
way to always include the table name as an index in all my pg_fetch_array
returned results? The reason I ask is when designing my tables I'm
delegated
to prefixing my column names i.e. users_name instead of just name or
forum_posts instead of just posts to make sure there's no collision.
have your simple wrapper do something like:
$sql = SELECT foo AS {$tablename}_foo FROM {$tablename} WHERE 1;
with regard to generating the query. if your wrapper doesn't generate the
SQL then you'll have to parse the given SQL and rewrite it ... good luck
with that.
Cheers
Thomas Shaw
[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] php image and javascript include
I'm a big fan of Zend Studio 5. It's pretty hard to beat considering how fast you can code load up the page refresh, and the editor itself is very clean plus it works in linux. I know a lot of people like to soft tab but I just don’t have the patience. Hard tabs all the way for me. Tom Shaw [EMAIL PROTECTED] -Original Message- From: Ashley Sheridan [mailto:[EMAIL PROTECTED] Sent: Saturday, September 13, 2008 4:36 PM To: Børge Holen Cc: php-general@lists.php.net Subject: Re: [PHP] php image and javascript include On Sat, 2008-09-13 at 23:24 +0200, Børge Holen wrote: On Saturday 13 September 2008 01:34:41 Ashley Sheridan wrote: I've never been a huge fan of Vi or Vim, but I am a fan of coding in a text editor, not a GUI, I just guess I prefer Kate. I know for certain that one thing that really bugs me about Dreamweaver is the fact that it has a tendency to really nerf up the spacing, and it replaces tabs with spaces more often than not. It's all about the tabs to space things out, adding spaces just makes the files bigger! Oh, thats just how you set up DW, options on indentations is througoutly documented inside the preferences pane and quite a few options to go, only thing that is wrong with it is the way it can't handle large projects, say like more than 100 files. nevermind the filesize... Ash www.ashleysheridan.co.uk -- --- Børge Holen http://www.arivene.net I've worked on projects like that before, but never considered DW, I used Notepad++ instead, as I was forced to use Windows at work at the time. I never really had any reason to try to open all the files at once though... ;) Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Browser could not get mp3 files from http site
Thanks Dan and Ash. I've tried object tag, it crashed my firefox. The audio.php file generates a simple following html. You need media player plugin to test it. The web server http://www.myweb.com/audio.php is my home server. Let me further discribe the problems, it is not the embed tag problem, it is the source in the embed tag does not download to the browser (In fact, I've tried the object tag as Ash suggested, the object tag crashed firefox): (1) If I open following audio.html directly from Open File file:///home/webserver/audio.html, the embed tag works just fine, the audio can play. The /home/webserver is the directory where all applications audio.php and audio.mp3 are stored. (2) If I open from http://www.myweb.com/audio.php, the audio.mp3 does not download to firefox. Nothing is played. html embed src=audio.mp3 autostart=1/embed /html Thanks. Jim On 9/13/08, Ashley Sheridan [EMAIL PROTECTED] wrote: As far as I'm aware, the embed tag is not supported in any HTML standard, and as such, it's a little hit and miss. Depending on what you want to achieve, you should look towards the object tag instead: http://joliclic.free.fr/html/object-tag/en/ Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
