I Searched a lot to find the answer to this question, here on stackoverflow and over on google. But was not able to find anything...
So, my question is: It is a good practice to extend a controller (in my case BaseUserController from zfcuser) once in a module, and once more in another module?
Thanks for all your replies!
It's fine, I would not go as far as "good practice".
Excessive use of inheritance can cause you issues in any language and there are numerous of post around explaining the issues and possible solutions.
From a ZF2 perspective in doing so you will have the issue where Module B depends on Module A which may be a problem - However this really depends your application/module design.
There are other alternatives:
Aggregation -
create new functionality by taking other classes and combining them into a new class. Attach an common interface to this new class for interoperability with other code.
Use PHP traits - If you lucky enough to use the more recent versions of (PHP 5.4+) the you can simply reuse these within each controller class that requires it.
A Custom Controller Plugin - ZF2 has a "pluggable" API within the controller, meaning you can write self contained helper classes that can then be used in any controller - No need to extend. You are almost certainly using these already with $this->redirect() or $this->params() so they might be good places to start to see how they are built.
I'm new to Backbone.js. I have gone through the documentation. My question is
where does the controller concept come into picture? In other words, what is a controller in Backbone.js?
I heard that the router is the controller. If so, why it is considered as a controller? Can we develop simple basic apps without the Router also? In that case what will be the controller?
To clear things a little bit here. A Router is not a Controller, It's a way to define a client-side route map (similar to Rails's routes.rb). This helps routing client-side pages to certain actions/handlers. And that's different from a controller's job which is to provide a bit of orchestration between Models and Views. And there is actually more than one way to do this using Backbone. Quoting from Backbone's documentation:
References between Models and Views can be handled several ways. Some
people like to have direct pointers, where views correspond 1:1 with
models (model.view and view.model). Others prefer to have intermediate
"controller" objects that orchestrate the creation and organization of
views into a hierarchy. Others still prefer the evented approach, and
always fire events instead of calling methods directly. All of these
styles work well.
This brings three different approaches to accomplish this. The first one is pretty straightforward which is to have the model object included as a property to the view.
The second one proposes including a third component that performs this role of orchestration. I believe this can be helpful in quite large and complex applications. For this I encourage you to look at Chaplin, a sample application architecture using Backbone.js. The guys have done a great job in separating things out and also introduced the concept of a Controller into the architecture.
The last approach is suggesting using events to mark for actions and mediator to handle these actions. For this I encourage you to look into the mediator and Publish/Subscribe JavaScript patterns.
Check out Addy Osmani`s article on MV* on the client:
http://addyosmani.com/blog/understanding-mvc-and-mvp-for-javascript-and-backbone-developers/
From the article:
In Backbone, one shares the responsibility of a controller with both the Backbone.View and Backbone.Router.
and
In this respect, contrary to what might be mentioned in the official documentation or in blog posts, Backbone is neither a truly MVC/MVP nor MVVM framework.
It's more similar to how for example iOS Cocoa Touch framework works, you shouldn't think about it like a backend MVC, backbone team itself even never mentions MVC on their website to avoid confusion people often have when coming from backend MVCs. The View in backbone is what's called in iOS a ViewController/AppController and usually your main AppController will be a View which sets the main wrapper for your application which usually you would also use as a global pub/sub system and controller for your main app logics.
Router is exactly what it say - it converts routes into set of params and passes them to the app controller to figure out what to do with them, what subview to load etc. (or if application is less sophisticated it can load/change the views straight from the router level) - It used to be called controller but it was renamed in (0.5 I believe?) to clear this confusion.
At least this is our approach - if you checked multiple tutorials in the wild you've probably seen that when it comes to Backbone there are as many approaches to this as many developers there are. And that's what is beautiful about Backbone! :)
Usually I make my own controllers, and let the router do it's thing (catching routes, and pointing towards a controller action). These controllers are home made, just javascript objects with methods on them. They take the request from the router, collect the right data (collections, models...) and take the necessary view, combine them and pass the data into the view.
from there on it's backbone again.
however recently I came arcoss a 3rd party backbone plugin called backboneMVC. Have read it's documention, but have yet to try it out myself.
It aims to take over your router and make routes based on your controllers and actions you define with it.
Take a look at that library however I cannot promise anything because I have yet to build something with it myself.
I want to make one mvc3 application which is student management.
I've seen some open source projects.
They have used solution structure like core,data serve rice.
is there any reason to use structure like this?
Usually it is a good a good idea to keep things separated.
By that I mean not mixing up business logic with database management code and having non-UI code in the view files.
This makes it a lot easier for others to understand the code you have written. I also helps you, when you get back to some project after some time to make improvements or correct errors.
I hope this answered your question, if not shot again.
Edit: I found this link explaining how it is done in the MVC framework.
Use layered architecture where you isolate each layer by using the Separated Interface pattern. For the database, use Repository pattern (easiest way to archive that is to use a ORM like nhibernate).
Use an inversion of control container to reduce coupling (with the help of interfaces) and make it easier to handle dependencies between classes.
As stated in the previous answers, you should separate your logical tiers into a minimum of BusinessLogic (Entities,validation,etc..), Data(your favorite ORM), and presentation (MVC).
However, if you are just starting out it may be a little daunting to incorporate all of the more advanced concepts of a SOLID architecture.
Separating logical tiers doesn't always have to mean separate projects. The standard MVC3 template demonstrates this with the "Models" folder. Any entity added to this will be under the namespace Myproject.Models. Later you could re-factor the code in the Models folder into a separate dll,add a reference, and as long as the namespace was still Myproject.Models the MVC app will continue to work.
The same thing could be done for your Data Access layer!
If you're just starting out I would recommend developing your app in the MVC project and separating your DAL and Business Layers with a Folder (Namespace). Once your application is working you can re-factor as needed.
Closed. This question is opinion-based. It is not currently accepting answers.
Closed 7 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Some people consider WordPress a blogging platform, some think of it as a CMS, some refer to WordPress as a development framework. Whichever it is, the question still remains. Is WordPress MVC compliant?
I've read the forums and somebody asked about MVC about three years ago. There were some positive answers, and some negative ones. While nobody knows exactly what MVC is and everybody thinks of it in their own way, there's still a general concept that's present in all the discussions.
I have little experience with MVC frameworks and there doesn't seem to be anything about the framework itself. Most of the MVC is done by the programmer, am I right? Now, going back to WordPress, could we consider the core rewrite engine (WP_Rewrite) the controller? Queries & plugin logic as the model? And themes as the view? Or am I getting it all wrong?
Thanks ;)
Wordpress itself is not architected in MVC, but one can build very MVC oriented themes and plugins within the framework. There are several tools which can help:
WordPress MVC solutions:
Churro: # wordpress.org/extend/plugins/churro
Tina-MVC: # wordpress.org/extend/plugins/tina-mvc
Plugin Factory: # wordpress.org/extend/plugins/plugin-factory
MVCPress: http://mozey.wordpress.com/2007/01/22/mvcpress-screenshots/#comment-3634 (abandoned, but interesting ideas)
MVC threads on WordPress.org Ideas and Trac:
http://wordpress.org/extend/ideas/topic/mvc-plugin-framework
http://wordpress.org/extend/ideas/topic/complete-reestructuring
http://wordpress.org/extend/ideas/topic/rewrite-wordpress-using-mvc
http://wordpress.org/extend/ideas/topic/wordpress-theme-revamp (more on XSL than MVC)
http://core.trac.wordpress.org/ticket/12354 (on MVC in widgets)
Wordpress is kinda-sorta MVC. If anything it is a pull-type MVC layout, where the View 'pulls' data from the model. It does this in a very proceedural way, instead of using lots of different objects, but this actually makes the front end templates easier to write in a lot of ways.
This also gives the views some degree of controller logic (thus the kinda-sorta MVC).
Lets run this down:
Wordpress gets a URL. The wordpress core acts as a controller and determines what initial queries to run of the database, and by extension, what view should be loaded (category view, single post or page view, etc). It then packages that INTIAL query response and sends it to the view file.
That view file CAN be a strict display only file OR it can request additional information/queries beyond the built in one. This is the pull-type of the MVC, where the view pulls data from the model instead of the controller 'pushing' data from the model into the view.
Thus, when the view sees code to load a sidebar or widget area, it asks for that information. However, what widgets should be there is determined by the controller, which looks at the model for what widgets are in the sidebar, and then selects those that are set to show on the current page, and returns those to the view.
That each part of that isn't an object doesn't make this any less MVC. You can alter WP core without (necessarily) altering anything about a theme. Similarly, as long as you use built in functions like 'get_pages()' then the model and the database tables could change as long as those functions still returned the right data. So, the model is independent of the view, and the controller is independent as well (except when the view adds controller logic to do more than the core normally does).
While you COULD have a model object holding a number of methods and stuff like WPModel::get_pages('blah blah'), and contain everything that way, there is still fundamental separation of concerns.
View: template files
Controller: WP core
Model: the various functions that handle specific data handling.
As long as the names, arguments, etc, stay the same (or just have new ones added) then separation of concerns is maintained and one can be altered without disturbing the others.
It isn't a super-clean version of MVC, (especially when hooks get involved), but at a basic level it starts there.
And being proceedural about it isn't a bad thing IMO. A request from a website is pretty inherently proceedural: it is a process with a clear beginning and end, and just needs a procedure to process the request, get data, package it, then die. You can set up those steps with objects and object methods and OOP layouts (which would make some things easier) or you can just write alot of function calls and separate them out that way. Class members like private variables are lost that way but depending on the needs of the application... you might not care.
There is no one-grand-way to do development, and WP sits at like 20% of websites so it is doing something right. Probably something to do with not making people have to learn/memorize complex class hierarchies to get the database to answer the question 'what pages are child of page x?' and deal with that data. Could you make it that easy with OOP? yes, but if Joomla is any example of how hard it is to implement a complex custom website with OOP, then WP is FAR easier and quicker, and time is money.
As already mentioned in the comments, MVC is an architectural design pattern, not a specific framework, and no, Wordpress doesn't follow the MVC pattern.
There is a separation of views (templates) from the programming logic, but only in the frontend, not in the admin panel and a general separation of views and application logic is not inevitably MVC. An implementation of the MVC pattern usually assumes some kind of object oriented programming paradigm behind it and Wordpress is mainly implemented in a procedural way, with plain SQL queries in the PHP functions, therefore not having an actual model either.
One of the topics that periodically crops up in discussions as it relates to WordPress is the idea of WordPress and MVC.
But the thing is that MVC is not the silver bullet of web development that we try to make it out to be. Yes, it’s an awesome design pattern, and I personally think that it fits the web application model like a glove, but not every framework or platform implements that design pattern.
Case in point: WordPress is not MVC.
And that’s okay. I think we need to leave the desire of trying to shoehorn it into our projects aside especially when the pattern WordPress provides is not only sufficient, but works well when leveraged correctly.
“But I Love MVC!”
So do I! In fact, I spent the last year working on a project that more-or-less mimicked the MVC architecture.
A high-level example of MVC.
A high-level example of MVC.
For example:
Views were implemented using templates
Controllers were implemented by a combination of using function names like create, read, update, destroy, delete, and so on (even though these functions were hooked into the WordPress API
Models were functions also were called to validate and verify data prior to serializing the data. Again, this required that certain functions be hooked into WordPress to achieve the desired result.
Finally, a set of rewrite rules gave the application a clean set of predictable URLs in the format of /people/update/1 or /people/all.
What Pattern Does WordPress Implement?
WordPress implements the event-driven architecture (of which there are several variations such as the Observer Pattern).
In short, you can conceptually think of this as the following:
Things happen when WordPress is processing information.
You can register your own function to fire when these things happen.
Not too complicated, is it?
A high-level example of event-driven patterns
A high-level example of event-driven patterns
When you begin to think in terms of the paradigm in which it works rather than trying to make it work the way that you want it to work, it’s liberating. It helps to solve problems much more easily.
The bottom line is this: WordPress implements the event-driven design pattern, so even if you end up trying to implement MVC, you’re still going to have to utilize the hook system.
If you’re not careful, you can end up trying to craft the perfect architecture without actually getting your work done, and thus end up finding yourself so high up in the atmosphere of software that you’ve effectively become an architecture astronaut.
So You’re Saying Avoid Design Patterns?
Not at all! Design Patterns serve a purpose because, above all else, they basically give us solutions to previously and commonly solved problems. Use them!
But the point I’m trying to make is that we don’t need to try to force things to fit pattern just because we like the pattern. That’s not their purpose. Instead, leverage the primary pattern that your platform of choice implements – in our case, it’s an event-driven pattern – and then implement patterns where they fit (such as dependency injection or something like that).
Otherwise, it’s like trying to put your foot in a glove.
Courtesy (and totally copied :P) from : http://tommcfarlin.com/wordpress-and-mvc/
Just to update this with more recent information for people hitting this from search engines - the wp-mvc plugin http://wordpress.org/extend/plugins/wp-mvc/ goes a long way to creating a mvc framework for plugin development. You can find out more here: http://wpmvc.org/documentation/70/tutorial/
Just to add to the list of options, (I'm admittedly biased as the author,) swpMVC is a fully featured, lightweight MVC framework, inspired by Rails, Sinatra, Express, and FuelPHP. It's thoroughly documented, and while I have used and enjoyed wp-mvc, I wanted something where the models were able to populate views themselves, including form controls for interacting with said models.
I put this together largely to reduce the amount of controller code required to put together an app on top of WordPress, and the result is a very fast and effective framework that runs inside WordPress. The models are based on PHP Activerecord and 8 models are included for existing WordPress data types, including Post, PostMeta, User, UserMeta, Term, and a few more. Modeling data is very easy thanks to the activerecord library, and I've enjoyed working with this framework immensely thus far.
Also ships with underscore PHP and PHP Quick Profiler (as seen in FuelPHP.)
RokkoMVC is a micro MVC framework built especially for WordPress. The project is meant to simplify AJAX functionality in WordPress applications, as well as bringing in all the other benefits of using models, views, and controllers to your theme.
I had a bash recently at creating a plugin that makes use of a simple view-controller system, and quite liked the results, so I separated the template stuff out to its own repo. It offers object-based controllers, passing variables locally to PHP templates, template fragments (templates within templates) and components (template fragments with their own sub-controller). All in two tiny classes!
Of course, I wrote this code thinking that no other WP developer had considered the problem before ;-).
It's far from mvc, there is no kinda-sorta thing like some people say, it's either MVC or not... The fact that you write logic on the view level doesn't qualify it as a mvc framework. The reason people use it - it's easy to learn, you don't need to be hardcore php programmer, they're lazy.
Our team is experienced in web development (tomcat/Oracle) but not with AJAX on our existing projects. This is new technology for us, so I want to introduce this carefully and correctly.
What should I look at in terms of frameworks or best practice or common pitfalls?
read this:
progressive enhancement
and use a library such as jQuery, mootools, or YUI it'll save you many headaches with cross-browser implementation. this will show you why you want to use a library.
My first recommendation would be to explore the different frameworks available and see what your team prefers in terms of coding style. Most of the frameworks have the same basic features so a lot of it comes down to preference. I prefer jQuery, so that is my first recommendation, but I worked with YUI, MooTools, Prototype and EXT JS before making my decision.
Secondly, I would recommend working AJAX functionality as a progressive enhancement, allowing your apps to work with and without JavaScript. I find that this approach also ensures a solid, working application before worrying about adding the bells and whistles.
Head First Ajax is a good book IMO for getting started with the basic concepts behind working with Ajax. It would probably be a good place to start for your team to gain some knowledge of what is happening behind the scenes in whatever framework you choose.
One thing we struggled with when starting to use ajax was how often to use it.
We had no exact requirement as to where we were supposed to use ajax and not, and initially we erred to the side of using it too much. This affected application complexity quite a lot.
If you think of your inter-page-structure as a state-machine, ajax introduces nested state-machines within each page-state. The moment your sub-state machine ends up with a number of distinct states (I'd say anything over 2), you should think really hard about using a traditional approach.
The best starting point is to try to get a mix og full page reloads and ajax, and be conservative until you're sure you're getting really good at it.
Don't use it where you don't need it.
Long running operations that need to send the client some status updates? Use AJAX.
Markup for major UI elements (menus, ect)? Use plain old HTML.
Basically, use AJAX for transmitting data only. If you try do fancy things like dynamically pulling in UI elements on the client side with AJAX, you are in for a world of hurt when you get a client who wants to use ie5 (they exist), or a non-pc based browser.
first, look at the user interface you already have, and consider where it might make sense for its elements to be able to change/react independently. This is where your ajax enhancements might make sense
second, look at libraries as noted in the other answers (I like AJAXPRO for its simplicity, but it has been discontinued)
if you find that all of your page elements tie together and cannot change independently, then there is really no need for ajax
otherwise, consider how you will access the page state from your ajax enhancement points - depending on which ajax framework you use, you may or may not have access to the entire page object, session state, original request parms, etc. Consider these issues up front to avoid coding yourself into a hole and/or having to make messy workarounds.
If you were on .Net or Mono I would encourage you to use Ra-Ajax which abstracts away JavaScript completely. Though I work for Ra-Ajax (inventor) so I am biased...