[PHP] non-woven bags, shopping bags, eco-friendly bags
Hey there, We are the manufacturer of the non-woven bags and other eco-friendly bags in China, can print your logo and your own design of pictures on the bag, good choice for promotional gifts and advertisement! Advantages to imported directly from us: 1. Directly factory, cut out the middle man which can provide you good price and good quality. 2. Professional designer can design the exact product you like; good with OEM orders can copy most of the bags you need. 3. Varies of style of the designs can meet your customize requirement. 4. Timely delivery, and well communicated! For any inquiry please responde to my mail: E-mail: sa...@bagstalk.com Thanks & best regards Andrew Huang Blue Eyes Industry Tel No.: 86-592-2055232 Fax No.: 86-592-2055232 E-mail: sa...@bagstalk.com MSN: anderu1...@hotmail.com Site: www.bagstalk.com
Re: [PHP] Debugging Help Needed
On 13 April 2011 03:06, Paul M Foster wrote: > On Tue, Apr 12, 2011 at 03:37:26PM -0700, Rich Shepard wrote: > >> On Tue, 12 Apr 2011, Daniel Brown wrote: >> >> > You missed the ending semicolon, that's all. >> >> Daniel, >> >> Oops! Too long since C and Python doesn't use semicolons. > > Wait, what?! Did they change C? When did this happen?! ;-} > > Paul Oh they did a while ago. Didn't you read the memo? -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Online tests for php
Hi, I am trying to hire some php developers for a local taks and I need to somehow perform a triage. One of the aspects is the knowledge of PHP itself so I was wondering if there is any set of questions (multiple choice) to try to do that. I am not looking for a certification level in those tests but a way to at least know what this guy knows.
Re: [PHP] Debugging Help Needed
On Tue, Apr 12, 2011 at 22:06, Paul M Foster wrote: > > Wait, what?! Did they change C? When did this happen?! ;-} I believe he meant that it's been too long since he used C (which uses semicolons) and that Python, which he used more recently, doesn't use semicolons (which always trips me up whenever I have to patch Python code). -- Network Infrastructure Manager http://www.php.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Online tests for php
On Wed, 2011-04-13 at 09:08 -0400, robert mena wrote: > Hi, > > I am trying to hire some php developers for a local taks and I need to > somehow perform a triage. One of the aspects is the knowledge of PHP itself > so I was wondering if there is any set of questions (multiple choice) to try > to do that. > > I am not looking for a certification level in those tests but a way to at > least know what this guy knows. I am not a regular poster here but I do watch posts. My suggestion is taking your time and learning php/mysql is your only way I suppose. Else be ready to get cheated. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Online tests for php
--- On Wed, 4/13/11, robert mena wrote: > From: robert mena > Subject: [PHP] Online tests for php > To: "php-general" > Date: Wednesday, April 13, 2011, 6:38 PM > Hi, > > I am trying to hire some php developers for a local taks > and I need to > somehow perform a triage. One of the aspects is the > knowledge of PHP itself > so I was wondering if there is any set of questions > (multiple choice) to try > to do that. > > I am not looking for a certification level in those > tests but a way to at > least know what this guy knows. > I think the best method is, ask the developers to do some small projects; like.. 1) login page 2) user creation 3) sending email 4) file upload And after completion just check that the projects are running properly or not. --- নির্মাল্য লাহিড়ী [Nirmalya Lahiri] +৯১-৯৪৩৩১১৩৫৩৬ [+91-9433113536] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Debugging Help Needed
On Wed, 13 Apr 2011, Daniel Brown wrote: I believe he meant that it's been too long since he used C (which uses semicolons) and that Python, which he used more recently, doesn't use semicolons (which always trips me up whenever I have to patch Python code). Thank you, Daniel. Inserting a call to debug_print_traceback() (with a terminating semi-colon) at the top of the ErrorHandler404() function produces no visible output (and nothing in the application directory or in ~/). Will someone suggest either how I properly use debug_print_traceback() or otherwise learn what's failing as I try to invoke the application and transferring control to the error handler? There has to be something either in the index.php, or a function it's calling, that cannot find the opening display. I need to learn what's happening so I can get this application running here. Rich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Class Constants
I'm doing some testing from the command line and would like to be able = to pass along a constant from a class. For example: php emailTest.,php OrderConfirmation OrderConfirmation is a constant in a class. Is there any way I can take = the value passed on the command line and have PHP figure out which = constant is equals? Thanks! Floyd -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Class Constants
On 13 April 2011 17:45, Floyd Resler wrote: > I'm doing some testing from the command line and would like to be able = > to pass along a constant from a class. For example: > php emailTest.,php OrderConfirmation > > OrderConfirmation is a constant in a class. Is there any way I can take = > the value passed on the command line and have PHP figure out which = > constant is equals? > > Thanks! > Floyd In your script ... Once you've got the value, you can ... $s_ConstantValue = className::$s_ConstantNameFromCommandLine; sort of thing. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] $_POST vars
Can one create a set of $_POST vars within a script or is that not do-able? My display portion of my script utilizes the POST array to supply values to my input screen - this works well for the first display of an empty screen, and any following re-displays if there's an error in the user's input. But I want to use this same script/screen to display the results of a query when the user wants to update an existing record. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
On Wednesday, 13 April 2011 at 18:49, Jim Giner wrote: Can one create a set of $_POST vars within a script or is that not do-able? > My display portion of my script utilizes the POST array to supply values to > my input screen - this works well for the first display of an empty screen, > and any following re-displays if there's an error in the user's input. But > I want to use this same script/screen to display the results of a query when > the user wants to update an existing record. $_POST is a standard PHP array, with the only added feature being that it's available everywhere (i.e. it's a superglobal). There is nothing stopping you modifying that array from anywhere within your code. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
On Wed, Apr 13, 2011 at 1:49 PM, Jim Giner wrote: > Can one create a set of $_POST vars within a script or is that not do-able? > My display portion of my script utilizes the POST array to supply values to > my input screen - this works well for the first display of an empty screen, > and any following re-displays if there's an error in the user's input. But > I want to use this same script/screen to display the results of a query > when > the user wants to update an existing record. > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > I'm not sure what you're asking, but you can set the values of the POST array directly within a script, for instance: $_POST['new_key'] = 'new_value'; Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
Re: [PHP] $_POST vars
On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner wrote: > Can one create a set of $_POST vars within a script or is that not do-able? > My display portion of my script utilizes the POST array to supply values to > my input screen - this works well for the first display of an empty screen, > and any following re-displays if there's an error in the user's input. But > I want to use this same script/screen to display the results of a query > when > the user wants to update an existing record. While a user script can populate $_POST this is generally prohibited as it's typically populated by the environment. It would probly be cleaner to have the display portion of your script read from an arbitrary array. Said arbitrary array could be populated by $_POST in one case and the results of a query in another case. -nathan
Re: [PHP] $_POST vars
On Wednesday, 13 April 2011 at 18:56, Jim Giner wrote: And that includes adding entirely new elements in that array? Yes, it's a standard array. It's not special other than being a superglobal. > Do you have any suggestion on how to get the results of a query into POST > easily or is it simply a for loop? Not sure what you mean by "the results of a query". If you mean an array that you got from a MySQL query (my best guess), then simply assign that array to $_POST and Bob's your slightly perverted uncle! And please include the list when replying so everyone can benefit from the discussion. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] $_POST vars
Hi Jim, Sure you can create set of et of $_POST vars : e.g. So that admin_code var is passed to myphpaction.php as post and shall be access there via $_POST["admin_code "]; However, note that in PHP all the output buffer is flushed actually, ONLY after the script execution is terminated. Skype: eliorr.com -Original Message- From: Jim Giner [mailto:jim.gi...@albanyhandball.com] Sent: Wednesday, April 13, 2011 8:50 PM To: php-general@lists.php.net Subject: [PHP] $_POST vars Can one create a set of $_POST vars within a script or is that not do-able? My display portion of my script utilizes the POST array to supply values to my input screen - this works well for the first display of an empty screen, and any following re-displays if there's an error in the user's input. But I want to use this same script/screen to display the results of a query when the user wants to update an existing record. -- 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] Class Constants
That didn't quite work. Here's what I did: $const=$argv[1]; $value=email::$const; When I run it I get an "Access to undeclared static property" error. Thanks! Floyd On Apr 13, 2011, at 1:16 PM, Richard Quadling wrote: > On 13 April 2011 17:45, Floyd Resler wrote: >> I'm doing some testing from the command line and would like to be able = >> to pass along a constant from a class. For example: >> php emailTest.,php OrderConfirmation >> >> OrderConfirmation is a constant in a class. Is there any way I can take = >> the value passed on the command line and have PHP figure out which = >> constant is equals? >> >> Thanks! >> Floyd > > In your script ... > > print_r($argv); // Requires ini setting to set argv and argc. > // or > print_r($GLOBALS['argv']); // > ?> > > Once you've got the value, you can ... > > $s_ConstantValue = className::$s_ConstantNameFromCommandLine; > > sort of thing. > > > -- > Richard Quadling > Twitter : EE : Zend > @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY > > -- > 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] $_POST vars
On Wednesday, 13 April 2011 at 18:55, Nathan Nobbe wrote: On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner wrote: > > > Can one create a set of $_POST vars within a script or is that not do-able? > > My display portion of my script utilizes the POST array to supply values to > > my input screen - this works well for the first display of an empty screen, > > and any following re-displays if there's an error in the user's input. But > > I want to use this same script/screen to display the results of a query > > when > > the user wants to update an existing record. > > > While a user script can populate $_POST this is generally prohibited as it's > typically populated by the environment. > > It would probly be cleaner to have the display portion of your script read > from an arbitrary array. > > Said arbitrary array could be populated by $_POST in one case and the > results of a query in another case. While I don't necessarily disagree with you as far as abstracting the source of data goes, but it's never "prohibited", it just considered bad practice. Personally I've never understood this "thou shalt protect the superglobals" attitude. They're arrays, nothing more, use them in whatever way you want to. They're not sacred, endangered or likely to be overcome with the urge to kill you if you modify them. If your code changes its behaviour depending upon whether the data you're dealing with has come from within or without your code I think you have bigger style issues to address. All hail the superglobals! (sarcasm for those not familiar) -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
When you say "assign that array to $_POST" do you mean $_POST = $qrslt; Not sure about this "assigning an array" thing. - Original Message - From: "Stuart Dallas" Newsgroups: php.general To: "Jim Giner" Cc: "PHP General" Sent: Wednesday, April 13, 2011 1:59 PM Subject: Re: [PHP] $_POST vars > > Not sure what you mean by "the results of a query". If you mean an array > that you got from a MySQL query (my best guess), then simply assign that > array to $_POST ... > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
On Wed, Apr 13, 2011 at 12:04 PM, Stuart Dallas wrote: > On Wednesday, 13 April 2011 at 18:55, Nathan Nobbe wrote: > On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner >wrote: > > > > > Can one create a set of $_POST vars within a script or is that not > do-able? > > > My display portion of my script utilizes the POST array to supply > values to > > > my input screen - this works well for the first display of an empty > screen, > > > and any following re-displays if there's an error in the user's input. > But > > > I want to use this same script/screen to display the results of a query > > > when > > > the user wants to update an existing record. > > > > > > While a user script can populate $_POST this is generally prohibited as > it's > > typically populated by the environment. > > > > It would probly be cleaner to have the display portion of your script > read > > from an arbitrary array. > > > > Said arbitrary array could be populated by $_POST in one case and the > > results of a query in another case. > > While I don't necessarily disagree with you as far as abstracting the > source of data goes, but it's never "prohibited", it just considered bad > practice. > considered a bad practice means prohibited for most groups ive worked with. Personally I've never understood this "thou shalt protect the superglobals" > attitude. They're arrays, nothing more, use them in whatever way you want > to. They're not sacred, endangered or likely to be overcome with the urge to > kill you if you modify them. If your code changes its behaviour depending > upon whether the data you're dealing with has come from within or without > your code I think you have bigger style issues to address. > the reason it's a bad practice is it undermines an assumption that $_POST is only being populated by the environment, which in the case of $_POST is coming from a form field, ajax / curl request etc. as soon as that assumption is thrown out the window debugging becomes more involved trying to track down the mysterious appearance of a $_POST var. if you really need to store arbitrary data in a supergloabal $GLOABALS is there for that; def don't stuff these into $_POST :) keep things cleanly separated and you'll thank yourself later imo. also when someone is asking a question of this nature, obviously this is the most critical time to tell them about bad practices rather than just the obvious, "yes, of course you can do that...". otherwise people asking questions won't get much more mileage from this list than a google search. -nathan
Re: [PHP] $_POST vars
No need to email me AND send to the list. Is that the standard practice on this forum? Not encountered it before. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Class Constants
On Wed, Apr 13, 2011 at 11:04 AM, Floyd Resler wrote:
> That didn't quite work. Here's what I did:
> $const=$argv[1];
> $value=email::$const;
>
Instead try this:
$const = $argv[1];
$reflector = new ReflectionClass('email');
$value = $reflector->getConstant($const);
David
Re: [PHP] $_POST vars
Shrug, it's called reply-all and it's been brought up here before :) -nathan On Wed, Apr 13, 2011 at 12:25 PM, Jim Giner wrote: > No need to email me AND send to the list. Is that the standard practice on > this forum? Not encountered it before. > >
Re: [PHP] $_POST vars
On Wednesday, 13 April 2011 at 19:12, Jim Giner wrote: When you say "assign that array to $_POST" do you mean > > $_POST = $qrslt; > > Not sure about this "assigning an array" thing. Yup, nothing more complicated than that. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ > - Original Message - > From: "Stuart Dallas" > Newsgroups: php.general > To: "Jim Giner" > Cc: "PHP General" > Sent: Wednesday, April 13, 2011 1:59 PM > Subject: Re: [PHP] $_POST vars > > > > > > Not sure what you mean by "the results of a query". If you mean an array > > that you got from a MySQL query (my best guess), then simply assign that > > array to $_POST ... > > > > -- > 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] $_POST vars
On Wednesday, 13 April 2011 at 19:15, Nathan Nobbe wrote: On Wed, Apr 13, 2011 at 12:04 PM, Stuart Dallas wrote: > > On Wednesday, 13 April 2011 at 18:55, Nathan Nobbe wrote: > > On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner > > wrote: > > > > > > > Can one create a set of $_POST vars within a script or is that not > > > > do-able? > > > > My display portion of my script utilizes the POST array to supply > > > > values to > > > > my input screen - this works well for the first display of an empty > > > > screen, > > > > and any following re-displays if there's an error in the user's input. > > > > But > > > > I want to use this same script/screen to display the results of a query > > > > when > > > > the user wants to update an existing record. > > > > > > > > > While a user script can populate $_POST this is generally prohibited as > > > it's > > > typically populated by the environment. > > > > > > It would probly be cleaner to have the display portion of your script read > > > from an arbitrary array. > > > > > > Said arbitrary array could be populated by $_POST in one case and the > > > results of a query in another case. > > > > While I don't necessarily disagree with you as far as abstracting the > > source of data goes, but it's never "prohibited", it just considered bad > > practice. > > considered a bad practice means prohibited for most groups ive worked with. This isn't any of the groups you've worked with, this is the wide world and it's full of possibilities. > Personally I've never understood this "thou shalt protect the superglobals" > attitude. They're arrays, nothing more, use them in whatever way you want to. > They're not sacred, endangered or likely to be overcome with the urge to kill > you if you modify them. If your code changes its behaviour depending upon > whether the data you're dealing with has come from within or without your > code I think you have bigger style issues to address. the reason it's a bad practice is it undermines an assumption that $_POST is only being populated by the environment, which in the case of $_POST is coming from a form field, ajax / curl request etc. as soon as that assumption is thrown out the window debugging becomes more involved trying to track down the mysterious appearance of a $_POST var. if you really need to store arbitrary data in a supergloabal $GLOABALS is there for that; def don't stuff these into $_POST :) My idea of "best practice" says that data coming in from outside your code should only ever be dealt with in the first script the request hits, so you should never be hunting for where an errant value in $_POST came from. Given this (and noting the fact that this was your suggestion to the OP) you're creating the problem you're trying to avoid by using an "arbitrary array" in the place of $_POST. My response to the OP was simply answering the question. He has a section of code that uses $_POST and he wants to know if he can populate that within his code rather than needing it to come from a request. Why he didn't just try it is beyond me, but all this talk of best and bad practice is all beside the point. > keep things cleanly separated and you'll thank yourself later imo. also when > someone is asking a question of this nature, obviously this is the most > critical time to tell them about bad practices rather than just the obvious, > "yes, of course you can do that...". otherwise people asking questions won't > get much more mileage from this list than a google search. It's bad practice for reasons that arise equally well from abstracting the source of data, as you suggested. Why, then, is it bad practice? -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
On Wed, Apr 13, 2011 at 12:34 PM, Stuart Dallas wrote: > On Wednesday, 13 April 2011 at 19:15, Nathan Nobbe wrote: > On Wed, Apr 13, 2011 at 12:04 PM, Stuart Dallas wrote: > > > On Wednesday, 13 April 2011 at 18:55, Nathan Nobbe wrote: > > > On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner < > jim.gi...@albanyhandball.com>wrote: > > > > > > > > > Can one create a set of $_POST vars within a script or is that not > do-able? > > > > > My display portion of my script utilizes the POST array to supply > values to > > > > > my input screen - this works well for the first display of an empty > screen, > > > > > and any following re-displays if there's an error in the user's > input. But > > > > > I want to use this same script/screen to display the results of a > query > > > > > when > > > > > the user wants to update an existing record. > > > > > > > > > > > > While a user script can populate $_POST this is generally prohibited > as it's > > > > typically populated by the environment. > > > > > > > > It would probly be cleaner to have the display portion of your script > read > > > > from an arbitrary array. > > > > > > > > Said arbitrary array could be populated by $_POST in one case and the > > > > results of a query in another case. > > > > > > While I don't necessarily disagree with you as far as abstracting the > source of data goes, but it's never "prohibited", it just considered bad > practice. > > > > considered a bad practice means prohibited for most groups ive worked > with. > > This isn't any of the groups you've worked with, this is the wide world and > it's full of possibilities. > lol youre right, and none of the groups ive worked with have been part of this global community, so these must be strictly new possibilities we're discussing on this thread... > > Personally I've never understood this "thou shalt protect the > superglobals" attitude. They're arrays, nothing more, use them in whatever > way you want to. They're not sacred, endangered or likely to be overcome > with the urge to kill you if you modify them. If your code changes its > behaviour depending upon whether the data you're dealing with has come from > within or without your code I think you have bigger style issues to address. > the reason it's a bad practice is it undermines an assumption that $_POST > is only being populated by the environment, which in the case of $_POST is > coming from a form field, ajax / curl request etc. as soon as that > assumption is thrown out the window debugging becomes more involved trying > to track down the mysterious appearance of a $_POST var. if you really need > to store arbitrary data in a supergloabal $GLOABALS is there for that; def > don't stuff these into $_POST :) > > My idea of "best practice" says that data coming in from outside your code > should only ever be dealt with in the first script the request hits, so you > should never be hunting for where an errant value in $_POST came from. Given > this (and noting the fact that this was your suggestion to the OP) you're > creating the problem you're trying to avoid by using an "arbitrary array" in > the place of $_POST. > well when you build programs that are more than one script in length you'll find that data submitted by the user is often referenced further in the flow than the entry script.. read: front controller. and im not creating a problem, im avoiding a problem by not overloading the intended use of the $_POST array. > My response to the OP was simply answering the question. right, don't bother to offer any insight to a beginner, undermining the benefit of a list like php-general. > He has a section of code that uses $_POST and he wants to know if he can > populate that within his code rather than needing it to come from a request. > Why he didn't just try it is beyond me, but all this talk of best and bad > practice is all beside the point. > no, it's the entire point. if you ask a question on this list you should expect to get more than a black and white answer. that's how people get better quicker and that's the point of interacting with humans on the other end of the wire. > > keep things cleanly separated and you'll thank yourself later imo. also > when someone is asking a question of this nature, obviously this is the most > critical time to tell them about bad practices rather than just the obvious, > "yes, of course you can do that...". otherwise people asking questions won't > get much more mileage from this list than a google search. > > It's bad practice for reasons that arise equally well from abstracting the > source of data, as you suggested. Why, then, is it bad practice? no, it's actually a better practice. users are expected to populate arrays they create. the $GLOBALS array is expected to be populated by user scripts. The $_POST array is expected to be populated by PHP. by the time you've decided to stuff variables into $_GET or $_POST yourself you've decided to start mixing variables from
Re: [PHP] $_POST vars
PHP then is Truly an amazing and powerful language. I can expand the contents of the array $_POST by simply assigning a separate arry to it. Obviously if I have a duplicate element-name in my array it will override the $_POST element but that's my problem. "Stuart Dallas" wrote in message news:4962044e8a244fc28719d97746759...@3ft9.com... > On Wednesday, 13 April 2011 at 19:12, Jim Giner wrote: > When you say "assign that array to $_POST" do you mean >> >> $_POST = $qrslt; >> >> Not sure about this "assigning an array" thing. > Yup, nothing more complicated than that. -Stuart (remainder deleted for everyone's sake :) ) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Class Constants
David,
That worked great!
Thanks!
Floyd
On Apr 13, 2011, at 2:25 PM, David Harkness wrote:
> On Wed, Apr 13, 2011 at 11:04 AM, Floyd Resler wrote:
>
>> That didn't quite work. Here's what I did:
>> $const=$argv[1];
>> $value=email::$const;
>>
>
> Instead try this:
>
> $const = $argv[1];
> $reflector = new ReflectionClass('email');
> $value = $reflector->getConstant($const);
>
> David
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
Nathan Nobbe wrote on 04/13/2011 12:47:11 PM: [much snippage] > no, it's actually a better practice. users are expected to populate arrays > they create. the $GLOBALS array is expected to be populated by user > scripts. The $_POST array is expected to be populated by PHP. by the time > you've decided to stuff variables into $_GET or $_POST yourself you've > decided to start mixing variables from your code with variables from the > client. simply put these arrays are not intended to be populated by user > scripts. I like Chris Shiflett's approach, which emphasizes security. Step 1 with posted (tainted) data is to sanitize it. "Clean" values are then moved from $_GET/$_POST into a new array, e.g., $CLEAN, so that it is immediately clear to code reviewers, future support programmers, etc., that the data is now clean and safe to use. With this approach, $_POST is only used at Step 1 and then disappears from the remaining code; $CLEAN is used in subsequent steps. Using $_POST out in the middle of nowhere *looks* like it could be a security flaw, whether it actually is or isn't. And you know how Joel Spolsky feels about code that *looks* like it could be an error ;) But, yes, you can use $_POST just like any other array. Not a practice I prefer, but YMMV. Kirk
Re: [PHP] Class Constants
On 13 April 2011 19:04, Floyd Resler wrote:
> That didn't quite work. Here's what I did:
> $const=$argv[1];
> $value=email::$const;
>
> When I run it I get an "Access to undeclared static property" error.
>
> Thanks!
> Floyd
>
> On Apr 13, 2011, at 1:16 PM, Richard Quadling wrote:
>
>> On 13 April 2011 17:45, Floyd Resler wrote:
>>> I'm doing some testing from the command line and would like to be able =
>>> to pass along a constant from a class. For example:
>>> php emailTest.,php OrderConfirmation
>>>
>>> OrderConfirmation is a constant in a class. Is there any way I can take =
>>> the value passed on the command line and have PHP figure out which =
>>> constant is equals?
>>>
>>> Thanks!
>>> Floyd
>>
>> In your script ...
>>
>> > print_r($argv); // Requires ini setting to set argv and argc.
>> // or
>> print_r($GLOBALS['argv']); //
>> ?>
>>
>> Once you've got the value, you can ...
>>
>> $s_ConstantValue = className::$s_ConstantNameFromCommandLine;
>>
>> sort of thing.
>>
>>
>> --
>> Richard Quadling
>> Twitter : EE : Zend
>> @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
>>
>> --
>> 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
>
>
Or http://uk.php.net/manual/en/function.constant.php
constant('bar::'. $const)
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] A Starter has prob in blog script
Hello,
i has a CMS System, but want better write my website manually. Im
started at first with PHP or write a Program. I really not know what i
has to do, Google can not ask, i not know what should ask. Google with
"mysql link php foreach pdo" help not really.
I have for my blog two files, first is the the all entry list with a
link for the complete Entry. The file for list called bloggen.php, the
file for complete Entry called blogdetail.php. I has link the Entrys
from bloggen.php to blogdetail.php with blogdetail.php?blogid=1 or with
the other BlogID from Mysql.
The File bloggen.php run without any Problems. But the linking want not
work.
The code in blogdetail.php is:
---
query($sql);
foreach ($_POST as $blogid => $result)
{
echo $result['content'];
}
$DB = null;
}
catch (PDOException $e)
{
echo "Fehler: " . $e->getMessage();
exit ();
}
?>
---
This code should use the link which come from bloggen.php in. Example,
when i click on link (blogdetail.php?blogid=1) that the script take the
content from database for this entry. I use PDO System, the content in
database is save as HTML code. I has no error in my PHP log, only the
database should communicate with php at the website call, but they not
take the right content.
---
110413 22:52:45 630 Connect root@localhost on silviosiefke
630 Query SELECT * FROM sessions WHERE id = 'aeon1g5odp5hi0ka31uqmk16l4'
630 Query SELECT * FROM `bloggen` WHERE id = blogid ORDER BY date DESC
630 Query DELETE FROM sessions WHERE lastUpdated < 1302727065
630 Quit
---
I really starter with Program Langs, i have much things really finished,
but now i really not know.
Can someone help me? Thank u so much.
Regards
Silvio
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
On Wednesday, 13 April 2011 at 19:47, Nathan Nobbe wrote: > On Wed, Apr 13, 2011 at 12:34 PM, Stuart Dallas wrote: > > On Wednesday, 13 April 2011 at 19:15, Nathan Nobbe wrote: > > On Wed, Apr 13, 2011 at 12:04 PM, Stuart Dallas wrote: > > > > On Wednesday, 13 April 2011 at 18:55, Nathan Nobbe wrote: > > > > On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner > > > > wrote: > > > > > > > > > > > Can one create a set of $_POST vars within a script or is that not > > > > > > do-able? > > > > > > My display portion of my script utilizes the POST array to supply > > > > > > values to > > > > > > my input screen - this works well for the first display of an empty > > > > > > screen, > > > > > > and any following re-displays if there's an error in the user's > > > > > > input. But > > > > > > I want to use this same script/screen to display the results of a > > > > > > query > > > > > > when > > > > > > the user wants to update an existing record. > > > > > > > > > > > > > > > While a user script can populate $_POST this is generally prohibited > > > > > as it's > > > > > typically populated by the environment. > > > > > > > > > > It would probly be cleaner to have the display portion of your script > > > > > read > > > > > from an arbitrary array. > > > > > > > > > > Said arbitrary array could be populated by $_POST in one case and the > > > > > results of a query in another case. > > > > > > > > While I don't necessarily disagree with you as far as abstracting the > > > > source of data goes, but it's never "prohibited", it just considered > > > > bad practice. > > > > > > considered a bad practice means prohibited for most groups ive worked > > > with. > > > > This isn't any of the groups you've worked with, this is the wide world and > > it's full of possibilities. > > lol youre right, and none of the groups ive worked with have been part of > this global community, so these must be strictly new possibilities we're > discussing on this thread... I clearly didn't put my point across well enough, which was that what is and what isn't best practice is not set in stone. Best practices vary from group to group and from project to project, and that's the way it should be. However, just because you've mostly worked in groups where this is bad practice does not make it bad practice. > > > Personally I've never understood this "thou shalt protect the > > > superglobals" attitude. They're arrays, nothing more, use them in > > > whatever way you want to. They're not sacred, endangered or likely to be > > > overcome with the urge to kill you if you modify them. If your code > > > changes its behaviour depending upon whether the data you're dealing with > > > has come from within or without your code I think you have bigger style > > > issues to address. > > the reason it's a bad practice is it undermines an assumption that $_POST > > is only being populated by the environment, which in the case of $_POST is > > coming from a form field, ajax / curl request etc. as soon as that > > assumption is thrown out the window debugging becomes more involved trying > > to track down the mysterious appearance of a $_POST var. if you really need > > to store arbitrary data in a supergloabal $GLOABALS is there for that; def > > don't stuff these into $_POST :) > > > > My idea of "best practice" says that data coming in from outside your code > > should only ever be dealt with in the first script the request hits, so you > > should never be hunting for where an errant value in $_POST came from. > > Given this (and noting the fact that this was your suggestion to the OP) > > you're creating the problem you're trying to avoid by using an "arbitrary > > array" in the place of $_POST. > well when you build programs that are more than one script in length you'll > find that data submitted by the user is often referenced further in the flow > than the entry script.. read: front controller. and im not creating a > problem, im avoiding a problem by not overloading the intended use of the > $_POST array. Good at making assumptions, aren't you?! Anyway, again, you seem to have missed my point. In a front controller architecture, in my opinion, no code beyond that front controller should ever be referencing the get, post or cookie superglobals, and ideally not the server superglobal either. This, to me, is the equivalent of having all variables a system uses as globals which, I hope you'll agree, is something everyone agrees to be bad practice. > > My response to the OP was simply answering the question. > > > right, don't bother to offer any insight to a beginner, undermining the > benefit of a list like php-general. Again, your insight is from your perspective. It's an opinion, and one I don't share, hence why I didn't mention it. > > He has a section of code that uses $_POST and he wants to know if he can > > populate that within his code rather than needing it to come from a >
RE: [PHP] A Starter has prob in blog script
> > > Regards > Silvio > Sprechen sie deutsch? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Starter has prob in blog script
On Wed, Apr 13, 2011 at 17:06, Silvio Siefke wrote:
> Hello,
>
[snip!]
>
> The File bloggen.php run without any Problems. But the linking want not
> work.
Oh, boy. Okay, here we go
Because you're doing multiple lines if the condition is met, you
need to add an opening bracket here:
> if(isset($_POST['blogid']) && is_array($_POST['blogid']))
>
> try {
> $sql = 'SELECT blogid, content FROM `bloggen` WHERE id = ' .$blogid;
Then you define $result as the database object reference here (and
I'm still trying to figure out why you think $DB exists at this point,
other than perhaps some botched copy-and-paste from examples):
> $result = $DB->query($sql);
only to redefine it as an array value here:
> foreach ($_POST as $blogid => $result)
> {
so that, here, it thinks it should be grabbing $_POST values,
and that $blogid will retain the keys. So this doesn't exist:
> echo $result['content'];
This is nice:
> $DB = null;
> }
> catch (PDOException $e)
> {
> echo "Fehler: " . $e->getMessage();
You've got a lot of Fehleren in the code already. Don't worry
about the output of this quite yet.
> This code should use the link which come from bloggen.php in. Example,
> when i click on link (blogdetail.php?blogid=1) that the script take the
> content from database for this entry. I use PDO System, the content in
> database is save as HTML code. I has no error in my PHP log, only the
> database should communicate with php at the website call, but they not
> take the right content.
Right. Instead, try to fix it somewhat like this:
query($sql) as $row) {
var_dump($row).''.PHP_EOL;
}
?>
Good luck with the rest. You may want to just go back to the CMS,
or at least start with the basics. You may already be learning that
copying and pasting code doesn't always work but sometimes it can
be malicious code that, to an untrained eye, could really be a Bad
Thing[TM].
--
Network Infrastructure Manager
http://www.php.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Starter has prob in blog script
Am 14.04.2011 01:35, schrieb Daniel Brown: > Good luck with the rest. You may want to just go back to the CMS, > or at least start with the basics. You may already be learning that > copying and pasting code doesn't always work but sometimes it can > be malicious code that, to an untrained eye, could really be a Bad > Thing[TM]. Yes thats right what u write. When i make bad code with copy and paste, what is with a CMS System? What i know about this code, what i know about the backdoors, what i know which door is open for the Publisher or what is with the goverment? This website is not online, i know i must learn, but with books and howtos u learn not in two weeks all, i think before we normal write perfect for the masters it need more time. I nothing has to do with writing programs but i like work with computer, and my unix servers running perfect and something i must do. Im sorry when the questions is stupid, but at one point we all must start. I try that i only post the really hard questions, but what is hard for me and hard for the masters? Have nice day. Silvio -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] APC: Warming the bytecode cache with preload_path
Greetings, APC has an INI setting named apc.preload_path which I assume causes all PHP files within that path to be compiled and cached by APC as it is initialized. The documentation is nonexistent, but in this thread Rasmus corroborates my assumption (well, he doesn't invalidate it in any case): http://www.serverphorums.com/read.php?7,259956 I have enabled APC. I have restarted Apache many times. I have tried the command-line in which I am able to force APC to compile and cache files. APC is working flawlessly otherwise, caching compiled bytecode across requests. However, I cannot get any preloading to occur. I have also verified that the directory I am setting in the INI a) exists and b) matches the source files that APC ends up caching dynamically. Is there some other undocumented setting I have to enable beyond the path? The reason I need this is that when we push a new version of our site live and restart Apache, we get a few random fatal errors due to our 48M memory limit setting as APC forces the request threads to compile the scripts themselves. One of the larger pages on our site requires 29M of bytecode. Yes, I know that's insane. Part of it is Zend Framework but the vast majority is our data layer which will take some time to deconstruct to be more modular. I would create scripts to manually compile the larger scripts immediately after restarting Apache, but by then it's too late. We'll have received a few requests that die. Is there another creative solution I'm missing? Thanks, David
Re: [PHP] $_POST vars
On Wed, Apr 13, 2011 at 3:30 PM, Stuart Dallas wrote: > On Wednesday, 13 April 2011 at 19:47, Nathan Nobbe wrote: > > On Wed, Apr 13, 2011 at 12:34 PM, Stuart Dallas wrote: > > > On Wednesday, 13 April 2011 at 19:15, Nathan Nobbe wrote: > > > On Wed, Apr 13, 2011 at 12:04 PM, Stuart Dallas > wrote: > > > > > On Wednesday, 13 April 2011 at 18:55, Nathan Nobbe wrote: > > > > > On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner < > jim.gi...@albanyhandball.com>wrote: > > > > > > > > > > > > > Can one create a set of $_POST vars within a script or is that > not do-able? > > > > > > > My display portion of my script utilizes the POST array to > supply values to > > > > > > > my input screen - this works well for the first display of an > empty screen, > > > > > > > and any following re-displays if there's an error in the user's > input. But > > > > > > > I want to use this same script/screen to display the results of > a query > > > > > > > when > > > > > > > the user wants to update an existing record. > > > > > > > > > > > > > > > > > > While a user script can populate $_POST this is generally > prohibited as it's > > > > > > typically populated by the environment. > > > > > > > > > > > > It would probly be cleaner to have the display portion of your > script read > > > > > > from an arbitrary array. > > > > > > > > > > > > Said arbitrary array could be populated by $_POST in one case and > the > > > > > > results of a query in another case. > > > > > > > > > > While I don't necessarily disagree with you as far as abstracting > the source of data goes, but it's never "prohibited", it just considered bad > practice. > > > > > > > > considered a bad practice means prohibited for most groups ive worked > with. > > > > > > This isn't any of the groups you've worked with, this is the wide world > and it's full of possibilities. > > > > lol youre right, and none of the groups ive worked with have been part of > this global community, so these must be strictly new possibilities we're > discussing on this thread... > > I clearly didn't put my point across well enough, which was that what is > and what isn't best practice is not set in stone. Best practices vary from > group to group and from project to project, and that's the way it should be. > However, just because you've mostly worked in groups where this is bad > practice does not make it bad practice. > The irony here is I've developed this rule of thumb by working with groups that don't consider it a bad practice but should have. > > > > Personally I've never understood this "thou shalt protect the > superglobals" attitude. They're arrays, nothing more, use them in whatever > way you want to. They're not sacred, endangered or likely to be overcome > with the urge to kill you if you modify them. If your code changes its > behaviour depending upon whether the data you're dealing with has come from > within or without your code I think you have bigger style issues to address. > > > the reason it's a bad practice is it undermines an assumption that > $_POST is only being populated by the environment, which in the case of > $_POST is coming from a form field, ajax / curl request etc. as soon as that > assumption is thrown out the window debugging becomes more involved trying > to track down the mysterious appearance of a $_POST var. if you really need > to store arbitrary data in a supergloabal $GLOABALS is there for that; def > don't stuff these into $_POST :) > > > > > > My idea of "best practice" says that data coming in from outside your > code should only ever be dealt with in the first script the request hits, so > you should never be hunting for where an errant value in $_POST came from. > Given this (and noting the fact that this was your suggestion to the OP) > you're creating the problem you're trying to avoid by using an "arbitrary > array" in the place of $_POST. > > well when you build programs that are more than one script in length > you'll find that data submitted by the user is often referenced further in > the flow than the entry script.. read: front controller. and im not creating > a problem, im avoiding a problem by not overloading the intended use of the > $_POST array. > > Good at making assumptions, aren't you?! > lol, i figured id give it a shot. Anyway, again, you seem to have missed my point. In a front controller > architecture, in my opinion, no code beyond that front controller should > ever be referencing the get, post or cookie superglobals, and ideally not > the server superglobal either. I see what you're saying, but then you're implying that it's ideal to copy the values into secondary data structure(s), perhaps modifying the values along the way or at least have them accessed indirectly after the initial processing. > This, to me, is the equivalent of having all variables a system uses as > globals which, I hope you'll agree, is something everyone agrees to be bad > practice. > is that written in stone? The arbitrary arr
