As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
It seems the more popular frameworks use a front controller. I understand the benefits of a front controller (reduces redundancy and simplifies extensibility), but
I want to know what PHP frameworks do NOT use a front controller. Additionally I am interested in those frameworks that use page controllers and that recommend using a real file directory structure for the urls as opposed to rewriting almost every url or using a mess of a query string. Additionally I am interested in knowing which of the frameworks that do not use a front controller implement MVC. Lastly, any additional details you can provide on the non-front-controller frameworks would be useful, particularly what version of PHP it uses or requires. (I know I can get this later information from other sites so it is not as important.)
Consider the words of Rasmus Lerdorf (the original creator of PHP):
"As for MVC, if you use it carefully, it can be useful in a web
application. Just make sure you avoid the temptation of creating a
single monolithic controller. A web application by its very nature is
a series of small discrete requests. If you send all of your requests
through a single controller on a single machine you have just defeated
this very important architecture. Discreteness gives you scalability
and modularity. You can break large problems up into a series of very
small and modular solutions and you can deploy these across as many
servers as you like. You need to tie them together to some extent most
likely through some backend datastore, but keep them as separate as
possible. This means you want your views and controllers very close to
each other and you want to keep your controllers as small as possible." - Rasmus Lerdorf
UPDATE: Many thanks to user Alex for the first of hopefully more answers. His answer is QCubed ..
"remember that front controller (index.php) and MVC are separate
patterns. That is, you can have an MVC framework that does NOT
implement or require the front controller. My framework of choice,
QCubed, happens to be like that." - Alex
Now if we can reopen this question then we can continue what we started and put together a list of frameworks that do not use a front controller. Please vote to reopen. Thank you.
I'm still learning Symfony2, so if I'm not wrong, i think you can have different front controllers. And the code would be separated in different Bundles.
By default, it has two fron controllers, one for production and the other one for development. However i think you can create more than one (one for each page)
Hope this helps
Interesting question, although I am not sure what your end game is. A controller basically 'bootstraps' the framework into a useable state. My experience lies with Symfony, Zend, and CakePHP, and can tell you that the controllers used in Symfony are quite short (~50 lines of code). However the underlying code is quite extensive, but this code does a number of things such as setup your ORM, cache heavily used arrays (creating static files in /cache directory), and initialize an autoloader for file calls, just to name a few.
Within the Symfony Framework context you have a primary controller, but you also have mini-controllers, or as you put it, page controllers, these controllers are referred to as 'actions'. An action acts as a bridge between a user request and various attributes of your application which may include file/data stores, request handling, user redirects etc. As with the primary controller the actions are meant to be lightweight, mainly consisting of API calls to underlying classes and functions.
I have actually used Zend within Symfony to fill the gaps in functionality that Symfony does not provide. So to your question, I am using Zend functionality without any controller interaction. All I need to do is initialize Zend within the autoloader (b/c Zend is correctly namespaced). Also did this with CakePHP to take advantage of the Inflector class, no controller usage, just calls to functionality I didn't want to write myself.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I know this has been done many times before (some posts are really old so would be nice to get feedback based on current state of play), but I would like people's advice on which framework to use for a new application that we are about to start developing.Though we have set-up everything according to ZEND but now client's investor need to know why we choose Zend.
It was selected on the bases, out of 5 developers 2 are familiar with Zend. Now client want a detailed explanation why we didn't choose Symfony over Zend. Our reason is not enough to support our selection ;) so help me to choose which framework has what advantages over other so that we can present him solid reasons(for zend), and if symfony has more +ves then why we choose it(symfony) NOW. We can change our framework now.
I guess the correct answer is 'depends on what you're application and you're own requirements/preferences' so here is a brief description of the application and some of our own requirements:
The Application:
A financial transaction system extracting live transactions data done over thousands/millions of POS world-wide.
Few important things for project:
Database is already provided to us & it is an ORACLE database.
Oracle database has more than 86 tables. Some of the tables have more than 60000 rows of data at present & some of them have 79 columns too.
Our Requirements:
good support for jQuery
allow easy output of different types of output (HTML, XML, JSON)
easy UI development using in-bulit functions/methods.
ACL
fairly fast development (as always, schedule is tight)
nice clean business logic layer with freedom to architect the solution as we like.
a framework that helps you to get stuff done quickly but doesn't restrict you too much.
a good platform for doing other projects.
Any feedback from people who have used these frameworks (specially those who have used both) would be much appreciated.
Zend is not compulsion, but if changed to symfony, we need support for that. So support your answers with reasons, links.
Thank you.
Why Zend
First of all, I had my good experience over working with Zend Framework. It is most stable framework over all the php RAD Frameworks. Zend provides you jQuery builtin Class as Helper that will make it easy for you to make jQuery usage most easy. Even though, it provides the best usage with Dojo too. ZendX_jQuery class makes it easy for you to make use jQuery whenever you want. And, as you know jQuery allows ajax calls by $.ajax*() so it would be perfect choice for going through client side scripting.
However, I'll focus over the zend too because you can go through writing your API for most of the common transactions all over the site. As, ZEND provides Using AjaxContext with Zend_Rest_Controller and Zend_Rest_Route classes for this purpose that holds the Ajax context.
Zend has the best cache system. Even though, it provides the perfect search indexing using lucene. It is easy and stable to make your own re-usable component in your class library. CLI makes your structure delightful so no need to make everything manually.
No problem of managing templates. Action loads its view by prefix. View doesn't bounds you to have any templating engine. However, you can go through that too.
Layouts capability makes it extremely perfect to make generic and dynamic layouts that would be based over different of the controllers based upon ACL. And by ACL, i also got that Zend_Acl provides the complete solution over implementing out the ACL services. ACL is ofcourse the mandatory thing in your application.
Zend also provides you ability of having the modular structure of your site. Just plug and play your code snippets.
Why Symfony
I never gone too much deep over the symfony. However, I experienced it before for one of my project. Overall, as comparing, zend has decent folder structure then symfony. Symfony provides you ability to your code snippets but those snippets are known as bundle here. It has some templating styles that you need to implement in your views. It didn't found any built-in core library for implementing jQuery dynamically. May be, I would be wrong here but I don't know about it yet!.
I also got the same situation when I need to compare Zend & Symfony. But, after looking over all the aspects, I decided to go through the Zend.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have the exact question that this guy has: http://groups.google.com/group/symfony2/browse_thread/thread/cd35132cc6972f29
I'll just copy-paste it here:
I was wondering what different ways of organizing bundles within a
project people are using.
I seem to end up with either one massive bundle for a project or a lot
of bundles which are closely related (dependant) to each other. eg;
I implemented my own user entity and login forms etc, but the users
are linked to an organization (with some functionality). Etc ... It's
mostly the entities that overlap a lot I guess ...
Do you guys split them up or dump them all in the same bundle?
Edit: I don't use bundles for app-specific code anymore.
Personally I prefer to have a bundle per a section of an application. For example:
UserBundle
BlogBundle
ForumBundle
JobBundle
StoreBundle
etc
This is okay if the app is a mishmash of several functionalities, none of which is big enough to require a separate application and/or a subdomain. But if I was developing a big webstore applicaton, my bundles would be more specific:
UserBundle
ProductBundle
CartBundle
SearchBundle
WishlistBundle
etc
So, I'd say, it depends on the focus of the project. What's just a section for one project could be the core functionality of another.
And I usually have CommonBundle, where all the common stuff goes, like global CSS, images, layouts, etc.
Also there are at least two options for the backend organization:
each bundle has its own backend section, or
there is one big backend bundle.
Personally I lean towards the first option and you can read about it in my previous answer, but there are people who prefer to have a separate bundle for the whole backend — probably using one of the admin bundles.
By the way, it's perfectly okay for bundles to be interconnected — you don't have to make them all independent of each other. For example, JMSDiExtraBundle depends on the metadata library and JMSAopBundle, which in turn depends on cg-library. If you'll try to keep bundles totally independent, you'll end up with big monolithic one-bundle lumps of code.
For every project I start off with one CoreBundle, where I put everything together. Then I just develop features in it and as time goes I reevaluate it - if I might use this feature somewhere else someday (or even release to open source), I move it to a new bundle.
"Size" of the feature worth separate bundle doesn't really matter - I've seen OS bundles as big as a 1 single js file :D
One thing for sure - stuffing everything in a single bundle is bad, it goes against the whole reason why this architecture was implemented in the first place!
My answer in the following topic can probably help you : Symfony 2 : Location of Entities
I'm not a Symfony2 master, but I think I have quite a good idea of the bundle design ; of course, there is no universal answer but you can follow some "best practices".
First of all, I don't think that big bundles are a good solution ; you doesn't split your project into applications anymore, like you did with Symfony1.4. You may ask "but what can I do with the frontend/backend logic ?" ; quite easy, use the controller !
Each bundle should refer to a module, a stone in your project's wall. You have to divide your application ; many bundles are not bad. Of course, don't do a bundle for each entities, that would be a waste of time. But imagine a blog application : you would have an User bundle, Articles bundle (which would manage posts, categories, ...), eventually a bundle for static pages, ...
It's not unlogical that your bundle are linked ; you are building a whole application, so in this case they are linked. But the keyword here is "generalization" ; your bundle should be able to be linked to others bundle, not only yours. You should be able to re-use it in others projects.
Good luck !
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have just "finished" coding up a relatively involved web service in PHP. The code base is now a bit of a mess due to last minute requests, changes, add-ons, the usual.
I tried to code it as lightly as possible and in a manner that would maximise performance.
Therefore, I didn't use any frameworks like Zend or any ORMs like Doctrine.
I was wondering if there are any frameworks or design patterns that exist for the sole purpose of building APIs/web services in PHP?
I'm thinking of a refactor and I want to make sure now I know exactly what's involved I can build this thing properly.
I apologize in advance for the self-reference here to my own framework - there's no way for me to help you otherwise since I don't use anything else. I'm not advertising, since it's not public.
As I said in my comment, I think a good web front-end framework shouldn't mean it is a poor web service framework.
Because I was unsatisfied with the restrictive way any of the popular PHP frameworks (CodeIgniter, CakePHP, Kohana) processed requests, as well as their size, I wrote a framework that is designed for really only two purposes, process a request and determine an action to take, and then separate the code for that action from the view (response).
The design pattern I use is this:
All URLs are rewritten (mod_rewrite) and passed to your execution entry point.
Your entry point sets up paths that it will recognize and process. I.E. for a web service:
/users - User list
/user/* - User identified by the value where * is.
/user/*/delete - Delete the user
/posts - List posts
/post/* - View post *
Along with the path you specify a function, I.E. UserActions::saveUser to be executed if the HTTP method is POST. The reason it's only executed on POST is to enable output and input to have the same URL.
The path also specifies a view. This is the response body that will be sent to the browser. It can be rendered as straight PHP, or you could plug in a template engine. In the case of web services, all paths would probably use a single view that renders your data in the output format (JSON, XML, whatever). The view can be just a PHP method and is not required to specify a template file.
In the case of a web front-end, the view can have a parent view which wraps it (creating the page from the inside-out).
The last point is security. You can define a security type to be applied to any path. A security type just specifies what function (like SecurityManager::authorize) to check for authorization and if false is returned, it redirects to a path of your choosing.
The reasons I believe this design pattern works well for Web Services:
Enables you to use a single-entry point, but can be used with multiple entry points (for optimization, if needed).
No assuming that you want your URLs to match your Object Model, like most of the major frameworks do (a notable exception being Zend, as mentioned in the comments).
Easily adapted to REST (instead of just checking for POST, check for other methods too).
The removal of any HTML feels completely natural, since in this pattern the response is completely separated from processing.
This can all be done in a few classes.
Imho, every MVC-based "thing" can really help you.
If you really do not want to use anything (give a try to CakePHP!) already existing, strucutring your code following mvc can really help you to split the logic of your application on more layer, and keep it more readable and debuggable.
Of course, also with the better pattern you can write awful code, it's up to you!
I think you can use the same patterns you use by simple web applications. A restful service has different interface than a web application, but everything under that interface is the same. You can transform a restful service to a web application like so:
METHOD host/resource/data => host/resource/METHOD?data
resource is the controller, METHOD is the action.
For example:
GET http://library.com/books/123 => http://library.com/books/get?123
So you can use front controller and MVC.
A quick Google and I see
Frapi
Cake
Meditation
Code Canyon
I have never used any of these
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm looking for some good resources to learn how to implement internal service layer in Zend Framework. This is interesting post Bookie Link, but with no concrete code samples.
Where to put service classes (/application/modules/modulename/services/?);
How to autoload them (custom autoloader?)
Most common services (user, authentication, cart, cache, feed?)
Sample implementations (any github repos?)
Good practices?
I think the answer to this question depends on your needs, your time constraints and your overall approach to/style of software development.
I have recently (A) made the decision to use Zend Framework on a small but complex web application that has a very tight deadline and (B) have spent a LOT of time investigating ORM solutions and different ZF application structures in general. The conclusion I have come to is that there isn't a one-size-fits-all solution and that you should feel free to get creative and build an application structure that you are happy with.
If you have tight time constraints and the application isn't too large, then you could just create classes with names like Application_Model_BlahService and store them in the application/models directory and they will get picked up by default by the autoloader (assuming the autoloader has been bootstrapped correctly).
But if your application is larger or if, for some other reason, you want to split classes out into more directories, you could create your own sub-directories under the application directory and use something like the code below (which would exist in your application/Bootstrap.php) to add those classes to the autoloader:
protected function _initResourceLoader()
{
$this->_resourceLoader->addResourceType( 'service', 'services', 'Service' );
$this->_resourceLoader->addResourceType( 'serviceplugin', 'services/plugins', 'Service_Plugin' );
}
You can then create classes like Application_Service_Invoice, which would reside in application/services/Invoice.php and Application_Service_Plugin_TaxPlugin, which would reside in application/services/plugins/TaxPlugin.php. (Note: the code above assumes you are using Zend_Application).
You could, in theory, take this as far as you like and separate model classes from service classes from data access classes, etc etc etc. But again, it depends on the style of development that you prefer, the size of the team and, to some degree, what requirements your persistence layer imposes on you.
One last quick thing: have a look in Zend_Application_Module_Autoloader for a list of resources that are added to the autoloader by default. (Should I have mentioned that I'm referring to ZF 1.8+ in this answer?)
You don't need hacking to get service layer work. Default autoloader has a resource namespace Service_ with services folder inside application. So, it will load service layer from application\services, classes should follow Service_* naming pattern.
Basically, you could probably put those anywhere you like ; somewhere close to the model will most likely make sense, though.
As an example, you might want to take a look to :
ZFPlanet : an example of a planet developped with ZF
Not sure it's finished, but there are several classes, controllers, models, config files, ...
Which means that going through the code can help (it has, for me, for some things)
And, especially, its application/modules/zfplanet/models/Service directory
Which contains two classes.
(Well, I hope that's the sort of thing you meant by Service, actually)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In the jungle of frameworks out there, I've come to the conclusion that I cannot simply decide on a framework without considering the type of application / site I want to create. I think I need a little help with determining this one.
This site is graphics heavy, with all of the content presented in a small <div> in the centre of the page, surrounded by graphics. The graphics around it should preferably be loaded only once.
The site will allow users to log on with their account and choose from a number of pre-made food recipes, or create their own. Then they can press a button to have the site generate a week or two of dishes.
The users will need their own control panel where they can customize stuff as wallpaper, dishes, labels etc. As well as browsing recipes, adding ingredients, and looking up which dishes they can create with the ingredients.
As mentioned, all of this data is supposed to be presented inside a square in the centre, so we need a system of jQuery panels. I was thinking of dynamically adding content to this square as needed. For example, emptying the content and adding new content to it when clicking links, etc.
We don't need any community per se; the possibility for discussion can be explored in a separate, external site.
I should mention I am more of a designer than a programmer. I get stuff pretty easily, but fear I don't have the capacity to create a framework like this from the ground up. I do know a bit of Visual Basic, but I'm not so good with C# syntax. I've never even touched PHP, but my partner has. He's also somewhat familiar with Java.
Basically, we need a framework that's easy to understand and get up and running.
I rolled my own framework based on http://kissmvc.com/. It allows you to basically do what you need in PHP but gives you an easy MVC framework to do it in. You don't have to learn the specific syntax to Zend, Cake, Code Ingiter or Kohana, all of which I played with before I found kissmvc. Based on a blog post by Rasmus, it was all the direction I needed and I love what I have now for reasons #animuson mentioned.
Rasmus' post: http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html
From what you write, I would say all "big, famous" frameworks will be able to do this fairly "easy"... So You should really define a few prototype tasks and check out a few of the frameworks. You should be able to solve this using, CakePHP, Symfony, CodeIgniter, Yii, Zend, or any other framework, so it is better to do some real testing.
You might look for a framework that has a tight integration to jquery, but this should not be a showstopper, since you should be able to implement this in almost any framework.
You might also consider footprint and execution time, and find a framework that performes well and is not too cpu heavy (read Yii or CodeIgniter for instance).
Good luck in the search
Ultimately if you want it to fit your needs you need to build your own framework, otherwise there will always be limitations. Keep in mind that there is no framework that you can simply install and tell it to do these things, you are going to need programming knowledge of how the framework works in its entirety and how to program your custom pages to work with those features. I found it easier to just build my own framework. That way I always knew exactly what everything did and if I needed something additional, I could easily add it in the correct spot without doing much thinking on it.
A framework is only the base materials and functions you need. If you're looking for something like a pre-built website such as PHP-Nuke or a forum system, you're looking for a content management system, not a framework. A framework generally comes with absolutely no pre-built pages. Might I add that some content management systems do come with their own framework and some use existing frameworks from elsewhere.
So, we basically need a framework that's easy to understand and get up and running.
well as far as the above statement is concerned you may want to have a look at cakePHP framework.
You will easily find help on cakephp framework on stackoverflow and cakephp google group. Response will be quite fast on both the sites.
You will need to go deeply through the documentation of every framework that you plan to use because with a functionality that you are planning to built would require you to study the framework quite well.
With cakephp you will be able to create CRUD (create, update, delete) operations quite easily with less effort, but for further functionalities you will have to study it's documentation and keep your cool while you learn it :-)
I have always found plain php to be all the framework I need.
PHP itself has all the features provided by the other frameworks
A superb templating engine, database access, parsing, and control logic.
The great thing is all these features implemented in a single unified component called "php".
The main problem is you need discipline to separate presentation, navigation, busines logic and database/persistence handling. You can have sql statements mixed in with your html, you can emit html directly from an sql statement in fact you have complete freedom to implement all the known anti-patterns and invent some of your own.
The "Java" and "Perl" frameworks generally provide things like request handling, template handling etc. which are missing from the basic language, but, these features are built into php. Most of what the "php" based frameworks do is force you into (a very sensible) MVC design pattern and save you a tiny bit of coding.