Right now what you have is an idea. When it’s ready, let people download it and decide for themselves if it’s different or better than other frameworks.
I am not an expert in ALL frameworks but I’m pretty sure Symfony 2 is event driven too.
take a look, it’s right in their description, under “Flexible”
I know it’s much more difficult to make a framework that handles ajax and non-ajax elegantly. It’s easier said than done. Ajax is not just sending a small block of html via XHR response. You can’t just have a router that looks at request and decides, hey ,this is ajax request, I will send ajax response, else I’ll send normal HTML. In the real world it’s often more complicated. Once you really start working on it, do a lot of hand-on development you will find it is not as simple as you may think now.
Anyway, good luck to you, post a link when your framework is ready.
You only get one chance to make a first impression. And trust me, I am by no means underestimating the complexity of this endeavor. But it’s not ready. It will be a few months yet before it’s even close.
Haha…I disagree (especially in software) you have unlimited attempts at making a first impression. How many times over the years I picked up CMS frameworks and dropped them a few weeks later. I started with a project called Midgard and later switched to one of the Nukes. Then Mambo, Joomla, Drupal, the latter two back and forth so many times I have lost count. Here I am today, convinced Drupal is the best there is at getting things done ASAP, with Joomla having a slight edge in terms of clean architecture. I’ve given CodeIgnitor and Zend so many ‘firsts’ I have all but given up on both for the most part.
Getting user feedback from the community will be impetus in improving your design. Otherwise, what I am willing to bet, is you end up with a system with flaws in the design, questionable API, etc. Once people start using it however, it’s very difficult to change the design. Drupal I am sure, know they could do thngs better but changing that now would deprecate 1000’s of existing modules and force everyone to re-learn, so they simply cannot change.
I tend to consider the release. i.e. if its Alpha I expect it to be rather crude, Beta a bit more polished but by no means pefected, RC ready to go with a few bugs but before the onslaught of feature bloat.
True, I think many are “scared away” or take the “I’ll let others do take their chances first” approach, but I see nothing wrong with releasing a Beta.
In fact I think releasing a Beta is a crucial step in the process. There’s no possible way I can test for all the various use scenarios.
For my own apps, they’re Alpha until I’m happy with them. Then I release a Beta (or three ). Once I’ve gotten enough feedback (subjective I know) then the RC
I’ve yet to see any app that was “final” except where the developer stopped working on it. So don’t suffer from “analysis paralysis” once you’re happy with what you’ve got.
This point might be a little bit past your current conversation, but not ALL frameworks require a database connection at start.
CodeIgniter has the option to load the database class as soon as the request is received, but like my current setup, it will only ever load the database object, when the database is needed. Otherwise, a request doesn’t even touch the database.
That said. I love CodeIgniter for it’s ease of use and what not, but I’m finding the thought of writing my own framework daunting, yet I feel compelled to write one.
I haven’t had the chance to read every single post, explaining your current framework and the reasons for setting it up, but I think at the very simplest form, an MVC framework is the way to go.
When I first looked into MVC, it was scary. But CodeIgniter made it seem VERY simple, simple enough that I could create the MVC structure very easy. The parts I struggled with was handling of data etc to make it scalable.
In the end, I simply gave up. Until now, when your post, threw my brain into, hell, lets try it again mode lol
Hope it all pans out mate, and as everyone else is saying, get some code up so we can have a fiddle with it.
I went from Ruby on Rails to CodeIgniter back in ver 1.6 of CI and found it refreshingly simple. I didn’t need migrations at the time and I felt more comfortable with pure SQL than some migration system so the CI db forge can make making your own simple migration system easy.
Also, CI makes it easy to find out if you have an AJAX request or not, to much of the chagrin of the poster on this page somewhere who said it could not.
Put that into the constants.php file in the app/config folder:
Then you can use IS_AJAX in your controller to lock down if a call is ajax or not. That simple.
Your controller method would look like
public function get_data() {
if(IS_AJAX) {
//retrieve data from somewhere
} else {
//print error that it was not an ajax call.
}
}
This sort of thing should probably be included in the base install but that is what makes CI so good, it can be tweaked to the needs of users. It might actually be something the OP wants to look into as it should be useful for any MVC.
At this point I’m working through the unit testing system. Control and view seem solid but I want tests for them to prove it. This rebuild is taking longer than any previous version of the thing for better or worse.
Using HTTP_X_REQUESTED_WITH for authentication is fundamentally flawed since it can be spoofed. Hopefully its not being used for that purpose otherwise anyone can spoof it and access actions without restrictions if no additional, server-side authentication exist. In that regards its pretty much worthless.
Well the fact that it’s an “HTTP_X_” header should be the first clue that it can be spoofed. I wish PHP had put the elements in $_SERVER that can be altered by the client in an attack in a different superglobal so that the fact they can be changed could be driven home more easily to intermediate programmers - but at this point doing so would be a backwards compat nightmare.
Any header starting with “HTTP_X_” is custom and setable by the client. In the response there’s the reverse of “X_”
No, you’re wrong. They are set by the client, but they aren’t custom. The meaning of HTTP_USER_AGENT might be under the client’s control, but the HTTP protocol defines how that variable should be used.
I said … "Any header starting with “HTTP_X_” is custom and setable by the client. In the response there’s the reverse of “X_” "
). Once I’ve gotten enough feedback (subjective I know) then the RC