From what I understand, grails applications with the angular profile don't technically need controllers as the domains support the http requests. So, what exactly is the point of the controller class in these grails applications?
Here is an example I am working on:
I have a Wardrobe class, and a Color Class. Wardrobes have colors, and I want the functionality to add and delete colors from specific wardrobes. However, colors may be a part of many different wardrobes.
I understand I can just add a color to a wardrobe without the controller class, by calling a post request to my 'localhost:8080/color' specifying the wardrobe. Can I also delete a color from a wardrobe with the same logic?
If this is true, why do I need a controller class? In this tutorial, I notice they leave the controller class out. https://www.djamware.com/post/5a10b5f580aca75eadc12d6c/grails-3-angular-5-profile-crud-web-application-example
Just wondering what exactly is the point of having a controller class when working with angular, and when it can be avoided and when it is needed.
Thanks
From what I understand, grails applications with the angular profile
don't technically need controllers as the domains support the http
requests.
That is not the case. We do not support routing requests to a domain class.
In this tutorial, I notice they leave the controller class out.
https://www.djamware.com/post/5a10b5f580aca75eadc12d6c/grails-3-angular-5-profile-crud-web-application-example
It is not really true that they left the controller out. There is a controller there, there just isn't source code for it because there doesn't need to be. The #Resource(uri='/customer') annotation on the Customer classes causes CustomerController to be created at compile time.
Just wondering what exactly is the point of having a controller class
when working with angular, and when it can be avoided and when it is
needed.
When working with Angular (or anything else that wants to send a request to the Grails app), a controller is generally the thing that will receive the request and decide what to do.
Related
I'm writing an application that details an applicant's status in our company through Salesforce; when one of our employees enters their Enquiry ID, it shows their status (cleared, not cleared) and, if not cleared, what the applicant needs to fix before they can proceed in their program.
I want to make sure that I am thinking about my application's different areas correctly. Here is what I have:
Model: The applicant class has a dynamic function, such as Application.find_by_Enquiry_Token__c_and_Account_dot_LastName_from_Opportunity, and when requested it returns the information from Salesforce
Controller: Parses the returned data from Salesforce and creates hashes with the information, such as #applicant[:general_information] = {:first_name = data[:Account].first[:FirstName], :last_name = data[:Account].first[:LastName]}.
View: Displays the information generated by the controller. However, it has it's own logic and checks, such as changing the color of a div depending on if they are clear (class="success"), if they are not clear (class="danger") or if they have some conditional information (class="warning").
I think I have this correct, except I'm a little worried about my view because I have a bit of Ruby code in there to perform checks based on the returned data, mainly to colorize but also to show certain errors. Is this okay/does this follow standards? Or should I try to refactor my application and push this up to the controller?
I would say having some ruby code like you do in the view is fine as long as you aren't performing long queries or setting instance variables in the view. Also another sign to start moving code from the view to the controller is if you feel the view is getting cluttered and hard to understand. From what you said, this seems like it is not a problem though.
One thing I would recommend changing is to make the method name on the model shorter. Shorter method names are much easier to understand and as you have it, the method name is very long and unwieldy. Other than that, I think you are doing everything well!
Displaying the correct classes in the view is fine and can't really be done anywhere else. If you feel like your views are getting messy, consider dividing them into partials or using Haml for views instead of ERB.
Model is where your application's business logic goes, including parsing data, and everything related to your domain.
Controllers handle interactions with the user. So, basically, in a webapp if a user goes to a URL what should your application do. This should not be doing anything other than handing off tasks to other classes and then rendering a view.
Views are just that. They should be super simple and straightforward as possible. You can extract logic from views into helpers or even presenters/decorators. Views handle what gets displayed to a user.
In your app I would have:
SalesforceApiGateway class which handles communications with Salesforce, I wouldn't be surprised if there was already a gem out there to handle this.
A model class for each Salesforce resource you are accessing. These would setup the proper call to the API gateway to pull the right data for the given resource.
This could get hairy quickly and may need to be extracted further: 1 class for interfacing with the gateway and a model class the resources as you would want to access them from your application.
Your controller should not be parsing any Salesforce data, but rather taking a user request and and wiring that up to the proper model.
The biggest thing to keep in mind is your classes should be doing one thing and one thing only. If you can't talk about your class without saying "and" then it is probably doing too much.
So you have a class that interfaces with the API. You have a class that parses the API. You have a class that brings an api's resource into your domain, etc.
I'm quite new into groovy / grails world, so forgive for asking simple question. I'm pretty sure this can be done by meta-programming, that is injecting method into definition of grails controller class or so. Can anyone point me where should this injection be written (Bootstrap.groovy?).
I'm trying to create currentUser() method with Spring-security-core plugin that I could use in any controller.
Your question is answered in these two posts:
How can I add common actions to controllers without using inheritance?
Add methods to controllers
However there are a couple of other approaches you might consider ...
You could just inject a "SecurityService" into controllers that need to know the current user and put "getCurrentUser" on that.
You could use a Grails filter to add "currentUser" to the params map available to all controllers. I like that approach as I usually use a filter to implement security anyway. The filter can also add it to all models prior to view rendering so all your views have access to it.
Using Rails, I am building several sites which are very similar. I want to implement these as one Rails app answering to multiple domains, and change what is presented and the processing logic based on the domain name. The areas I need to change/skin per site are:
Views: The fields on a page differ slightly by site. Some sites have more/different fields than others, but there are some that are common across all
Models (which seems best to do this by defining a super class for the main model which varies and implement a subcalss for each site)
Controller logic. There is a lot of similarity but a few small processing differences, including which Model subclass to deal with
CSS (which seems fairly straight forward)
I have already implemented a mechanism which makes the current domain/app name visible to the views, controllers and models.
I was thinking of defining a view partial per site and using ERB logic to include the right one. The controllers seem like the least obvious part.
Any suggestions very much appreciated.
Cheers
Paul
I have implemented something similar for our application, HiringThing (http://www.hiringthing.com)
To do so, we use a before_filter on the application controller that parses request.host and determines what website the request is for. That then sets a variable #site that we reference in views, controllers and models to determine versioning requirements at runtime.
I'm building an application that among other things allows users to upload documents. I have the basic create/view actions working just fine, but i'd like to reuse this action in other places.
I want to know if anyone has a pointer for how to do this. There doesn't seem to be a very good way of doing this.
Here are a few ways i've considered:
Try to do a chain(). This doesn't work since chaining does a GET, and to upload you need a POST.
Break out the main business logic into the Grails "service", and make two actions that use the same code.
Use a JS modal window. I've been thinking a modal that contains an iframe to an "unskinned" version of the document upload. The trick here is to get the window to close when the upload is done.
Thanks
--Matthias
I don't care for the extending controller method. In fact, I avoid inheritance when possible. I'd rather put the common code in a service class and reuse it that way.
You can use a base controller class, and place the common functionality there. Then extend the base controller and call the method from other action methods.
I have the following Filter on my Controller:
[Authorize(Roles="Admin")]
public class AdminOnlyController : Controller
{
// stuff
}
I showed a couple of guys here at work what I'm doing, and a huge debate emerged with some of the guys claiming that Authorization should not be a responsibility of the Controller. This is the way I learned to do it, according to the book Pro ASP.NET MVC Framework by Steven Sanderson.
None of the other guys were able to suggest how it should be done, other than that it was wrong.
Is it? Is there a better way?
The simple answer is yes - that is the best way. The Controllers' Actions are the end point for ALL requests to the application. It makes perfect sense to put the authorisation there.
You could farm the authorisation out to IIS, but that worked better when access was controlled to files (.aspx etc). Now we have a MVC with which you have to control access to multiple actions within one controller.
There's two ways to assign authorization. The controller class or the ActionResult. As opposed to how else you could do it, I'm not very sure.
I don't really see the side of the argument where you argue against the controller managing who's authorized to invoke it. By having the authorization nearby, you follow theory (I forget the name) of 'declare it as close as you can to where you use it.'
It might depend on the background of your coworkers. If they're really used to using something like XML, then I bet they're suggesting some type of configuration file - which seems to be induced due to a more corporate type of programming.
On the flip side, There could be a benefit to extracting out authorization somewhere else (but within the application) so that it's easily modifiable, in case you end up adding a "PaidUser" for example. In that case you wouldn't have to go to every controller to update it. However, I think you end up falling into an all or nothing approach - where it's either in the controller, or it's all in some configuration file. Unless you create a scheme that your central authorization can be overridden by a controller's authorization, except at that point, you can easily lose control of who's managing what and you end up in an 'authorization soup' of sorts.