I have a front controller which receives all of the requests. Request has an action parameter which tells the controller which command to initiate.
Apparently Laravel commands are not supposed to return responses like views and redirects upon completion. Should my main controller do it? Different actions require different responses.
Perhaps I should implement command objects as tiny controllers with a single method like process()? If for example an action is to load a login screen, process() would simply return view('login'). Is that reasonable?
An explanation would be appreciated.
Look into Job classes.
https://laravel.com/docs/5.2/queues#writing-job-classes
Your controller could dispatch a Job classs like this (like a tiny controller that you mentioned)...
https://laravel.com/docs/5.2/queues#pushing-jobs-onto-the-queue
The handle method on the Job class could return whatever you want to your controller.
Related
I need to call a controller say 'faq_view' inside admin controller as the URL structure admin/faq_view like this how I can do this?
e.g:
site.com/maincontroller/function
site.com/maincontroller/othercontroller/function
Then, just redirect the page. Else if you want to just call the function, call it via AJAX.
It depends what you exactly want to do. If you want to just invoke the function, its not the right way. Controller as it defines itself controls the flow of the pages that comes on sequence. Controller is responsible to send commands to its associated view to change the view's presentation of the model.
So, if you are saying you want to call controller within another controller, that should mean you are about to redirect to another page.
Updated answer:
Just assume you have new_function on maincontroller that calls the function from othercontroller. The function does not need to be defined on othercontroller.
Add the following line on routes.php.
$routes['maincontroller/new_function'] = 'othercontroller/new_function';
Now, you can call the function of othercontroller as maincontroller/new_function.
You can always call a controller inside another controller, but this only works for calling one controller as far as I have tried. Let's say you are trying to load a controller inside a controller. You can try this:
$this->load->library('../controllers/myothercontroller');
Then do this:
$this->myothercontroller->function_name();
That's it! You can now access any function inside myothercontroller (controller) in your current controller. I hope this helps too.
Your controllers are part of the presentation layer and should not contain application logic. That means you should never need to call a controller from another controller, instead refactor your application and move the domain logic to the model layer.
Now if you have a method that you need in multiple controllers, say for example you need a template method that automatically adds your header and footer views.
If that is the case, create a base class that your controllers extend.
If you are talking about just a routing issue, then just use the routes file for that. I don't like the CI automatic routing and it should be avoided as it will result in duplicate URLs for the same resource.
I'm designing an application trying to follow the REST spec. I'm trying to figure out the best way to design it.
So let's say I'm doing a POST call that so I have a "post" method in my controller and model
// in controller
function post()
{
//call post model here
}
In my post request I need to make the following checks:
-validate fields
-make sure item name is unique for that user
-make sure there are less than 10 items
-etc (there could be more cases)
Now in controller post function I will return a REST message and status code based on whatever happens, which is fine, but I'm curious to know where it's better to keep all those checks.
I can put all the checks in the model and then return some kind of array like:
array('text' => 'return response text/array or whatever here', 'code' => '200/400/etc')
Then just return this in the controller, or is it better to break up those checks into individual functions within the model and then do all the checks in the controller?
// in controller
function post()
{
//if validation fails -> send response
//if name is not unique -> send response
//etc...
}
From a design point of view, if I ever wanted to potentially call the "post" method in the project model from other methods, it would not have an all encompassing function to handle it, however if I do keep it all in one model function it doesn't give me a lot of reusability. If I had to pick sides, chances are I probably wouldn't need to reuse those "check functions" too much anyway, however it also seems weird to have all that response info in the model rather than the controller.
Can anyone please give me some input on this.
I would not create post method inside the model (although having it in the controller is perfectly fine) simply because you just put code/model in such a frame that is not re-usable plus less readable. For instance, instead of post method in the model I would create create method.
There is no one-fits-all way for data validation. I like creating validation classes which have only one method validate for various data types (e.g. username validation class checks if it matches regex and is unique). It's better than copy pasting the validation code to every action (DRY). Where to call this class method? It depends. You can simply call that it in the action. Since the validation code is inside the validation class, it will look alright. You can also create a mapper which takes the request, determines what validations have to be performed and etc. but it might be overkill and is hard to do properly (maintainability wise).
For output again - DRY. It depends on what MVC framework are you using and there might be a good solution for this already. If not, you can create a class for that (yup, I am DRY maniac). You pass response code, array (or string) with response and class nicely wraps everything into JSON, XML format. Advantages: if you change then output format then you need to change only in one place.
Also consider using Remote Facade pattern.
Hopefully, you found something useful in this post.
I would separate the API from the MVC application and use Apify
In my app, I want to add a user notification each time a user receives a comment on an image or other page. Therefore in my add action in my images controller, I'd like to also call the addNotifications action which is in my Notifications controller. I'm trying to stay away from requestAction based on the warnings, but is there another way?
Workflow is this:
New event occurs -> trigger addition of notification in notifications table -> email user that notification exists.
If it's going to be a notification for all sorts of things, then I would consider something in the app_controller as this will make it available across your whole application. Meaning you'll be able to call something like
$this->Notify($user['User']['email'], 'MyNotifyType', 'MyTemplateName');
Then you can deal with the other bits in your app controllers notify function. You might need to add your User model to your app_controller, which could be tricky.
I would try using uses() as this could allow you to add the model and thus pull user data from your app_controller if you wanted to say include the users last login details, username or formal greeting etc. http://api.cakephp.org/class/controller
If you want to call a method that is based on another model, you need to place it in the model class, so in your example in the the Notification model. You can then call it from your Images controller with
$this->Image->Notification->add($params);
if the Models are associated. If they are not, you could either connect them on the fly or go with the previous proposal and add the function in the appController (which is not really perfect, because functions in the AppController should not depend on a certain model but be generic)
My application is following the MVC design pattern. The problem I keep running into is needing to call methods inside a Controller class from outside that Controller class (ex. A View class wants to call a Controller method, or a Manager class wants to call a Controller method). Is calling Controller methods in this way allowed in MVC? If it's allowed, what's the proper way to do it?
According to the version of MVC that I am following (there seems to be so many different versions out there), the View knows of the Model, and the Controller knows of the View. Doing it this way, I can't access the controller. Here's the best site I've found and the one describing the version of MVC I'm following: http://leepoint.net/notes-java/GUI/structure/40mvc.html. The Main Program code block really shows how this works.
Thanks for any answers.
Take a closer look at this paragraph from the article you linked to:
View
This View doesn't know about the Controller, except that it provides methods for registering a Controller's listeners. Other organizations are possible (eg, the Controller's listeners are non-private variables that can be referenced by the View, the View calls the Controller to get listeners, the View calls methods in the Controller to process actions, ...).
You have the observer pattern here between the View and the Controller. MVC is not a single pattern per se but at least two combined.
One way to get your head around managing the View/Controller communication is to use events. The View fires events on certain user actions (without knowing necessarily who might handle them.) The Controller processes these events and acts accordingly.
I'd like to know where the controller gets the user input from (to feed the model with). Because input media is strongly related to the user shouldn't the view be aware of the concrete way to get the user's data? But how can I separate the controller from the view then? Is it possible to make both completely independent of each other as their purposes suggest?
Example:
When I have an application which uses the curses library for the view it implies that the it's only accessible through the terminal. Using curses methods to read user data in the controller would break encapsulation but calling methods on the view would have nothing to do with displaying the model.
IN MVC, the controller gets its user input from the View.
Consider having the View and Controller communicate through the Observer pattern. The Controller registers itself as an Observer with the View. When the user inputs data into the View and presses Enter, then the View interprets the data and notifies its observers that there is data available. The Controller can then get the data from the View through a public method.
I dont think that the view really has much to do with inputting data actually. I find MVC much easier to visualise if you see the user as communicating with the controller directly. A controller receives data from the user and sends views back. In many systems the view engine has some limited way of updating itself (ie text inputs display what is typed before it is sent to the controller). But for any MVC type architecture you can replace any view with any other view provided they are both capable of handling the same data.
For example. Entering a username can be done on any system that supports entering strings. The controller accepts a string, and so can be used in a web application, a terminal application, or a GUI application.
I think the view should have a callback on the controller to send over user input. In web architecture, the callback is provided through the ability to send the user input back to the server through http requests.
In your case, your ncurse front should probably have some kind of callback method to the controller component to send back user input.
Well,
I'll try to be more specific for you. Giving vague/abstract answers for ppl that you can see, doesn't master the subject, doesnt help.
MVC -> Model View Controler
There are many implementation of MVC, I don't know your case, but I'll give you one.
The most common MVC implementation acts like this..
view <-> Controler <-> Model
In a web scenario..
The view would be your HTML pages and data input would happen in a form.
<form action=/home/createuser method=post>
...code goes here...
</form>
Home would be your controller (a class named home), and createuser a method in home.
public class Home extends Controller {
public void createUser(Userform f){
...create user...
}
}
This form would submit data into the method as parameters. Createuser would them processed to talk to the model and later persist the data if thats the case.