I have a site in Yii 1 with 3 modules:
admin
site1
site2
The site2 module is a parent module of site1. And these two modules are pretty similar (there are some controllers that are same).
I want to reorganize my site to be a parent module (which holds the common views and controllers. the models are the same).
What are the best practices for this?
This can have lot of solution. Here is something from where u can start:
U can have some common place where u will keep shared code. We can call that directory 'common' in this case. Than inside this 'common' directory u can organize your shared code based on functionality - behaviors, models, components, actions, widgets, events, and even views (but i not like too much to share views, if u need one view on more places its usually good to make widget for it). U can import this from application config.
Its usually much cleaner and more configurable if u break your controllers into action classes and than share that actions between controllers by attach them to controller (good example of this is Catpcha action in default yii application). On this way u can exclude actions in some controllers if u not need them or mix different set of actions if u need that.
About shared view files, even u can do it by give full path to view file from any place, I much more prefer to use widgets if there is need to call one view from more controllers. If u call one view on more place from one controller u can use renderPartial() and than include your view into other view, but if u need to call it from more controllers than from organization and functional view its much better to use widget.
Related
I'm using CakePHP 2.2.3 and I need to build an admin/dashboard area for my site.
I have many models and controllers related to this models and in the dashboard I need to have the ability to CRUD all posts/users/news etc.
Obviously I need to build a Dashboard controller with some index action which will be show dashboard "home" page.
My question is: where to put all other actions – for posts/users/other things adding/editing ?
Should I put all this actions in this new dashboard controller or it's better to put this actions to related controllers(Posts/Users..)?
Keep your specific actions in each of their own controllers. A DashbaordsController is fine for whatever pages need to display a lot of different model information, but CRUD actions should be kept in their own Controller.
If you want/need a single page to be able to actually do the CRUD actions ON that page, you can use ajax and STILL call the actions of that specific Controller.
Bottom line, if you try to put all your CRUD into a single Controller, it's just going to get messy, and will be very confusing for future programmers (which includes yourself 6 mo from now).
It's so easy to include data from other Models $this->loadModel('MyModel');, that doing CRUD actions in their own respective Controller is not much of a hindrance. Again - the DashboardsController is still fine for those few pages that really are like dashboards, and have no alliance toward a specific model. But not for each model's CRUD.
Generally the ideal way is to do skinny controllers and keep logic as far down the stack as possible that is near to the models. Ideally you'd want to introduce libraries for code reuse and testing. Robert Martin aka Uncle Bob says that the web delivery and databases should be as much of a plugin as possible. This lets you unit test much better. As far as your particular case i'd want to keep it close to REST as i can so separate controllers ideally delegating to some lower level stuff.
Alright, I know this is a bit localized, as I'm sure not many break out of traditional Zend Framework logic. But. This is a case where I have one main piece of software developed on ZF, and in it 3 different levels of platform.
So I have your stock folder structure of Zend Framework, then in it 2 additional sub folders that act as layers on top of the main structure. These sub folders have "layouts" "views" "controllers" and respectively "helpers" "scripts", etc.. so. With that due to how this was laid out I have run into a bit of a Jam, where I need to access a helper that is stored in one sub section from another sub section.
Normally you would access the helper like
$this->_helper->enrollHelper->isCreationDriven();
But, the controller I need to call this helper from is in another controller directory. Note I didn't build this app initially I am just helping enhance features and continue its growth. Anyway. The above line wont work for me in this case as the controller I want to call the helper from is outside of that directory in another like directory.
With that, My question is. Does anyone know a means I can call the helper in a similar fashion from this other directory? Or do I end up doing whats likely the obvious choice and just make a mirror copy of that helper in the other controllers directory where I want to call it from initially, my hope is there is a means as I want to avoid duplicate code.
During Bootstrap, you can register the second directory with the plugin broker using Zend_Controller_Action_HelperBroker::addPath($path, $prefix).
Started an project using kostache.
I have made some partials like banner,navigatons and footer in my class View_Layout with extends kostache_layout . Partials work fine on each page.
One problem. The navigation show always the same links. My goal is to show links that are appropriate to the user who is logged. How can I put logic in the partial of navigation? I know I can write functions in the View_Layout class but View_Layout must know the user role?
Hope somebody can help me.
In mustache, partials inherit from the surrounding template's variable stack. You'd need to do this logic in your view class. If different pages need different links, do that in your specific view class.
Option 1: evolve your views
The best option would be to expand the capabilities of your views. Actually in MVC-inspired patterns the views should be instances which handle UI logic and can choose from which (usually, more then one) templates to create the response. If that response even needs to be a HTML .. maybe a simple HTP header would be enough.
The default toolset in Kohana is geared towards very simple usecases, but it is possible to expand it.
My recommendation would be start using fully implemented views.
Option 2: use HMVC
Alternatively, you can utilize HMVC capabilities in Kohana. This would mean, that you have one or few "main controllers", which then create sub-requests. The responses from those requests is passed in/bound to the template, which said controller supervise.
In you particular case the menu would be governed by separate sub-controller.
I am using Zend framework and doctrine in this app
In my web application i have various individual modules like events, conferences, case studies.. so i am making controller design at this moment. In the below image regulatory document is the controller and its sub are its actions. So regulatory doc, videos, podcasts all are having almost the same kind of functionality. so is this design appropriate...?
In mvc for each action i will be having a separate view. And on user type i may have to put access levels on this modules. so i have kept separate controller so that i can easily control the module for each user type. But this is resulting in duplicate code.
Now i am thinking to make one parent class and in that i will have all the common methods. eg. I will have common class Resources and in that i will keep list, search, suggest, addFavorite etc. And that will be the parent to the above given controllers.
So than how will i manage my view for all these different modules if i go with this approach..? if i go with this than my code will be bit messy..?
I would suggest to keep all the controllers to have nice URLs and clear structure in the modules, however keep the controllers thin. Put your domain logic into Services or Entities, hence no (or just less) code duplication is required.
More in:
Is MVC + Service Layer common in zend or PHP?
How to implement service layer in Zend Framework?
From DDD:
http://domaindrivendesign.org/node/118
controllers belong to application layer / domain logic belongs to domain layer
If I understand you correctly you have a set of common behaviors among your regulatory documents, videos and podcasts.
In this case you should probably try to abstract the commonalities out into a parent class from which these three areas inherit.
As an example, I have my own MVC framework where I define a superclass tnh_controller from which my other controllers (eg: venue_controller, group_controller) inherit. In the parent controller I define the header() and footer() and delete() methods. I can then use those unchanged in the child classes and save myself some effort.
You can likewise do some of the common work for your models (CRUD) in a model superclass, only overriding it as needed. Most of the logic for different models comes from class variables (table names, column names, etc).
I wouldn't worry too much about being "strict" MVC. Instead try to work out what will save you time and keep your code organized. It sounds like you're on the right track putting similar behaviors at a parent level.
You can still have a separate controller to contain suggest, addFavorite actions without having to make it the parent class for all the controllers. Basically the UI elements related to these you can render as partial views and call on to the actions in the relevant controller. That way you can get rid of the problem with the views.
MVC designing means that for each view, you have a controller and a model. However, the models don't need to be classes at all, nor having a different model for each MVC. Usually you will share a model between some MVCs, or your model might just be an integer value which you define in the own controller. Usually, you might even want to share data between them, then you will have a singleton mode:
http://www.galloway.me.uk/tutorials/singleton-classes/
I'm wanting to be sure that I am setting things up correctly. On a typical website with 10 pages, would each page have it's own controller with it's own IndexAction and it's own View folder with it's own index.phtml as a view?
Or do you have one controller with multiple Page1Action, Page2Action, etc and have multiple differently named view.phtml pages within view/index folder?
I'm leaning toward the former because then I can have a cleaner controller for each page...
Is there a standard, or is it subjective?
Your sitemap would play a major role in this question. But, in lieu of that, here's a few examples.
Example 1. Flat
/foo
/bar
/baz
You'll probably want to use separate controllers: Foo/IndexController.php, Bar/IndexController.php, and Baz/IndexController.php with each having an indexAction() method to pass information to your view (once again separate).
Example 2. A Little Bit Lower Now
/foo/bar
/baz
You'll only need two controllers: Foo/BarController and Baz/IndexController. If /foo needs a landing page you'll have to throw in a Foo/IndexController.php to be safe. Your actions are still indexAction(). Because you've not gone deep enough to hit that third level, your views are still index.phtml.
Example 3. Straight Line
/foo/bar/baz
You're down to onc controller: Foo/BarController.php. If you need landing pages for /foo and /foo/bar you'll need another controller for /foo (Foo/IndexController) and an indexAction() for both. With /foo/bar/baz you're actually down to a slightly different action now too - bazAction() (inside Foo/BarController.php). Your view is now baz.phtml.
Summary.
The wider the sitemap the more controllers you have and fewer actions. The more narrow the sitemap the fewer the controllers and more actions.
Postscript.
I should also state, this is also contingent on using default routing patterns. If you do something a little more sophisticated in routing patterns, this is all shot out the window. Sometimes we use routes to keep the number of classes manageable. When we have a wide sitemap it's possible to create some custom routes and use __call() within a controller to hand-off view data appropriately. Just another way to skin this cat.
Typically you would create one Controller for a related group of Actions. What related means is subjective.
Very roughly speaking, a group of related Actions operates on the same Model. At least that's a good starting point, but it rarely works out that simply, because few real-world applications consist solely of CRUD operations on each Model.
If you decouple the Model from being simply a data access component, you can more sensibly define a logical grouping of Controller Actions for a Model. A Model is where the majority of your code exists for business logic. Database persistence is just an (optional) internal detail of the Model, to preserve state from request to request. But a Model doesn't necessarily use a database. It could be standalone, or it could be an aggregation of other Model objects.
By default, each Action has its own View script. But this is also just a starting point, because you could use Layouts to make many View scripts share some if their markup in common, and you could use View Helpers and Partials and so on.