Need Advice -- PHP Tutorials to Develop Quality PHP Framework

[Envrin]

Hi everyone,

 

Hope this doesn't get flagged as spam, because by no means my intention, and looking for honest feedback.  I'm currently developing the third iteration of my PHP framework, which I started back in 2006, now coined Apex Framework.

 

While doing the development, I decided to put together a series of tutorials, taking other developers through the development process step-by-step, to give them a good understanding of exactly how to develop their own high-quality PHP framework.  These tutorials are quite a bit more in-depth than your typical MVC tutorials, as the framework includes things such as package management repositories, multi-language, theme library, and much more.

 

To see what I currently have, please check out the one link at:

 

http://envrin.com/tutorial

 

There's 5 tutorials in the series now available now, and the onext one should be online within 24 - 48 hours.  Since I'm now blind, these tutorials take quite a bit of time to write, so I'm just looking for any feedback I can get.  What do you think?  Are they of valuable information to you so far?  Should I continue investing time in this tutorial series?  Is there anything you'd like to see different?

 

Again, I'm honestly looking for feedback here, and not plugging my site.  I'm wondering if it's worth my time to put these together or not.

 

Thanks in advance!

[Jacques1]

I see several problems with your tutorials.

 

First off, this isn't state of the art, and you spend a lot of time reinventing the square wheel. To give just a few examples:

• SQL injection vulnerabilities can be effectively prevented with prepared statements which have been available in PHP since the early 2000s. But you rather invent your own, far less reliable security mechanism.
• Nowadays, passwords are hashed with bcrypt, and there's even a programmer-friendly API for it. But you rather invent your own, far weaker algorithm.
• There are plenty of very solid and battle-tested template engines like Twig and Smarty. But you rather come up with your own, wonky implementation.

I think this project needs an update and a clear goal. If you want to implement an MVC framework, why spend so much time reinventing low-level features which aren't even relevant? How does copy-pasting your hash algorithm or your template engine help me better understand MVC?

 

Secondly, I'm not really sure who the audience is. For a beginner, this is far too advanced. For a professional, it's not good enough – they'll be more interested in learning frameworks like Symfony or Laravel. So you're targeting a narrow group of ambitious amateurs or semi-professionals who are ready for advanced topics but somehow aren't ready for the established frameworks. This isn't necessarily wrong. But you should be aware of it and maybe adjust your tutorials accordingly. Is a step-by-step guide really the right format? Personally, I think I'd be more interested in an explanation of what MVC actually is than in following “Please-copy-file-foo-into-directory-bar”-style instructions.

 

Last but not least, the presentation is far from optimal. In 2017, I really don't want to download code as plaintext files and go through a registration procedure to get the whole software. There should be a (free) GitHub repository, all code (and maybe the tutorials themselves) should be under version control, and inline code should have proper syntax highlighting.

[Envrin]

Thanks for the feedback, and much appreciated.  Let's see if I can answer everything.

 

Yes, you're correct, too much for beginners, and advanced users aren't going to waste their time with it.  I guess it's geared more towards the intermediate -- the guy who is done all the beginner stuff, and is that "ok, now what?  how do I get better?  what should I develop?" phase, or simply wants to hone their skills when it comes to structure, cleanliness, efficiency, security, writing a proper database schema, etc.  Maybe I'm wrong, and the pool of developers is too small compared to the time investment.

 

Regardless, this framework is getting developed, as I need it.  For one, I don't really like using 3rd part frameworks, as I prefer to know how my systems work inside and out.  More importantly, I went blind about 9 months ago, hence reading and sifting through third party code is quite difficult.  I need all the code in my head, so when a bug fix / modification comes up, I know exactly where in the code to go.

 

Nonetheless, once Apex is completed I'd be happy to put it up against the big boys like Laravel, Symphony, and even other non-PHP frameworks.  Maybe even have a competition, one (or more) developers each use a different framework, same set of project specs, and have say 24 hours to deploy a live system.  I'm sure at the very least Apex would stand up to them (once complete), if not beat them.  Time will tell I guess.

 

Regardless, I need to develop Apex for my own personal projects at the very least, so figured while doing it might as well try to help a bit by documenting the process from start to finish.  Instead of just a tarball on someone and say, "ok, learn this", I thought maybe there were some developers who would benefit learning it in smaller chunks, and more of a step-by-step process.  Again though, maybe I'm totally wrong and off base with that.

 

Yep, of course will be uploaded to Github once complete.  For now, the zip and tar archives are available at the top of every tutorial, which consist of the full system as is after each tutorial.

 

Thanks, and you're totally right about styling the code blocks.  My partner is out of town for the next week, but I'll take care of that when he gets back, since I'll need to borrow his eyes for it.

 

Thanks again for the excellent feedback.  Much appreciated!

[Jacques1]

For one, I don't really like using 3rd part frameworks, as I prefer to know how my systems work inside and out.

 

If that means you're also against using third-party components in your framework, that's a big mistake.

 

Knowing when to use which library is at least as important as being able to produce new code. Many problems simply have already been solved, and a lot of those solutions are far better than anything you or I will ever come up with. Projects like Twig have accumulated a lot of expertise and manpower and many years of testing. It makes no sense to reject this and instead spend a lot of time on a new solution which is objectively worse.

 

If your goal was to specifically teach the development of template engines, sure, it would be useful to start from scratch. But in your case, it's just a component which you want the user to copy into their directory structure.

 

 

 

Nonetheless, once Apex is completed I'd be happy to put it up against the big boys like Laravel, Symphony, and even other non-PHP frameworks.  [...]  I'm sure at the very least Apex would stand up to them (once complete), if not beat them.

 

I'd be careful with those big promises. Like I said, the current code is far from current best practices. It can certainly be turned into a decent project if you invest enough time and effort, but it will not reach the level of a professional framework. That's just illusionary.

 

Again, I think there should be a clear (and realistic) goal. An internal tool or eductional project? Sure. A super-secure Laraval killer? Definitely not.

[gizmola]

Regardless, this framework is getting developed, as I need it.  For one, I don't really like using 3rd part frameworks, as I prefer to know how my systems work inside and out.  More importantly, I went blind about 9 months ago, hence reading and sifting through third party code is quite difficult.  I need all the code in my head, so when a bug fix / modification comes up, I know exactly where in the code to go.

Hi Envrin. First off, I am sorry to hear about your health issues and the loss of your sight. I admire your ambition and will to battle through adversity. I can't imagine and hope I won't ever have to confront what you are confronting.

 

I hope that this won't come off as insensitive, but that issue should have no place in your discussions of your framework. Right at the start of the first tutorial you bring it up. I'm not sure how that is going to convince anyone that they should read your tutorials or use your framework.

 

Your stance on using components, albeit for an understandable personal reason is a giant step backwards in the state of professional quality php development. It took a long time to get namespaces, autoloading standards, a dependency resolution tool like Composer and a component library registry like packagist established, but now that those exist, any framework that isn't at least embracing those, as well as full and complete unit tests, can not be taken seriously by anyone.

 

Your framework will not be competitive with Laravel or Symfony, because those projects have a clear and understandable design philosophy based on other similar projects, thousands of man-years of code, and are rich with design patterns, utilize best practices, and have giant communities with skin in the game, as they are making a living using those frameworks to build systems and sites.

 

They are not the work of a single person. Symfony for example, is a complete ground up rewrite of a framework that at the time had many users. They were willing to admit that many of the elements employed in Symfony 1 were dead ends, with signifcant design flaws. That project has a robust peer review system in place, and of course all code is done in Github where it can be tested, analyzed and debated.

 

Regardless, I need to develop Apex for my own personal projects at the very least, so figured while doing it might as well try to help a bit by documenting the process from start to finish. Instead of just a tarball on someone and say, "ok, learn this", I thought maybe there were some developers who would benefit learning it in smaller chunks, and more of a step-by-step process. Again though, maybe I'm totally wrong and off base with that.

I agree that tutorials are necessary, but let's be honest and admit that what you are proposing is simply not current or modern. It seems more like a simple home-brew CMS than a competitive MVC, and the coding practices you are using are antiquated and seem to have been derived from the php 5.0 era. You also have no code available to look at or use, making this tutorial very much a cart before the horse situation.

 

I think you'd get a lot more benefit from a code review of your framework at this point.

[Envrin]

Ok, now those are some pretty damning reviews.  Alrighty then.

First up, on second thought, totally agree with you guys on the tutorials.  Good overall concept I think, but horrible format and for now a total waste of time.  I still think it's a good premise though, and will rewrite them from scratch later, but on more of a component-by-component basis instead of in a timeline format, which is obviously unhelpful.

No, I'm not totally adverse to using 3rd party.  For example, Bootstrap, jQuery, jQuery Validator, I have a SQL parser library in there for large SQL chunks (ie. package installation files), etc.  When I integrate a WYSYWIG editor obviously I'll use ckeditor or similar, and so on.  However, I am a little picky about which 3rd party components I do include, because general rule of thumb, the more you try to mix and match 3rd party components, the more clunky and restrictive the end result is.

I know many with disagree, but I personally dislike PDO, as it seems too cumbersome for no reason.  If I was going to go 3rd party for the DB layer it would be MeekroDB which I have used before (eg. Synala).  It's excellent, clean, efficient, what takes 5 lines with PDO only takes 1 line with MeekroDB, and it's very secure.  They've done extensive testing of their own, and I've had my software pen tested as well with no SQL injection found.  My DB library is modelled after MeekroDB, and granted still needs some work on security, does work great.  Went with my own naubky dye to logging, error handling, and debugging, but also a few other reasons.

Honestly, have never used Twig, so will check it out.  I'm very familiar with Smarty though, and have used it many times (eg. Synala).  It's a great template engine, but couldn't use it for a variety of reasons, one main one being it doesn't really support specialized tags, especially not on a per-theme basis.  For example, I need to put say "<e:tab_page title="My Tab"> ... </e:tab_page>" tags in the templates, and have them replaced correctly regardless of theme being used.  Many themes format tab controls differently, and at the very least use different CSS class names.  Same goes for loads of other elements on pages.  I need to be able to grab a theme from ThemeForest, have it fully integrated into the framework within 30 mins, and have it perfectly integrated across the dozens or hundreds of templates, without having to go through and tweak each individual template due to a theme change.

--------------------

Thanks for the nudge on the blind thing, and you're right.  Will remove that, as not relevant to the content.

Also thanks for the slap about PHP 7, as I somewhat missed that whole release while trying to figure out this whole blind thing.  Read up on it, some cool new features that I'll will definitely take advantage of.  Strict type setting I'm definitely happy about, plus the additional error / exception handling, and others.

As for component vs. more standard / modern MVC format, I guess personal taste, plus other reasons.  For one, I think it's more organized, as a developer can pop into a system and almost immediately get a brief overview of what's going on just by looking at the file structure without having to sift through any code.  Plus I like to think it provides more standardization.  With the more standard MVC model developers can sway from the path more easily, so you may end up with a dozen different development styles in the same system, which can get messy.  Whereas with this, although you still have flexibility to develop anything and everything, it's more structured, again allowing other developers to easily pop in and out of projects with a reduced learning curve. .  Thar, and even with multiple developers involed in one system, the end result to the client will be a coherent, streamlined system that all looks and acts the same.  Maybe I'm wrong, but that's my perception at least.  Definitely not for everyone, but I'm sure for some people, and definitely for me.

Yep, there will of course be full unit tests available, as that's a crucial aspect.  Plus extensive debugging features as well, which aren't yet developed.

--------------------

Anyway, thank you guys very much for the feedback, as you helped force me take a step back adnd re-analyze everything.  Development will move forward, tutorials are scrapped until development is completed, will upgrade to PHP 7 standards, will have to agree to disagree buy component design is staying, etc.  Alrighty, here we go.   I'll be back with a more finished version.

Now just to find a volunteer to help with the jQuery / Javascript aspects.  I know the code, but testing and debugging is a little tough without eyesight.  Will see what I can do.

Thanks again.

 



 

[gizmola]

It's great to see someone take some blunt criticism and consider it.

 

Again, I'd like to see your code in Github or bitbucket. You keep complete control, but others can fork and collaborate with you.

 

I also think you would benefit from consideration of breaking your work into individual components with seperation of concerns. That will force you to consider how modular and extensible your framework actually is.

 

Again to be blunt but hopefully useful, you must have a component framework that utilizes composer or you might as well resign yourself to the fact that your framework will never be used by anyone other than yourself.

 

Every framework -- even old ones like Cake, have moved to supporting composer.

 

Both Laravel and symfony are Dependency Injection frameworks. Laravel is more opinionated and favors convention over configuration in many places, but I think it is very useful to reflect on the fact that Laravel started with some of the basic symfony components.

 

Your opinions on db connectivity and productivity are fine, but again, there should be some sort of philosophy in your database component. Laravel did ActiveRecord with it's eloquent ORM, while Symfony typically integrates with Doctrine2 which implements the data mapper pattern.

 

A developer's comfort level with your framework may depend ultimately with their comfort and belief in the design philosophy of your components.

 

I do think your high level of resistance to the idea of components seems like a prejudice, and "not invented here" attitude. There are probably some peer reviewed high quality components that you could drop in to jump start things for you, with no discernible increase in complexity or lack of comfort on your part. You simply might have to review a little bit of code.

 

The best components come with a full suite of unit tests.