RE: [PHP] On large application organization [long and possibly boring]

2005-01-10 Thread Jay Blanchard
[snip] > Josh, I am interested in what you mean by "but there may be a better > overall approach." The reason I say that is because, though I'm no expert on application design, in my own code I've found that whenever I'm tempted to use a big switch, it's probably a better idea for me to make a cl

Re: [PHP] On large application organization [long and possibly boring]

2005-01-08 Thread Josh Whiting
> Josh, I am interested in what you mean by "but there may be a better > overall approach." (which was in reference to my original question which was: why are you using a big switch?) The reason I say that is because, though I'm no expert on application design, in my own code I've found that whe

RE: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Richard Lynch
Jay Blanchard wrote: > [snip] > Richard Lynch speaks: > But it ends up being not all that maintainable, and you end up having to > open up and track too many files with too many interactions when you go > down this route. > > I abandoned this style and have never regretted it. > > YMMV > [/snip] >

RE: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Jay Blanchard
[snip] Richard Lynch speaks: But it ends up being not all that maintainable, and you end up having to open up and track too many files with too many interactions when you go down this route. I abandoned this style and have never regretted it. YMMV [/snip] In favor of what? -- PHP General Mailin

Re: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Richard Lynch
Jamie Alessio wrote: > BUT, also from documentation on http://us2.php.net/include/ it looks > like your example might not hold any water either. "Be warned that parse > error in required file doesn't cause processing halting." Based on that > it appears that introducing the parse error in foo2.php

Re: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Richard Lynch
Jay Blanchard wrote: > switch($action){ > /* several dozen cases to follow */ > case "foo": > writing out all of the code > break; > } > > and this > > switch($action){ > /* several dozen cases to follow */ > case "foo": > include that will

RE: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Jay Blanchard
[snip] BUT, also from documentation on http://us2.php.net/include/ it looks like your example might not hold any water either. "Be warned that parse error in required file doesn't cause processing halting." Based on that it appears that introducing the parse error in foo2.php doesn't prove that

Re: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Jason Barnett
Assumably, if includes were processed before the script was executed, it would show a syntax error in foo2.php. We ran Good point about the syntax error. the test (v 4.2.1) and no error was returned, so that pretty much answers the question (READ: includes are not processed until they are calle

RE: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Jay Blanchard
[snip] > I appreciate all of ya'll's insight on this and for setting me straight > on the includes/requires band wagon. I made some incorrect assumptions > (and didn't run the simple tests I could have run myself, as a couple of > you have pointed out) and I will now have to eat some crow in front

RE: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Jesse Castro
[snip] You're wrong. The include() and require() statements are only evaluated when they are reached in your application code, so there is a big difference between your two examples. In you use the second example the code will only be included by PHP if the application logic enters the case stateme

Re: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Jamie Alessio
>> This doesn't prove the case either way. >> Nice catch on that one but actually there might be another problem with my example. According to example 16-8 on http://us2.php.net/include/ "Because include() and require() are special language constructs, you must enclose them within a statement

Re: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Jason Barnett
Consider yourself bytten, RTFM indeed! (BTW, this behavior is not really mentioned anywhere that I can find in TFM, it is more or less an assumption to be made from an example which would not prove the include) OK this is the last time I push the button on this one, but since you asked ;) http://

RE: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Richard Lynch
> Just out of curiosity, a lot of people had answers to this question, but > I couldn't find a shred of evidence in the > documentation. Did you do similar tests, hear from gurus, or something > of like? Or did I just miss it somewhere? Once upon a time, a long time ago, require and include were

RE: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Jesse Castro
[snip] You're wrong. The include() and require() statements are only evaluated when they are reached in your application code, so there is a big difference between your two examples. In you use the second example the code will only be included by PHP if the application logic enters the case stateme

Re: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Jason Barnett
Remember, I am old school. My first programming venture was in the 70's with FORTRAN, so all of you young bucks view programming differently than I do. I have a tendency to view things more from a C or C++ POV in I am indeed a young buck... but now I find myself moving (backwards?) because I have

Re: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread John Nichel
Jay Blanchard wrote: Remember, I am old school. My first programming venture was in the 70's with FORTRAN, so all of you young bucks view programming differently than I do. Old fart. I didn't venture into programming until 1980 with BASIC on an Atari. ;) Somebody wake-up grandpa Jay...he fell

RE: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Jay Blanchard
[snip] > > Otherwise, I'm curious as to why you're using a large switch, not that > it's bad inherently IMHO, but there may be a better overall approach. > > /jw I don't know why *he* wants to do it, but one useful example is the MVC model (google "MVC phppatterns" if you're unfamiliar with t

Re: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Jason Barnett
Otherwise, I'm curious as to why you're using a large switch, not that it's bad inherently IMHO, but there may be a better overall approach. /jw I don't know why *he* wants to do it, but one useful example is the MVC model (google "MVC phppatterns" if you're unfamiliar with the term). For a gi

Re: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Jason Barnett
Jamie Alessio wrote: Correct me if I am wrong, but includes (and/or requires) will get all of the code in all of the cases regardless if the case is being processed. You're wrong. The include() and require() statements are only evaluated when they are reached in your application code, so there is

Re: [PHP] On large application organization [long and possibly boring]

2005-01-07 Thread Josh Whiting
> If I have a large app what is the difference, other than having a very > large file, of doing this > > switch($action){ > /* several dozen cases to follow */ > case "foo": > writing out all of the code > break; > } > > and this > > switch($action){ > /* se

Re: [PHP] On large application organization [long and possibly boring]

2005-01-06 Thread Jamie Alessio
Correct me if I am wrong, but includes (and/or requires) will get all of the code in all of the cases regardless if the case is being processed. You're wrong. The include() and require() statements are only evaluated when they are reached in your application code, so there is a big difference betw