Much of the complaints I had, also the baffling license choice when it could just as easily be released under the MIT license or whatever others there are out there.
Ah I see, the MIT license does cover pretty much everything I needed. After looking for half an hour for a decent license I thought it would just be easier to write my own. MIT license will be included in the next push.
What I am thinking of is pretty much the Do What the Fuck you Want to Public License, but only keeping that license itself. It's hard to find that...
* Uses arcane define() statements to set configuration
* No ORM -- provides a slim wrapper around mysqli
* Uses singleton classes -- makes any potential unit testing very cumbersome
* Rudimentary routing system -- doesn't support anything beyond /$CONTROLLER/$ACTION/$ARGS...
* Rudimentary templating system that does simple string-replacement -- doesn't support looping or conditional control structures
* Database::safeQuery() is anything but safe, in fact it's quite dangerous -- prepared statements should be used at a minimum rather than blind string replacement (see mysqli::prepare())
This seems like it was an interesting learning exercise for the author, but it's not much beyond that.
The next step would probably be to make it PSR-1 and PSR-2 compliant (note how public/private accessors are absent in many places, and indentation swaps between spaces and tabs), and make it fit within the composer packaging system.
True. Logging could be implemented quite easily using events, unit testing, well, I have no idea. I don't unit test that much, and I know, good practice and blahblah, but I tried and do not see the benefits for my projects. (Generally my projects are quite small)
I am not defending this project, I have complaints about it myself but some of your issues are ridiculous.
> Not a composer package
Thats like saying "its not web 2.0" frankly. If you can't manage to checkout a library/framework and make use of it without being reliant on a specific package manager, you shouldn't be writing software.
> Uses arcane define() statements to set configuration
I don't think you know what arcane means.
Also, using constants to set application options can work very well if used properly.
> Uses singleton classes
I'd much rather a project that makes smart use of Singletons than the ridiculous SuperMegaObjectFactoryConstructorHelperFactoryFactory shit that is apparently the "in" thing.
> make it PSR-1 and PSR-2 compliant
PSR is a fucking joke. Code consistency within a project is important. Between a million different projects? Not so much.
The "goal" of PSR has never been "hey heres the best way to do things". Its purely an exercise in documenting the MOST COMMON way a set of projects do things.
> make it fit within the composer packaging system
Also, the author must only eat fishes on fridays and must devote his sunday to the FSM.
Composer is not jesus, PSR is not the bible. Stop acting like they are magical items sent from the heavens.
> Thats like saying "its not web 2.0" frankly. If you can't manage to checkout a library/framework and make use of it without being reliant on a specific package manager, you shouldn't be writing software.
Honestly, I would not start a new project with a library that does not support composer if I could help it. Supporting composer is easy and makes my life easy - not because I /can't/ checkout the library, but because I don't have to store the library in my VCS and I don't have to bother with transmitting it back and forth between servers or dealing with Pull Requests with massive file changes whenever I update the library.
* I don't like composer. This isn't some big framework everyone should use because it is good practice, or because it is such a great thing. It's easy. The way I like it.
* define() is a great way for < 4 variables. Seriously, whats the point of creating a whole config class when I could just execute 4 times a define(); Heck, maybe I should put them in the same file!
* Jep, MySQL only. As I said, this isn't some cool framework which can be used everywhere. It's simple. Very simple.
* Whoa, those singletons aren't needed. I'm not quite an expert on unit testing, but I am sure unit testing won't be much harder this way.
* As of the rudimentary routing, you are right. I probably should support custom routes in some way.
* The templating system blows. But again, one doesn't need more when setting up a simple project.
* Database::safeQuery() is indeed not great. I'll make it an issue. Someone pointed it out earlier to me and I forgot to fix it the right way. It used to be even more vulnerable. Shame on me.
It was an interesting learning experience, and I don't think I'm done yet. But I thought maybe some people think it's interesting, and it turns out some do. (See the number of upvotes/stars/comments)
PSR-1 and PSR-2 is not my style. Indentation sucks, I'll change that, but I will not change everything into PSR compliant code. Again: simplicity. I am pretty constant in my code style, so that can't be an issue.
I'm really glad you replied. I'm not trying to be a dick, but I'm comparing it other frameworks that I'm familiar with.
I disagree quite strongly with not trying to adhere to composer packaging guidelines, since it's common to many PHP developers (especially those on HN) that using it shouldn't be an issue.
Also, tying into composer would help you as a developer as well -- there is a very large body of packages available that are quite stable and reliable.
A lot of what I went over is mostly semantics/preference, however those are important to me. No shame, no guilt -- just constructive criticism.
Sure, no hurt feelings ;) I hope I didn't sound like I thought of you like a dick in my previous comment, that was not my intention.
I'll look at composer, that certainly looks promising. (But quite hard too...)
I'm always in for some constructive criticism, you do have valid points. But the thing is this framework isn't designed to be professional, it's designed for a simple copy-paste-program workflow. (Or in this case: 'git clone'-program). I never intended to write a great framework that can be used in any situation and is exactly following the standards to the last indentation, so that's not where I'll put my effort into. Big mistakes, however, like the Database::safeQuery(), are worth fixing. At first I didn't have events too, until someone alerted my that might come in handy, so I added it, and I am sure I'm going to use that one a lot.
I don't want to jump on to you too hard since I literally have my own custom PHP framework open in the other monitor, and sooner or later I might have to pay the price for having it posted here, but I think one of the problems with this is it's small, but not small enough to be micro - and it doesn't have one of the primary advantages of a framework (especially microframeworks) which is easy extensibility.
Most of the problems people have listed could be solved easily with the ability to import packages and manage autoloading through composer and psr-4. If you're going to create your own templating system, you're going to have to put forth a pretty decent argument against using Twig, for instance, which has autoescaping, inheritance, functional extensions and a sandbox. I think probably you've done what a lot of people do and tried to reinvent too much - as a result, the framework is not modular enough to meet various other users' needs. It does work, I don't doubt, but other things work better, and this is an issue facing anyone building a PHP framework.
Some documentation letting us know why you built this, how to use it, what it's strengths and weaknesses are compared to other frameworks, etc. would certainly be useful, as would a more standard open source license (MIT.)
Thank you so much. First positive comment I read today :P The simpleness is exactly what I had in mind when I wrote it. Just git clone it and start writing, because that's what I needed personally. And then I thought: 'Hey, I might as well share it'.
Note: I tend to use frameworks largely to enforce safe db queries. IIRC, Kohana does all the needed escaping transparently. Might seem like an overkill but it is better than relying on the discipline of individual developers.
Kohana seems to have the structure in about the same way, but is more complicated and has some basic modules, whereas Kamele does not.
Kamele does have a nice Database class that handles the PDO-object in a MySQLi-like way of approching the object. Especially the Database::safeQuery() function will be interesting for you: https://github.com/goldenice/Kamele-Framework/blob/master/sy...
29 comments
[ 5.5 ms ] story [ 61.0 ms ] threadNot sure why the documentation isn't included in the readme.
>It's a PHP framework. It works. Cool.
Tells me nothing.
I'm sorry, I will include this link right now in the README.md
Using proper namespaces would be great, the `System` namespace will probably collide with other projects. `Kamele\System` would be much better.
Using PDO would be much better than the `mysqli` functions.
Where are the unit tests?
What I am thinking of is pretty much the Do What the Fuck you Want to Public License, but only keeping that license itself. It's hard to find that...
* Uses arcane define() statements to set configuration
* No ORM -- provides a slim wrapper around mysqli
* Uses singleton classes -- makes any potential unit testing very cumbersome
* Rudimentary routing system -- doesn't support anything beyond /$CONTROLLER/$ACTION/$ARGS...
* Rudimentary templating system that does simple string-replacement -- doesn't support looping or conditional control structures
* Database::safeQuery() is anything but safe, in fact it's quite dangerous -- prepared statements should be used at a minimum rather than blind string replacement (see mysqli::prepare())
This seems like it was an interesting learning exercise for the author, but it's not much beyond that.
The next step would probably be to make it PSR-1 and PSR-2 compliant (note how public/private accessors are absent in many places, and indentation swaps between spaces and tabs), and make it fit within the composer packaging system.
* No unit tests
> Not a composer package
Thats like saying "its not web 2.0" frankly. If you can't manage to checkout a library/framework and make use of it without being reliant on a specific package manager, you shouldn't be writing software.
> Uses arcane define() statements to set configuration
I don't think you know what arcane means.
Also, using constants to set application options can work very well if used properly.
> Uses singleton classes
I'd much rather a project that makes smart use of Singletons than the ridiculous SuperMegaObjectFactoryConstructorHelperFactoryFactory shit that is apparently the "in" thing.
> make it PSR-1 and PSR-2 compliant
PSR is a fucking joke. Code consistency within a project is important. Between a million different projects? Not so much.
The "goal" of PSR has never been "hey heres the best way to do things". Its purely an exercise in documenting the MOST COMMON way a set of projects do things.
> make it fit within the composer packaging system
Also, the author must only eat fishes on fridays and must devote his sunday to the FSM.
Composer is not jesus, PSR is not the bible. Stop acting like they are magical items sent from the heavens.
Honestly, I would not start a new project with a library that does not support composer if I could help it. Supporting composer is easy and makes my life easy - not because I /can't/ checkout the library, but because I don't have to store the library in my VCS and I don't have to bother with transmitting it back and forth between servers or dealing with Pull Requests with massive file changes whenever I update the library.
It was an interesting learning experience, and I don't think I'm done yet. But I thought maybe some people think it's interesting, and it turns out some do. (See the number of upvotes/stars/comments)
PSR-1 and PSR-2 is not my style. Indentation sucks, I'll change that, but I will not change everything into PSR compliant code. Again: simplicity. I am pretty constant in my code style, so that can't be an issue.
I disagree quite strongly with not trying to adhere to composer packaging guidelines, since it's common to many PHP developers (especially those on HN) that using it shouldn't be an issue.
Also, tying into composer would help you as a developer as well -- there is a very large body of packages available that are quite stable and reliable.
A lot of what I went over is mostly semantics/preference, however those are important to me. No shame, no guilt -- just constructive criticism.
I'll look at composer, that certainly looks promising. (But quite hard too...)
I'm always in for some constructive criticism, you do have valid points. But the thing is this framework isn't designed to be professional, it's designed for a simple copy-paste-program workflow. (Or in this case: 'git clone'-program). I never intended to write a great framework that can be used in any situation and is exactly following the standards to the last indentation, so that's not where I'll put my effort into. Big mistakes, however, like the Database::safeQuery(), are worth fixing. At first I didn't have events too, until someone alerted my that might come in handy, so I added it, and I am sure I'm going to use that one a lot.
Most of the problems people have listed could be solved easily with the ability to import packages and manage autoloading through composer and psr-4. If you're going to create your own templating system, you're going to have to put forth a pretty decent argument against using Twig, for instance, which has autoescaping, inheritance, functional extensions and a sandbox. I think probably you've done what a lot of people do and tried to reinvent too much - as a result, the framework is not modular enough to meet various other users' needs. It does work, I don't doubt, but other things work better, and this is an issue facing anyone building a PHP framework.
Some documentation letting us know why you built this, how to use it, what it's strengths and weaknesses are compared to other frameworks, etc. would certainly be useful, as would a more standard open source license (MIT.)
If you believe in it, keep working in it though.
http://kohanaframework.org/index
Note: I tend to use frameworks largely to enforce safe db queries. IIRC, Kohana does all the needed escaping transparently. Might seem like an overkill but it is better than relying on the discipline of individual developers.
Kamele does have a nice Database class that handles the PDO-object in a MySQLi-like way of approching the object. Especially the Database::safeQuery() function will be interesting for you: https://github.com/goldenice/Kamele-Framework/blob/master/sy...