Jochem Maas wrote:
> Dan Trainor wrote:
>> Hello, all -
>>
>> Being still fairly new to PHP, I thought I'd ask a few more questions
>> and get on to the right track here, developing correct coding habits
>> before I start to teah myself incorrect habits.
>>
>> One of my biggest questions is how to go about writing an application
>> that uses a single file, i.e. all my html ACTION='s would go to, pretty
>> much, $_SERVER['PHP_SELF'].
They would then be sending the data to each HTML file, not to one big PHP
script.
It's MUCH better to not create that giant choke-point of a single
monolithic PHP script for all data-processing, if you ask me.
That giant script won't scale up well, and you'll find more and more cruft
accumulating in it to handle weird cases, and, in order to get GOOD
modularized code out of it, you'll essentially be loading in all the code
to process dozens/hundreds/thousands of files, when you really only need
10%, or even 1% of the code you are loading. That's just Bad Design, if
you ask me.
>> From what I understand, I make a flat file (flat, as in, not using OOP
>> at this time), and then make one large procedural flow, flipping
>> "triggers" at various points to tell the script at which "stage" it's
>> at, something like the following:
What you are describing, with all the if/else stuff, or without, could
easily be done with or without OOP or Procedural programming.
They are completely independent decisions.
>> if ($a = 1) {
>> // do first thing
>> } elseif ($a = 2) {
>> // do second thing
>> } elseif ($a = 3) {
>> // do final thing
>> }
Be sure to use == instead of = there... You'll get real confused real
fast otherwise.
>> Now, that all makes sense, but I'm wondering if it's the "correct" thing
>> to do, or would I be better off swapping out "// do x thing" for a
>> require() function to split things up into different files, calling a
>> different set appropriate for the "step" that we are on.
I think you'd be better off putting the code to handle HTML file X in file X:
<?php
//Process form submission here.
?>
<html>
<body>
Present form and/or results here
</body>
</html>
As a general rule, when I process a form for the user, I provide them the
same form again, with a status message and a request to double-check the
submission.
You'd be amazed how many people fill out a form quickly, and then review
it slowly and go "Duh" and re-do it, increasing the quality of your data.
Oooh. I just realized that maybe you were referring to the if/else stuff
just to handle the one single form, in all its variations:
Initial presentation with NEW item,
completion of NEW creation,
editing existing item,
notification of successful completion of editing
I believe it's a GOOD THING to put all that in one file, with the if/else,
and to NOT bother with the include files for things like the <form> etc.
I tried the include style for that, at first, but found myself messing up
when I tried to edit the form, or the processing or whatever, and would
too often mis-type my global search and replace in one but not the other
and...
My general rule of thumb is to use an include file ONLY when I would be
typing the same exact (or template-like) code twice, and ONLY if the code
is more than a couple lines. If it's only a couple lines of code, the
include doesn't "save" me anything in typing.
Exceptions:
Database connection goes in an include.
A font function (if you're not using CSS yet) is in my global include.
A spaminator function to obscure emails is in my global include.
These are all only a couple lines, but the db-connection needs to hide the
password, and the font() thing needs to be used on every TD (grrr!) and
spaminator is too likely to need a swift change to beat the harvesters in
the arms race.
But for processing a simple form, a single PHP file to handle all aspects
has worked best for me, because:
1) When I want to add a field/input, I change only one file (and the db)
2) When I rename some field, I change only one file (and the db)
3) I can structure it to use only one (1) <form> for insert/edit, so the
HTML for that form only exists in one place
4) If something goes wrong, I don't have to dig through a half-dozen files
to find the offending code. 99.9% of the time I know it's *GOT* to be in
that one file, if that one form is the only one mis-behaving.
Even though I understand OOP very well, I really would not recommend a
beginner to use it for "real" code on a site. Sure, experiment with it
and learn, but stick to procedural at first.
There's a reason why the construction industry has a lot more builders
than architects... Stick to the easier procedural stuff until you're
experienced enough to become an architect.
Honestly, for your basic PHP form in/out site, I'd always stick to
procedural.
If you need to release a Module for others to plug into their sites, or
you have an extremely large site with more than 2 or 3 programmers, hell
yeah, go for the OOP. But for a solo job of a single site, you're just
adding complexity and more typing for little benefit for MOST sites.
Modular procedural code, well-written, will out-perform OOP and be even
more maintainable simply by having fewer lines of code in which to make a
mistake, if you know what you're doing.
If you don't know what you're doing, you're going to have Bad Code until
you get more practice, and that's all there is to it. :-)
>> This may sound like a silly question, but like I said, I feel that I
>> should get myself off on the right foot as I start to do stuff that is
>> more infolved.
>
> for a 'newbie' you state a decent 'plan' - thats good. there is nothing
> intrinsically wrong with your approach but it may become a bottleneck when
> you applications start to grow, that is the main reason for trying to
> split code up into modules/files/whatever.
>
> again there is nothing wrong with a purely procedural approach as apposed
> to OO. both methods allow you to create spaghetti if you want ;-).
>
> a few tips (maybe):
>
> 1. dont let you files get too long - it makes them difficult to read
I agree, mostly...
But, for example, if you've got well-indented code with, say, a GIANT html
FORM in it, and there is line after line of INPUT tags, it's no harder to
read a 10 line form than a 100 line form, if it's indented and all
boiler-plate.
Shoving that form off into another file with an include doesn't hurt, but
it doesn't really "help" all that much either, so I wouldn't bother.
Unless you use the same form in two places, and than I would suggest that
your code design is flawed, and you shouldn't NEED that form in two places
if your code was correctly structured.
> 2. get religious about CS (coding standards), decide upon a CS for
> yourself
> and stick to it - it make code easier to read. http://pear.php.net is a
> good place
> to get ideas on CS
> 3. focus on readability and maintainability - let speed be a secondary
> concern (at least for now)
Speed should ALWAYS be a secondary concern. Worry about speed when you
have a speed problem, mostly.
Until you're very experienced, you'll end up wasting a lot of your time
coding stuff to be "fast" that is completely irrelevent how "fast" it
runs.
> 4. don't get too hung up on webapplication paradigms
> (front-controller,MVC,whatever), but look at what other people do also.
> (try http://phppatterns.net and http://sitepoint.com for more info on
> those)
> 5. take time to think about _your_ application structure, and how you
> would
> logically break it apart.
> 6. tackle one piece at a time.
> 7. let others review your code if you can (that's not an invite to post
> your complete codebase to the list ;-).
Hmmmmm. It *MIGHT* be an interesting forum somewhere/somehow to have a
"Code Review" site/forum/list for the express purpose of people posting
code, and tons of it, for critique...
I know I'd subscribe and post, at least for awhile, to check it out...
> 8. if your code works, it works, right? who is to say your way is
> incorrect.
> 9. break it down, break it down. keep the bits of code managable.... that
> one
> reason I prefer OO - I find it much easier (& neater) to encapsulate
> functionality
> into a class that a function (or set of functions).
> 10. nearly all of is personal preference, most of the rest is
> ReadingTheManual
> and being consistent in your coding practices/style (at least within the
> scope
> of a single project - you practices/style will adapt/mutate as time goes
> by).
> 11. and the eleventh commandment: COMMENT YOUR CODE (maybe check out
> phpDocumentor).
> I dare you to try for 50%comments/50%code, it does not matter how 'bad'
> the code is
> if its that well commented anyone should be able to maintain/change it -
> thats
> a good thing - especially when the anybody is you 18months from now :-).
The thing is, out-of-date documentation, or documentation that provides no
added information about the code is more of a problem than a solution.
I cannot count the number of times I've seen code like this:
/** foo (void) : function foo
* Does foo and returns the result
**/
function foo(){
/* Insert spaghetti code here */
}
Hello?! What *GOOD* does that "documentation" do?
What always seems to be missing, to me, is the nuts and bolts of how to
write GOOD documentation.
Anybody got a good reference to something like Documentation Rules such as:
Any jargon or technical term being discussed cannot be used as the
description of the term. IE, no self-referential definitions.
(see example above)
I'd really like to be able to recommend a reference of this nature to
Beginners.
--
Like Music?
http://l-i-e.com/artists.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
