php-general Digest 19 Jan 2011 15:34:27 -0000 Issue 7141
Topics (messages 310849 through 310868):
Re: switch case madness
310849 by: Chen Dong
310850 by: Joshua Kehn
310851 by: Mujtaba Arshad
310852 by: Donovan Brooke
310853 by: Joshua Kehn
310854 by: Donovan Brooke
310855 by: Joshua Kehn
310856 by: Donovan Brooke
310857 by: Paul M Foster
310863 by: Joshua Kehn
310864 by: Jay Blanchard
310865 by: Joshua Kehn
310866 by: Marc Guay
Class and interface location
310858 by: Larry Garfield
310859 by: Adam Richardson
310860 by: Richard Quadling
310861 by: Steve Staples
Autorename extracted files from zip-archive
310862 by: Merlin Morgenstern
310867 by: Daniel Brown
310868 by: Tommy Pham
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Hi,
If it is a string "0", you should use: case "0".
Because in PHP, 0 == false == null. You need to know the difference between
== and ===.
Regards,
Dong Chen
On Wed, Jan 19, 2011 at 2:30 PM, Donovan Brooke <li...@euca.us> wrote:
> Hello,
>
> I must not understand PHP's switch/case..
> The case '0' below fires when $t_mssg = "" apparently.
> Is this how it's suppose to work? I would think
> it would only fire if it equaled "0".
>
> ----------
> print "-$t_mssg- <br />";
>
> if (isset($t_mssg)) {
> switch ($t_mssg) {
> case 0:
> echo '<p><span style="color:red;">Log In Successful</span></p>';
> break;
> }
> }
> ----------
>
> TIA,
> Donovan
>
> --
> D Brooke
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Regards,
CHEN Dong
--- End Message ---
--- Begin Message ---
On Jan 18, 2011, at 10:30 PM, Donovan Brooke wrote:
> Hello,
>
> I must not understand PHP's switch/case..
> The case '0' below fires when $t_mssg = "" apparently.
> Is this how it's suppose to work? I would think
> it would only fire if it equaled "0".
>
> ----------
> print "-$t_mssg- <br />";
>
> if (isset($t_mssg)) {
> switch ($t_mssg) {
> case 0:
> echo '<p><span style="color:red;">Log In Successful</span></p>';
> break;
> }
> }
> ----------
>
> TIA,
> Donovan
>
> --
> D Brooke
I use switch cases so rarely I would have to refer you to the documentation.
Regards,
-Josh
____________________________________
Joshua Kehn | josh.k...@gmail.com
http://joshuakehn.com
--- End Message ---
--- Begin Message ---
$t_mssg = 0 is different from $t_mssg = "0" (in all languages, as far as I
know, maybe not in python, but I don't know python)
On Tue, Jan 18, 2011 at 10:30 PM, Donovan Brooke <li...@euca.us> wrote:
> Hello,
>
> I must not understand PHP's switch/case..
> The case '0' below fires when $t_mssg = "" apparently.
> Is this how it's suppose to work? I would think
> it would only fire if it equaled "0".
>
> ----------
> print "-$t_mssg- <br />";
>
> if (isset($t_mssg)) {
> switch ($t_mssg) {
> case 0:
> echo '<p><span style="color:red;">Log In Successful</span></p>';
> break;
> }
> }
> ----------
>
> TIA,
> Donovan
>
> --
> D Brooke
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Mujtaba
--- End Message ---
--- Begin Message ---
Thanks.
I had initialized $t_mssg as an empty string further up the chain out of
old habit.. removed that, and now it works... just built my first
basic cookie-based PHP/MySQL log-in script from scratch! ;-)
Fun stuff,
Donovan
--
D Brooke
--- End Message ---
--- Begin Message ---
On Jan 18, 2011, at 11:01 PM, Donovan Brooke wrote:
> Thanks.
>
> I had initialized $t_mssg as an empty string further up the chain out of old
> habit.. removed that, and now it works... just built my first
> basic cookie-based PHP/MySQL log-in script from scratch! ;-)
>
> Fun stuff,
> Donovan
>
>
>
> --
> D Brooke
I just died a bit on the inside.
Why would you build that from scratch?
Regards,
-Josh
____________________________________
Joshua Kehn | josh.k...@gmail.com
http://joshuakehn.com
--- End Message ---
--- Begin Message ---
--
D Brooke
I just died a bit on the inside.
Why would you build that from scratch?
Regards,
-Josh
Alright, I'll bite (since I affected you that much) ;-),
do tell...
Why not? Would you rather I use PHP's session_start()?
Donovan
--
D Brooke
--- End Message ---
--- Begin Message ---
On Jan 18, 2011, at 11:33 PM, Donovan Brooke wrote:
>>> --
>>> D Brooke
>>
>> I just died a bit on the inside.
>>
>> Why would you build that from scratch?
>>
>> Regards,
>>
>> -Josh
>
>
> Alright, I'll bite (since I affected you that much) ;-),
>
> do tell...
>
> Why not? Would you rather I use PHP's session_start()?
>
>
> Donovan
>
Why not use one of the countless, not to mention secure and stable cookie
management systems available? If it's an exercise cool, I misunderstood.
I'm not one to normally shun people rolling their own code, lord knows I've
done it more then once or twice, but there are some things I wouldn't touch
with a ten foot pool, and cookie management is one of them. The other would be
things like CSV parsers or text manipulations.
Regards,
-Josh
____________________________________
Joshua Kehn | josh.k...@gmail.com
http://joshuakehn.com
--- End Message ---
--- Begin Message ---
Why not use one of the countless, not to mention secure and stable cookie
management systems available? If it's an exercise cool, I misunderstood.
I'm not one to normally shun people rolling their own code, lord knows I've
done it more then once or twice, but there are some things I wouldn't touch
with a ten foot pool, and cookie management is one of them. The other would be
things like CSV parsers or text manipulations.
Regards,
-Josh
The idea of using existing resources for efficiency is very valid
indeed.. especially with a job at hand. But, there are good reasons to
roll-your-own... education and knowing your own code are 2 that are
important to me right now. Besides, a cookie based log-in system is
really not that complex. ;-)
Now.. payment gateway API? AJAX requests? I'll take the snippets please.
Cheers,
Donovan (moving on to database administration)
--
D Brooke
--- End Message ---
--- Begin Message ---
On Tue, Jan 18, 2011 at 10:53:19PM -0600, Donovan Brooke wrote:
> >Why not use one of the countless, not to mention secure and stable cookie
> management systems available? If it's an exercise cool, I misunderstood.
> >
> >I'm not one to normally shun people rolling their own code, lord knows
> I've done it more then once or twice, but there are some things I wouldn't
> touch with a ten foot pool, and cookie management is one of them. The
> other would be things like CSV parsers or text manipulations.
> >
> >Regards,
> >
> >-Josh
>
>
> The idea of using existing resources for efficiency is very valid
> indeed.. especially with a job at hand. But, there are good reasons to
> roll-your-own... education and knowing your own code are 2 that are
> important to me right now. Besides, a cookie based log-in system is
> really not that complex. ;-)
I have to agree here. Login systems aren't that hard to do. And finding
a "library" or "toolkit" which does exactly what you want exactly the
way you want may not be so easy. For example, I don't use MySQL unless I
absolutely have to. But there aren't that many such systems based on
PostgreSQL. I could take their MySQl code and hack it. But while
analyzing their code, you find you could have done this yourself in half
a day, less if you've done it before.
I'm just thick enough to believe that most programming problems are
relatively easily solved from scratch. And it's an interesting challenge
to do so. Particularly when the result is something which can be reused
in later projects.
Yes, of course, I wouldn't touch payment gateways and the like.
Paul
--
Paul M. Foster
http://noferblatz.com
--- End Message ---
--- Begin Message ---
On Jan 18, 2011, at 11:53 PM, Donovan Brooke wrote:
> The idea of using existing resources for efficiency is very valid indeed..
> especially with a job at hand. But, there are good reasons to
> roll-your-own... education and knowing your own code are 2 that are important
> to me right now. Besides, a cookie based log-in system is really not that
> complex. ;-)
>
> Now.. payment gateway API? AJAX requests? I'll take the snippets please.
>
> Cheers,
> Donovan (moving on to database administration)
Payment gateways suck. AJAX requests are easy if you roll JavaScript well and
have a decent inspector (Firebug).
I agree, a simple login is not that complex. I thought it was a bit more
involved then that.
Regards,
-Josh
____________________________________
Joshua Kehn | josh.k...@gmail.com
http://joshuakehn.com
--- End Message ---
--- Begin Message ---
[snip]
...
[/snip]
Imagine when there'll be the day when you do not have to code at
all...just copy 'n paste snippets together in the order that you wish
them to work in and Voila'! - instant web app.
Thpppppppppppptttttttttttttttt!!!!!!
--- End Message ---
--- Begin Message ---
On Jan 19, 2011, at 9:43 AM, Jay Blanchard wrote:
> [snip]
> ...
> [/snip]
>
> Imagine when there'll be the day when you do not have to code at
> all...just copy 'n paste snippets together in the order that you wish
> them to work in and Voila'! - instant web app.
>
>
> Thpppppppppppptttttttttttttttt!!!!!!
>
They have that. It's called Ruby on Rails.
Regards,
-Josh
____________________________________
Joshua Kehn | josh.k...@gmail.com
http://joshuakehn.com
--- End Message ---
--- Begin Message ---
> Imagine when there'll be the day when you do not have to code at
> all...just copy 'n paste snippets together in the order that you wish
> them to work in and Voila'! - instant web app.
I have a Wordpress plugin that will do all of that for you.
--- End Message ---
--- Begin Message ---
Hi all. I'm trying to come up with a solution to an architectural problem I
could use some extra eyes on.
I have (or will have) a large code base with lots of classes, spread out over
many optional plugin components. These classes, of course, will have
interfaces on them. These classes will, of course, lazy-load using PHP's
autoload capability.
What I need to know is which classes implement which interfaces, so that I can
load and use "all classes that implement interface Foo".
There are a couple of approaches that I've considered, all of which I dislike
for one reason or another.
1) Magic file naming. That is, any class that implements interface Foo lives
in a $something.Foo.inc file, or some similar pattern. This has a number of
problems. First, it means a huge number of file_exists() calls to determine
if a given potential class exists, and then disk hits to load those files.
While that information is possible to cache, it also means that we cannot have
a class that implements two of the interfaces I'm interested in (a feature I
will need) because then it would have to live in two files, which is clearly
impossible.
2) Reflection. PHP makes it quite easy to get a list of all loaded classes,
and to get a list of all interfaces that a loaded class implements. The catch
there is "loaded". Reflection only works once you've loaded the code file
into memory. Once you've done so, you cannot unload it. That means the code
is sitting there in memory wasting space. Given the size of the code base in
question, that could easily blow out the process memory limit. Even if we
cache that information we derive from reflection we still have to load it the
first time (or periodically when rebuilding the cache), which will blow the
memory limit. The only alternative would be to have some sort of incremental
rebuild across a multi-request batch process, the complexity of which makes my
skin crawl.
3) Static analysis. Instead of reflection, either tokenize or string parse
all files to determine what classes implement what interfaces and then cache
that information. We are actually using this method now to locate classes,
and it works surprisingly well. Because we never parse code into memory it
does not ever spike the memory usage. However, it is impossible to determine
if a class implements a given interface by static analysis unless it declare
so itself with the implements keyword. If it does so indirectly via
inheritance, either via the class or via the interface, it would not find it.
That necessitates that any "detectable" classes must explicitly themselves
declare their interfaces, even if it is redundant to do so. I don't like that
approach, but it's the first one that strikes me as even viable.
4) Explicit declaration. In this approach we detect nothing and rely on the
plugin developer to do everything. That is, they must provide somewhere
(either in code or a configuration file) an index of all classes they offer,
the interfaces they implement, and the file in which they live. While this
makes the implementation easy, it is a huge burden on the plugin developer and
I'm quite sure they'll forget to do so or get it wrong on a regular basis.
5) Wave a wand and let the magic ponies figure it out. I wish. :-)
Can anyone suggest a better alternative? At the moment option 3 seems like
the most viable approach, but I'm not wild about the implied performance
impact nor the potentially redundant interface definitions it would require.
--Larry Garfield
--- End Message ---
--- Begin Message ---
On Wed, Jan 19, 2011 at 2:07 AM, Larry Garfield <la...@garfieldtech.com>wrote:
> 3) Static analysis. Instead of reflection, either tokenize or string parse
> all files to determine what classes implement what interfaces and then
> cache
> that information. We are actually using this method now to locate classes,
> and it works surprisingly well. Because we never parse code into memory it
> does not ever spike the memory usage. However, it is impossible to
> determine
> if a class implements a given interface by static analysis unless it
> declare
> so itself with the implements keyword. If it does so indirectly via
> inheritance, either via the class or via the interface, it would not find
> it.
> That necessitates that any "detectable" classes must explicitly themselves
> declare their interfaces, even if it is redundant to do so. I don't like
> that
> approach, but it's the first one that strikes me as even viable.
>
4) Explicit declaration. In this approach we detect nothing and rely on the
> plugin developer to do everything. That is, they must provide somewhere
> (either in code or a configuration file) an index of all classes they
> offer,
> the interfaces they implement, and the file in which they live. While this
> makes the implementation easy, it is a huge burden on the plugin developer
> and
> I'm quite sure they'll forget to do so or get it wrong on a regular basis.
>
I'd suggest combining 3 and 4. Build a tool that performs a static analysis
of a group of files and make it easy for developers to use. This tool would
generate the explicit declarations your codebase would utilize when
answering such questions as "which classes implement interface foo". The
file the static analysis tool generates could be easily hand editable, so
developers could tweak it if they see issues (just in case the static
analysis tool has bugs early on), or for small plugins, just quick crank out
a couple lines by hand.
As long as the static analysis tool builds a composite of class hierarchy
established in all the files (project wide, at least in terms of the
plugin), you wouldn't have to double declare interfaces so they could be
detected.
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
On 19 January 2011 07:46, Adam Richardson <simples...@gmail.com> wrote:
> On Wed, Jan 19, 2011 at 2:07 AM, Larry Garfield <la...@garfieldtech.com>wrote:
>
>> 3) Static analysis. Instead of reflection, either tokenize or string parse
>> all files to determine what classes implement what interfaces and then
>> cache
>> that information. We are actually using this method now to locate classes,
>> and it works surprisingly well. Because we never parse code into memory it
>> does not ever spike the memory usage. However, it is impossible to
>> determine
>> if a class implements a given interface by static analysis unless it
>> declare
>> so itself with the implements keyword. If it does so indirectly via
>> inheritance, either via the class or via the interface, it would not find
>> it.
>> That necessitates that any "detectable" classes must explicitly themselves
>> declare their interfaces, even if it is redundant to do so. I don't like
>> that
>> approach, but it's the first one that strikes me as even viable.
>>
>
> 4) Explicit declaration. In this approach we detect nothing and rely on the
>> plugin developer to do everything. That is, they must provide somewhere
>> (either in code or a configuration file) an index of all classes they
>> offer,
>> the interfaces they implement, and the file in which they live. While this
>> makes the implementation easy, it is a huge burden on the plugin developer
>> and
>> I'm quite sure they'll forget to do so or get it wrong on a regular basis.
>>
>
> I'd suggest combining 3 and 4. Build a tool that performs a static analysis
> of a group of files and make it easy for developers to use. This tool would
> generate the explicit declarations your codebase would utilize when
> answering such questions as "which classes implement interface foo". The
> file the static analysis tool generates could be easily hand editable, so
> developers could tweak it if they see issues (just in case the static
> analysis tool has bugs early on), or for small plugins, just quick crank out
> a couple lines by hand.
>
> As long as the static analysis tool builds a composite of class hierarchy
> established in all the files (project wide, at least in terms of the
> plugin), you wouldn't have to double declare interfaces so they could be
> detected.
>
> Adam
>
> --
> Nephtali: A simple, flexible, fast, and security-focused PHP framework
> http://nephtaliproject.com
>
There is a pecl extension called inclued [1] & [2] which could be used I think.
It can be used to produce a list of all the relationships between
included files, so a one off pass of all the class files (simply
include them) and then retrieve the analysis from inclued.
You can now build a class dependency tree from that data and cache it.
Pretty much exactly what you need.
Richard.
[1] http://pecl.php.net/package/inclued
[2] http://docs.php.net/manual/en/book.inclued.php
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
On Wed, 2011-01-19 at 01:07 -0600, Larry Garfield wrote:
> Hi all. I'm trying to come up with a solution to an architectural problem I
> could use some extra eyes on.
>
> I have (or will have) a large code base with lots of classes, spread out over
> many optional plugin components. These classes, of course, will have
> interfaces on them. These classes will, of course, lazy-load using PHP's
> autoload capability.
>
> What I need to know is which classes implement which interfaces, so that I
> can
> load and use "all classes that implement interface Foo".
>
> There are a couple of approaches that I've considered, all of which I dislike
> for one reason or another.
>
> 1) Magic file naming. That is, any class that implements interface Foo lives
> in a $something.Foo.inc file, or some similar pattern. This has a number of
> problems. First, it means a huge number of file_exists() calls to determine
> if a given potential class exists, and then disk hits to load those files.
> While that information is possible to cache, it also means that we cannot
> have
> a class that implements two of the interfaces I'm interested in (a feature I
> will need) because then it would have to live in two files, which is clearly
> impossible.
>
> 2) Reflection. PHP makes it quite easy to get a list of all loaded classes,
> and to get a list of all interfaces that a loaded class implements. The
> catch
> there is "loaded". Reflection only works once you've loaded the code file
> into memory. Once you've done so, you cannot unload it. That means the code
> is sitting there in memory wasting space. Given the size of the code base in
> question, that could easily blow out the process memory limit. Even if we
> cache that information we derive from reflection we still have to load it the
> first time (or periodically when rebuilding the cache), which will blow the
> memory limit. The only alternative would be to have some sort of incremental
> rebuild across a multi-request batch process, the complexity of which makes
> my
> skin crawl.
>
> 3) Static analysis. Instead of reflection, either tokenize or string parse
> all files to determine what classes implement what interfaces and then cache
> that information. We are actually using this method now to locate classes,
> and it works surprisingly well. Because we never parse code into memory it
> does not ever spike the memory usage. However, it is impossible to determine
> if a class implements a given interface by static analysis unless it declare
> so itself with the implements keyword. If it does so indirectly via
> inheritance, either via the class or via the interface, it would not find it.
>
> That necessitates that any "detectable" classes must explicitly themselves
> declare their interfaces, even if it is redundant to do so. I don't like
> that
> approach, but it's the first one that strikes me as even viable.
>
> 4) Explicit declaration. In this approach we detect nothing and rely on the
> plugin developer to do everything. That is, they must provide somewhere
> (either in code or a configuration file) an index of all classes they offer,
> the interfaces they implement, and the file in which they live. While this
> makes the implementation easy, it is a huge burden on the plugin developer
> and
> I'm quite sure they'll forget to do so or get it wrong on a regular basis.
>
> 5) Wave a wand and let the magic ponies figure it out. I wish. :-)
>
> Can anyone suggest a better alternative? At the moment option 3 seems like
> the most viable approach, but I'm not wild about the implied performance
> impact nor the potentially redundant interface definitions it would require.
>
> --Larry Garfield
>
My suggestion, would be for #5. The magic ponies do wonderful work.
:)
Steve (TheStapler) Staples.
--- End Message ---
--- Begin Message ---
Hello,
I am using shell_exec to uncompress zip files which works fine, but has
one big problem. Whenever the zip-archive containes an already existing
file name, it will overwrite the current one. I need the file to be
extracted and autorenamed.
This is the code line:
$output = shell_exec('unzip -jo '.$filename.' -d '.$path);
Does anybody know a way on how to autorename existing files?
I thought about a workaround on extracting to a tmp folder and then
moving to the proper directory while renaming the files if they already
exists. Unfortunatelly I could not find a way to do this.
Thank you for any help on this.
Merlin
--- End Message ---
--- Begin Message ---
On Wed, Jan 19, 2011 at 09:06, Merlin Morgenstern <merli...@fastmail.fm> wrote:
> Hello,
>
> I am using shell_exec to uncompress zip files which works fine, but has one
> big problem. Whenever the zip-archive containes an already existing file
> name, it will overwrite the current one. I need the file to be extracted and
> autorenamed.
>
> This is the code line:
>
> $output = shell_exec('unzip -jo '.$filename.' -d '.$path);
>
> Does anybody know a way on how to autorename existing files?
Just because you're using PHP as a frontend doesn't mean this is a
PHP question. This is a Linux administration question, and one that
Google can handle.
> I thought about a workaround on extracting to a tmp folder and then moving
> to the proper directory while renaming the files if they already exists.
> Unfortunatelly I could not find a way to do this.
Probably because you haven't written it yet. When you think about
how to achieve this, it's really simple:
1.) Create a temporary directory (e.g. -
mkdir(dirname(__FILE__).'/tmp'.time()) for a unique name).
2.) Extract the files to that directory.
3.) Check the target directory for existing files.
4.) Handle things as appropriate.
There are even simpler ways, again available by searching Google,
you may just need to adjust your search terms and try again.
--
</Daniel P. Brown>
Network Infrastructure Manager
Documentation, Webmaster Teams
http://www.php.net/
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Merlin Morgenstern [mailto:merli...@fastmail.fm]
> Sent: Wednesday, January 19, 2011 6:06 AM
> To: php-gene...@lists.php.net
> Subject: [PHP] Autorename extracted files from zip-archive
>
> Hello,
>
> I am using shell_exec to uncompress zip files which works fine, but has
one
> big problem. Whenever the zip-archive containes an already existing file
> name, it will overwrite the current one. I need the file to be extracted
and
> autorenamed.
>
> This is the code line:
>
> $output = shell_exec('unzip -jo '.$filename.' -d '.$path);
>
> Does anybody know a way on how to autorename existing files?
>
> I thought about a workaround on extracting to a tmp folder and then moving
> to the proper directory while renaming the files if they already exists.
> Unfortunatelly I could not find a way to do this.
>
> Thank you for any help on this.
>
> Merlin
>
Merlin,
It's a shame that unzip doesn't have that feature like unrar. However, I
suggest you extract the contents of the zip files into a temp working
directory. Scan the files within that directory for any compressed archives
and extract each into their own subdirectory matching the filename. And
just recurse until no more compressed archives. Then process whatever files
you need. When done, just rm -fd <tmpworkdir> (my unix/linux is limited.
Don't recall the parameters). That way, clean up is a synch and you still
have the original file when there's something wrong during processing stages
like mismatch columns, duplicate entries, etc.
Regards,
Tommy
--- End Message ---
