Hello,
> This is an great proposal, and of course having better tutorial is > always great. I would recommend though starting with a plan for the > tutorial - i.e., what it would cover, etc. - like table of contents, > with short description of each item, so we agree on what is going there. > Once we have a good plan we could take it from there and maybe also > solicit help for particular topics/chapters. How do you propose we start working on this? Should we get either a repository on git/github with a tutorials section or maybe a wiki install of some sorts? > > I would rather stay away of defining specific extensions or ways to do > things as "a must". There are many ways of doing things, and many > solutions depending on particular setup and use case. For example, I > think in generic tutorial would be better to explain how caching works, > what are data caches, bytecode caches, page caches, etc., how one uses > them, and then use APC as an example of the implementation. Just saying > "APC is a must" it not really a correct approach - there are times where > APC is not the right solution, and there are other implementations for > both bytecode and data caching. You are right, I've totally forgot about XCache, eAccelerator and so on. And yes, we shouldn't target APC as a must, but rather have a section for performance improvements where we could point them out and give some links to people so that they can dig out info on about them. > I think content on SOAP belong to SOAP part of the manual - where SOAP > extension, etc. lives. Of course, generic tutorial can explain what > webservices are and refer to particular parts of the manual for specific > ones. Well we should have a section for web services, explain them a bit, provide some basic demos and then give people links so that they can read more about the it. > What FIG is standardizing is a nice work but I do not think php.net > should be promoting any specific code style or API or such. We can have > a reference to FIG work as an example of a standard that organization > could use for their best practices, but I do not think we should > prescribe it and make an impression this is the only right way. FIG is just one group that I know of, composed mostly of frameworks and libraries that tries to get traction. I'm not saying to promote FIG only, some might just not like them. By having a section that links to them and their effort, as well as any other similar groups, would help (new) people find the information faster and not reinventing the wheel. > "DB usage" is a very broad topic. Specific advice would depend a lot on > what your requirements are, what your environment is, what you actually > need to do with the db, etc. If you just need basic CRUD - any SQL > tutorial plus mysqli manual pages will do it for you. If you need > something more - please define what is that more. That's why a open collaboration platform would be useful. We should not aim to provide 100% coverage for all topics but we could have material for basic ops like getting a form to/from DB, send users to PDO/MySQLi for more functions. Definitely, php.net shouldn't display a SQL tutorial for advanced SQL operations but we can include small things like CRUD operations with a database. Also, maybe we could have polls to see what people are looking for mostly from tutorials so that collaborators could pick up the topic and write something up. > I appreciate your enthusiasm and I do agree that the tutorial portion > of the section needs a rewrite. However, I disagree with much of the > content you propose. We should stay away from frameworks, PHP fig, > and ORMS in the manual. What we really need is a way to teach basic > PHP mechanics to a new user without teaching them incorrect or > outdated information. Right, having outdated information is worst that having no information as well. Maybe I should explain this better. We don't need to have tutorials about specific frameworks. That would be the job of the frameworks themselves to do. It would be nice to have a place for new people to learn about frameworks, what they are good or bad for, in general, then just hand out links to the various frameworks out there. Fixing the lack of knowledge about them should be the target. ORMs are as bad as their user is. They can be very powerful but they can also backstab you when you least expect. I'm not saying we need to promote them as de facto standard for DB operations but since most frameworks have a place for them we can mention them as well, with both their goods and bads, again, in general. The whole point for this would be to promote the language features as well as the work done by various groups so that those interested in the language or those that seek out to improve their skills don't have to waist hours in searching for information, which can be wrong some times. Instead they could just go to php.net and get/request the info they are searching for. Best regards, Florin ---- Florin Patan
