Maugrim_The_Reaper wrote:By way of suggestion, building a full application (not a feature creeped mutant, just something simple and elegant) and using it as the base for all chapter examples and tutorials would be very useful. Give readers a sense of accomplishment, and also have a common strand to all (well, most source code) that let's readers know the context of example easily. Too few books out there which explain the language and stuff the experience/confidence building app tutorial at the back, or just leave one out altogether.
I've never read a Sitepoint book... Same idea?
Just on something Roja noted earlier. I'm not going to push it very hard, but would it not be considered prudent to introduce very simple OOP concepts from the get-go? The problem I have with the procedural first approach is that, IMHO, it sucks. You give the reader a whole body of knowledge, that lets them get started quickly, but you leave the entire OOP learning till some later chapter by which time the reader is already steeped in procedural thinking - and inadvertantly dump a massive paradigm change on the reader. I really dislike such an approach. What's wrong with basic OOP use, within the confines of simple procedural scripts? Get the reader familiar with the concept, the usage, the potential advantages, and get the paradigm across quickly and simply. It's too big an area to put off for Chapter 30+.
Oh, and since I haven't mentioned it directly I'm up for some writing so count me in.
I agree with the OO. We don't need to teach them how to write classes and stuff at first but we could tech them how to *use* classes. Classes can be used procedural code very easily. For example, JPGraph or PDF classes... from the procedural point of view you're just issuing a list of commands.
If the user is familiar with the idea of instantiating an object and doing things with it then they will prhaps have a better grasp of what exactly they're trying to acheive when they learn basic OOP coding themselves. I belive we can do that whilst still meeting Roja's request I'm more keen to go by popular vote however (the way we've always done things around here).
Another thing to cover in the book - regex and form validation.
Someone wanna summarise our list of contents again thus far?
I'm just gonna have a fiddle around with writely and see how useful it could be to us. Never used it before. I'm wondering how quickly it runs because my PC struggles with DHTML if too much is going on (it struggles really badly with Flash).
Hmmm... another approach. We have one or two editors who both use the same word proccessing software. Chapters can then be written to a forum (or wordpress because you can easily add multiple editors!!) somewhere like this and editted online before someone comes along and takes what's seen to be a finished version and puts it into the actual document. This means we don't have heaps of people editting the same document. Better plan?
Broadly speaking, Subversion would appear to be an invaluable tool. Most of the writing would (I suspect) be initially plain text, prior to editing/formatting - but the final product should be versioned. A tool like writely, or some other online forum would be most suitable for proposed text where peer review and comments would be sought.
There's also the matter of a final format? Are we aiming for a specific format, or numerous ones (PDF, HTML, etc.). There are some very good generic format open to being translated to output formats such as these - e.g. Docbook XML (lot's of others).
You know, since we are talking about walking through the teaching from newbie to advanced, why can't we teach both OOP and Procedural at the same time. Small snippets of code, shown procedural and then OOP. Let the user choose what they like as they learn. Then, at the end, they can have one big procedural app or one big OOP app (or, if we did our jobs right, a complete app with a mix of the two). Since we are not talking about advanced stuff early on, and I have seen some really good, simple examples of basic classes, structures and implementations, I see no reason (save for space on the page) why we wouldn't pursue teaching both.
Letting the reader decide their approach is a great plus. It will encourage the reader to develop their own sense of programming penmenship (sp?) and style, leading to customization. I think it also allows for the ability to understand more at an easier level.
As for teaching OOP and Procedural at the same time, I don't see an issue with this. The basics of classes are just as simple as declaring a variable (or just as complex?). The way I see, OOP basics should be right up there with the declaration of strings, arrays, integers... just perhaps in a small section of it's own.
I hate to be Mr. Boring Brass Tacks (who has not piped up until now ), but how about a Chapter Outline and then writing Overview/Summaries for each Chapter. You can divide and conquer and you can always rearrange later. So far I have seen:
Starting Steady with;
* History of PHP and What it's for
* Installing it and generally getting up and running (Need to mention apache/IIS at minimum)
* (I feel a description of the client-server architecture is vital)
* General Programming concepts (with explanations of technical terms, e.g. "syntax", "semantics")
* Basic PHP coding (Hello world, assigning variables, GET/POST, loops...)
* Functions
Moving onto possible issues;
* ini settings and how they might affect you when using different servers (the evils!!!)
* Debugging techniques (basic -- echo, var_dump(), print_r(), exit() etc)
Getting into more practical stuff;
* MySQL/Postgres
Advanced;
* Basics of OOP (and differences in PHP versions)
* A practical OOP example start-->end
More practical stuff:
File uploads
Image Manipulation
String hashing (also can be taught in authentication)
Session Management
Form array processing
File manipulation
...and every other thing that fits into "Why don't this work?" category on these forums Wink .
I just remembered something that would be very, very helpful to this project.
please dontuse procedural code examples, wherever it can be avoided. Teach OOP from the beginning and let the user decide if they want to go procedural.
I am self-taught more or less and have a ton of trouble grasping OOP concepts mainly because every tutorial I find is procedural.
I do not want to start a flame or topic war about procedural vs. OOP so I beg an admit to delete every post associated with every war stemming from this one, including this one.
The point is, there are not enough tutorials or books that teach OOP from the beginning and that is how I think things should be.
More and more, as I write more code, and learn more things, BY MYSELF, I realise that using OOP techniques is ultimately more useful, IMO, than procedural pages.
Too many tutorials neglect this, I do not think that this one should be similar.
Eventhough the pulse in the development community is toward modular OOP, personally I still think there is a place fro procedural code. To maintain a flame-free thread, we should probably not get into the OOP vs. Procedural debate here. Maybe as a contributing community we can vote on whether there is merit to including it or not? Not a 'Why do you think we should/shouldn't' but a 'Should we' type of vote.
Last edited by RobertGonzalez on Mon Jul 10, 2006 2:33 pm, edited 1 time in total.
Everah wrote:You know, since we are talking about walking through the teaching from newbie to advanced, why can't we teach both OOP and Procedural at the same time. Small snippets of code, shown procedural and then OOP. Let the user choose what they like as they learn. Then, at the end, they can have one big procedural app or one big OOP app (or, if we did our jobs right, a complete app with a mix of the two). Since we are not talking about advanced stuff early on, and I have seen some really good, simple examples of basic classes, structures and implementations, I see no reason (save for space on the page) why we wouldn't pursue teaching both.
erm..yeah...new rule..don't post in this thread unless you've read the entire thing..tempted to add that to my post...if you can't be bothered to read what's been said don't be bothered to click reply I still love ya
I think we're going a bit overboard if we show an OO example for *every* procedural example. We're also overwhelming our poor newbies programmer. I don't see an issue with teaching procedural first providing we introduce OOP early enough and not as an afterthought. Let's not forget where PHP came from and the simple things that some people are wanting to acheive with it. Add to that the number of open source projects filled with legacy, procedural code....
well, I'd go with mixed style, i.e. use OOP where appropriate, use procedural where appropriate. No procedural vs. OOP comparisions. Also I would like to introduce in the book the following maxim: 'Those who discuss OOP vs. procedural are stupid.' and put much of the stress on it.
While not entirely true, in the long term it would lessen (I hope) the flame-warriors population