Comments for NickAWilliams.com http://www.nickawilliams.com For everything Nick! Thu, 11 Mar 2010 15:59:58 +0000 http://wordpress.org/?v=2.6 Comment on The New .phar PHP Package by Lenguajes X » Simular paquetes en PHP http://www.nickawilliams.com/2008/09/04/the-new-phar-php-package/#comment-60 Lenguajes X » Simular paquetes en PHP Tue, 10 Nov 2009 20:48:15 +0000 http://www.nickawilliams.com/?p=29#comment-60 [...] script que nos permite cargar paquetes al estilo Java desde PHP. Aunque ya existen los phar, que es un paquete de PHP, esto puede resultar una posibilidad o al menos un método a tener en [...] [...] script que nos permite cargar paquetes al estilo Java desde PHP. Aunque ya existen los phar, que es un paquete de PHP, esto puede resultar una posibilidad o al menos un método a tener en [...]

]]> Comment on The New .phar PHP Package by Lee http://www.nickawilliams.com/2008/09/04/the-new-phar-php-package/#comment-51 Lee Tue, 17 Feb 2009 05:00:53 +0000 http://www.nickawilliams.com/?p=29#comment-51 As Pablo mentiond, you can call Phar::webPhar(), Phar::mungServer and Phar::interceptFileFuncs() to make a .phar a complete web application. Phar::webPhar() actually installs a front controller into the .phar that makes it painless. Phar::mungServer() fixes up the $_SERVER global Phar::interceptFileFuncs() will make relative references inside the .phar properly point back into the .phar As Pablo mentiond, you can call Phar::webPhar(), Phar::mungServer and Phar::interceptFileFuncs() to make a .phar a complete web application.

Phar::webPhar() actually installs a front controller into the .phar that makes it painless.

Phar::mungServer() fixes up the $_SERVER global

Phar::interceptFileFuncs() will make relative references inside the .phar properly point back into the .phar

]]> Comment on The New .phar PHP Package by Pablo Viquez http://www.nickawilliams.com/2008/09/04/the-new-phar-php-package/#comment-41 Pablo Viquez Tue, 30 Sep 2008 00:12:35 +0000 http://www.nickawilliams.com/?p=29#comment-41 I did a presentation about PHAR for the office. I made available my slides here: http://www.pabloviquez.com/2008/09/phar-files/ In case you're interested. I did a presentation about PHAR for the office. I made available my slides here: http://www.pabloviquez.com/2008/09/phar-files/

In case you’re interested.

]]> Comment on The New .phar PHP Package by Nick Williams’ Blog: The New .phar PHP Package : Dragonfly Networks http://www.nickawilliams.com/2008/09/04/the-new-phar-php-package/#comment-40 Nick Williams’ Blog: The New .phar PHP Package : Dragonfly Networks Thu, 25 Sep 2008 10:30:02 +0000 http://www.nickawilliams.com/?p=29#comment-40 [...] a quick post to his blog, Nick Williams points out a very handy extension for PHP - [...] [...] a quick post to his blog, Nick Williams points out a very handy extension for PHP - [...]

]]> Comment on The New .phar PHP Package by nick http://www.nickawilliams.com/2008/09/04/the-new-phar-php-package/#comment-39 nick Wed, 24 Sep 2008 21:28:20 +0000 http://www.nickawilliams.com/?p=29#comment-39 That's great to hear! I've been thinking about using this package in my next project, and it's sounding more and more viable given how flexible it seems to be. That’s great to hear! I’ve been thinking about using this package in my next project, and it’s sounding more and more viable given how flexible it seems to be.

]]> Comment on The New .phar PHP Package by Pablo http://www.nickawilliams.com/2008/09/04/the-new-phar-php-package/#comment-38 Pablo Wed, 24 Sep 2008 21:22:17 +0000 http://www.nickawilliams.com/?p=29#comment-38 Acctually, the performance is pretty good, there's no big impact, and you can use with APC to do some code cache. BTW, the PEAR package now comes as a Phar. Regarding the the phar over http, it's very easy, just add the application type to your apache configuration, the phars are designed to run out of the box, more if you use Phar::webphar on your stub. Acctually, the performance is pretty good, there’s no big impact, and you can use with APC to do some code cache.

BTW, the PEAR package now comes as a Phar.

Regarding the the phar over http, it’s very easy, just add the application type to your apache configuration, the phars are designed to run out of the box, more if you use Phar::webphar on your stub.

]]> Comment on PHP Patterns, Part I by xrado http://www.nickawilliams.com/2007/09/16/hello-world/#comment-37 xrado Wed, 24 Sep 2008 20:59:25 +0000 #comment-37 i see, so if i have defined $DB for a global db connection and this a know rule anyone should stick to it, that wont be a problem? ..maybe bad pratice but shorter code ...or there are other bad sides? i see, so if i have defined $DB for a global db connection and this a know rule anyone should stick to it, that wont be a problem? ..maybe bad pratice but shorter code …or there are other bad sides?

]]> Comment on The New .phar PHP Package by nick http://www.nickawilliams.com/2008/09/04/the-new-phar-php-package/#comment-36 nick Wed, 24 Sep 2008 20:51:54 +0000 http://www.nickawilliams.com/?p=29#comment-36 From what I've been able to find, there isn't any mention of a way to do that. I'll update my post if I run across anything though. As a workaround, if you're using Apache you could do a mod_rewrite and watch for URLs with .phar in them. Then you could pass the URL contents to a PHP script that could in-turn open the file for you. From what I’ve been able to find, there isn’t any mention of a way to do that. I’ll update my post if I run across anything though.

As a workaround, if you’re using Apache you could do a mod_rewrite and watch for URLs with .phar in them. Then you could pass the URL contents to a PHP script that could in-turn open the file for you.

]]> Comment on PHP Patterns, Part I by nick http://www.nickawilliams.com/2007/09/16/hello-world/#comment-35 nick Wed, 24 Sep 2008 20:43:05 +0000 #comment-35 The problem with using global variables is that for larger applications you are opening yourself up to problems that are very difficult to trace (specifically, naming collisions).Declaring a global $DB variable means that from that point forward, nowhere else in your entire application can you use the variable $DB for anything else. If you do by mistake, you could very easily run into problems that aren't immediately apparrent. You won't get an error, but what happens if another piece of code uses it expecting a string but getting a database connection instead? This is especially a problem when more than one person is writing code for the same project. While you might remember that you've already used $DB, someone else on your dev team might not know that and create $DB for their own purposes. This problem also results from the re-use of variables, which is also generally a big no-no. The problem with using global variables is that for larger applications you are opening yourself up to problems that are very difficult to trace (specifically, naming collisions).Declaring a global $DB variable means that from that point forward, nowhere else in your entire application can you use the variable $DB for anything else. If you do by mistake, you could very easily run into problems that aren’t immediately apparrent.

You won’t get an error, but what happens if another piece of code uses it expecting a string but getting a database connection instead? This is especially a problem when more than one person is writing code for the same project. While you might remember that you’ve already used $DB, someone else on your dev team might not know that and create $DB for their own purposes. This problem also results from the re-use of variables, which is also generally a big no-no.

]]> Comment on PHP Patterns, Part I by xrado http://www.nickawilliams.com/2007/09/16/hello-world/#comment-34 xrado Wed, 24 Sep 2008 20:26:17 +0000 #comment-34 what if u say global $DB; and you can have connection available any where, is something wrong with that? what if u say global $DB; and you can have connection available any where, is something wrong with that?

]]>