Cons and Pros of a new PHP 5 framework - Why another one?

Though we are good old friends with PHP since PHP 3 days and I made my living on it, I always considered myself as a student rather than an expert, and always enjoyed to learn from other people's experiences. When I faced a problem, I found more logical to look for the footsteps of others before trying to re-invent the wheel. This helped me develop a point of view on where to use the existing ones, where to manipulate them and where to design the wheel from scratch; "how to think" for short.

Troughout my programming life, I've encountered several problems, worked on various projects both by myself or as a member of a team, and besides my own experiences, I had the chance to hear how other programmers approached to a spesific programming or logical problem, even most of them were daily and recurring ones, especially for themselves!

I strongly guess the first application framework started as a result of the same feeling: We do some common things in every new project, and most of us use some re-usable code and write wrappers around them if we are experienced enough, but to put them as a whole is always there as a new problem with each new project, as the scope of the new project is seldom the same as the previous one, and if your last project took -say- eight months, if you are a person who does not remember everything he has done in his whole life like me, this would also mean another learning curve, even if the teacher is yourself and the curve is relatively short... and needless...

Having past this point, some years ago, not very long after PHP 5 started, I started to look for a good basis which would be good for projects at any scope, and saw with great happiness I wasn't alone with most of my thoughts, and with great vision, people already started to code some frameworks for PHP 5 to take advantage of the object-oriented features to have a more re-usable code, but helas, it was still PHP 4 days for anyone else. If I'd use their frameworks without any objection, I still needed to look for the server capabilities first, and most of I coded, I needed to deploy, so I needed to go with my own solutions for some time more.

Then, some day I heard of Ruby On Rails and the MVC pattern. That sounded logical, but I couldn't take another fight to use Ruby and advocate it, and not so long after, I met CodeIgniter. I feel I have almost the same opinion on it since my first day: Man, it was something usable! It also worked with PHP 4 and let the programmer keep everything in shape. Most important: not too hard to dive in. This was definitely something new for me, and as CI is one of the most popular frameworks nowadays, I guess it's valid for so many other programmers.

I believe CI was a kicking-point for a couple of other frameworks as well, however by time I felt it lacked some many important features for me as the life continued on, while those points might be considered as "features" for some others. Just to name a few one, they had good form handling and validation features, but not quite separated from the rest of your programming logic, as they wanted to validate any data by principal, not only forms, whereas in the real life, most of the validation tasks are for the data coming from the forms. Another one was that they didn't want to use code generators, most probably as they wanted to leave the coder free with their decisions, or perhaps for another reason. But for me, it's an advangate rather than a disadvantage to use them, as long as it's left to your choice.

So to name them as well, I also met Symphony which was an answer to use a code generator and also Cake. Cake was strict, Symphony was better, and lastly Zend.
I just want to ask a simple and honest question and close the Zend case: If it wasn't named "Zend", really how many people would use it?

So within time, I came to a point where I was pretty sure about what I really needed from a framework as a programmer:
- Documentation (Without it, I can't understand it's really not rocket science.)
- Performance. (It is of the essence especially when you deal with sites with high traffic.)
- Usability. (We are humans. We will use it, not robots.)
- Separation of logics: A required MVC implementation to force me write good code. I'm a very lazy person and if I have the db connection within the controller, I'd tend to use it.
- In addition but not required: Separation of form and validation logics: My forms and my validators "need to know about each other". If I will "define" a form, my validator must also have capabilities to use those definitions, but this must be in a very libertarian way: To do that, I must not define also the layout of the form within my general wiew, but let people use my form components however they wish within their design, even they can be automatically generated.
- As a consequence of the previous: The programmer must not be forced to use any template engine, but still preserve the rights to take advantage of a good caching mechanism.
-Ajax Capabilities: A PHP programmer's almost dead without Ajax. He needs a hand.
- A code generator with all ajaxified good pagination, sorting and validation capabilities.
- A good library for any task (That I don't have with 1.0 release)

Those are mine standards that need to come out of the box, and I could hardly see them together within another framework . I believe I have achieved most of the points above with the earlier 1.0 release and all by myself and if you, the programmer reading those lines will contribute, we may have much much more.

By the way, the address for the framework is http://framework.logikit.net