Zoop Framework: framework PHP and AJAX

have you know about zoop framework ? let's look what it is
this is of ther details
Zones : The Zoop Front ControllerThis article is for all of those asking why zoop "limits" you to passing everything through index.php. Zoop uses a front controller. All requests are passed through index.php and then through the zone component to their final destination. There is a lot of information about front controllers: http://www.google.com/search?hl=en&q=front+controller+design+patternThe front controller design pattern has got a lot of bad press from php developers over the years. It seems like every article I've ever seen by a php developer first goes on to explain what a front controller is, gives a very simple example and then goes on to explain it's easier to just not use them at all.see:http://www.phppatterns.com/docs/design/the_front_controller_and_phphttp://www.digital-web.com/articles/web_presentation_patterns/For those who may have doubts about our use of the front controller design, you can use nearly all of the modules in zoop (gui, db, etc) without using the zones front controller. Hopefully, though, by the time you are done reading this article you will want to pass everything through index.php and the front controller and, in addition, you'll like it.The front controller has gained a lot more traction in the java world. Notice that the first 6 links in the above google query are specifically written for Java developers.Here is a definition of a front controller in my own words. A design pattern for web apps where you pass all of your requests through a single script, parse the url yourself and then use some systematic method for determining what to send back to the browser based on the url.That is a gross oversimplification but it's simple and should get you started if you've never heard of it before. In this article I am going to explain the zoop implementation of a front controller (zones) and show how it goes beyond the over simplified examples shown in most articles on php front controllers. I will show how the zoop front controller actually adds value, makes development faster, and results in better more secure applications. I am going to show parallel examples of how certain problems are solved using a more traditional php approach and also using zoop zones.I am sure I create just as biased straw man examples of the "traditional" php app as the anti-front controller people have created since I have used front controllers almost exclusively for about 5 years. I welcome a flame fest in the forum to provide more worthy examples for the other side of the fence.
Bascially the main benefit of using zones is that is provides a systematic way to structure and organize your code. A zone groups together common pages and allows you to perform operations on all of those pages collectively. It allows you to easily share functionality between similar pages.The main problem that we are going to analyze first is the problem of implementing security by default. In order to illustrate this we are going to start developing a very simple bug tracker. I will provide examples of how to implement this using traditional php methods and another example using zoop.Let's start with a simple hello world app.at this point the traditional php "application" is ahead in terms of simplicity. Our zoop app has two files an entire class, method calls, several lines of code and has to link to an external library. Whereas the traditional php app has only one real line of code. Once we go beyond hello world though things start to even up.
Now in order to move from hello world to an application login we didn't have to even add files to the project. The traditional php app basically had to be started from scratch.Notice that neither project is using a templating system. The reason for this is that I wanted to focus on zones, and not templating.Also notice that although it could post anywhere the page function generally posts to the post function. When the url http://sampledomain/zoopapp/index.php/login is requested as a GET it only looks for the method pageLogin in zone_default. If that same url is requested as a POST operation it first looks for postLogin and only executes pageLogin if postLogin is not present.For this a design pattern appears. Display the page in pageXXX, post to your own url. Then in postXXX first handle manipulating the model based on the post data. Then redirect to the next page to be viewed. This eliminates what I call the POST problem. Anyone who has used the back button on your browser or hit refresh and seen this:
Turn this into an image block of a screen shot of that bad message.
knows what I mean by "the POST problem". I hate it when this happens. Not only does it disrupt navigation but you never know if you've duplicated some operation that was never meant to be duplicated.This article is not about MVC but I assume most web programmers understand MVC by now so I'll mention it. Now lets add in templates so that our view isn't merged with our controller and fix the post problem in the traditional app.In order to scale the traditional way and not mix post and get files and not mix display logic and application logic we need 3 files for nearly every page. A get file, a post file, and a tempalte file. In zoop we have one file for the each zone and one for each template. The zone files are not intended to be huge. But often, especially if your model is also adequately abstracted from your controller, you end up with a whole bunch of tiny pages. In this case it's much nicer to have them collected into one zone file rather than having tons and tons of 10 line .php files all over the place. This is however a matter of preference and not the main benefit of using zones. As we expand our app these benefits will become more and more apparent.
also notice how we don't have any configuration file listing each page. We just have to make sure that each zone is included.now get rid of the you are logged in page and add pageListIssues. Then add an extra zone. zone_issues. zone_issues will contain pageView, postView, pageEdit, postEdit. file count: zoop: 7, traditional: 12Notice the file count growing. But again that is not the main benefit. The main benefit is pageView, postView, pageEdit and postEdit all have certain things in common. They all require the user to be logged in and the all require an issueId. Here is where zones really come in handly.We're now going to learn about certain methods in each zone that really show of the power of the front controller.First, the constructor. In the constuctor is where we usually indicate the zoneParams. A zone param is a paramater that (generally) every page in the zone needs. Notice how in the traditional app the issue param has to be hand crafted into every url. In the zoop version we barely have to know about it except when we enter the zone. From then on it's just always there for us. Notice I should add in support for an issue class to properly separate out the model from the controller. Doing it this way illustrates the power of zone params. We will add some better OOP design in a later example in order to show even more features of zone.
Now here is the real kicker. The other special zone methods are initZone and initPages. They are both called before any of the page or post methods are called. In a later example we will learn the difference between them but for now just take my word for it that we want to use initZone here.What are we going to use it for you ask? For security.add a permissions.php to each projectfunction initZone(){ if( !loggedIn() ) trigger_error('user not logged in');}Now EVERY PAGE that is now in or EVER WILL BE IN zone_issue will get this security check. There is no having to remember because it just happens automatically one initZone has been set up. Now every time you create a new page in the traditional app you have to remember to include not just A header file but THE CORRECT header file. If you forget, no security. With zones you can't miss it. Even if you miss it, ou don't miss it. And the more zone's you have the more it useful it is. It is analagous to being able to set the permissions on a directory and having all files in that directory be automatically protected no matter what thier individual permissions are. Can you imagine a file system that only had file level, and not directory level, permissions. After using zoop that's how you will feel about any method of developing web apps that doesn't cover that problem.
TODO:now cover, nested zones, add comments to the issues.create some tool to show a formatted url when you want to see itshow how initZone and initPages differ and how you can use zone_issue::initZone to enforce permissions in zone_notethen add a model and use $this->issue to set stuff up in initPages and use it down below sequences - the added stucture allows us to do thistying zones into gui:this->assignthis->displayshow how it enforces organiztion of templatesdifferent display templatesI think that when you compare the two different solutions to these problems the front controller starts to look a lot more elegant and useful that the straw man front controller used to illustrate the "anti-front-controller" articles.