cancan did not work with a controller that did not have a class. So I created the userhome.rb model:
class Userhome
end
There is an action in the userhome controller that accesses a page in another directory/class. An attempt to access it yields the following error:
undefined method `find' for Userhome:Class
Is the best thing for me to do...:
delete the userhome model, and
remove "load_and_authorize_resource" from the userhome controller, and
just lock the application down with cancan in every other area possible?
Or is there a workaround to deal with this error?
Take a look at the CanCan documentation on non-RESTful controllers.
A "resource" is the "thing" that your controller is responsible for listing, creating, updating, etc. It often is a model, but need not be (e.g. you might have a "search results" resource that doesn't have a corresponding model).
If your controller really isn't dealing with a resource, then you may want to just use authorize! as appropriate within the controller, but if the controller is dealing with a resource but there is no corresponding model (which sounds like it may describe your situation) then you may want to use authorize_resource and specify that there is no corresponding class. This lets you "pretend" that you have a resource (i.e. you can specify abilities based on actions on a resource) without actually having a model that represents that resource.
Related
So I have my custom entity type, created it by following official tutorial:
https://docs.sulu.io/en/2.2/book/extend-admin.html
However entity I got is not translatable like i.e. standard pages or articles. I also didn't any info on how to make it translatable. Expected behavior is just to work as those standard types.
How to achieve that?
There are basically three things to do:
You have to add a new Translation entity for your custom entity. So if you have an Event entity, you need an additional EventTranslation entity. See https://github.com/sulu/sulu-workshop/tree/master/src/Entity
You need to tell Sulu, that your custom entity is translatable by adding the available locales to the view in your AppAdmin class, see https://github.com/sulu/sulu-workshop/blob/master/src/Admin/EventAdmin.php#L74
You need to adjust your custom entity's admin controller (it will receive a locale request parameter now) to persist the localized properties to the CustomEntityTranslation instead of the CustomEntity iself, see https://github.com/sulu/sulu-workshop/blob/master/src/Controller/Admin/EventController.php
So as conclusion, Sulu is only responsible for showing the locale switcher in the upper right corner and appending the current selected locale as locale parameter to your api calls. Everything else is completely up to you, you have to implement that like in a normal symfony application
Just wondering really if there's a consensus on the 'right' way to do this, for MVVM, DDD, and other philosophies . . .
So I've got a login screen, represented by a ViewModel, LoginViewModel. It can take a name and password. It also takes in through dependency injection a LoginService, that implements the logic of taking the username and password, and retrieving the Employee object.
My question is what's the 'right' way to get this information to the next view model? Let's say it's AccountSettings, which needs to know about the logged in employee. How do we encapsulate that? I've got an AccountSettingsViewModel, but should it require
a) An instance of the LoginViewModel?
b) An instance of the LoginService, which keeps a reference to the logged in employee
c) A shared object or field on a global object, like App or something?
Thanks in advance!
Personally all my view models in DDD or otherwise are simple data containers, used to restrict the data that gets sent from the application to the UI/view. I might include some code in my view models that's specific to transforming data for that view. I also consider my view models to be coupled to my views (I only mention this because I've seen 2 teams put them in their own separate project/assembly away from the views!).
If I have anything copying data, or performing actions to get the data needed for the view model, this would live in either my domain model or my application layer, probably in a service. I wouldn't ever inject a service into a view model.
It seems that Spine's Model.updateAttributes only updates attributes, and does not create new ones in case you supply any.
In my usecase, I have a controller that creates part of the attributes. Then through an Ajax request the server responds with the full object, and I want to update the model instance living in Spine with the additional variables.
For example, I have a model with attributes: name, date_created. Through the controller a user instantiates an object providing only the name. An Ajax request notifies the server which in turn responds with a name and a date_created. This date_created should then be added to the user's model.
Model.updateAttributes doesn't work, and I wouldn't be too fond of deleting the object and creating a new one - that just seems as too much overhead. I could provide default values for variables that are not set upon creation, but that also has a negative side. I guess what I'm looking for is a method that could be called Model.createOrUpdateAttributes. Can anybody recommend a way to achieve this? Thanks!
I might haven't fully understood your usecase, but I'll try to answer.
You need to declare whatever attributes a type of a model has with the configure class method. This declaration helps various model function to do their job later.
After you declare all the attributes you need, you can create model instances with any of the previously declared attributes.
You don't have to provide values for all the declared attributes.
After the ajax call returns, the date_created will be set on your model instance. Until this happens it will be just undefined.
If this solution still can't work for you, please describe why, and I'll gladly try to help.
So I have a Rails 3.1 app that contains nested resources:
resources :projects do
resources :todos do
resources :tasks
end
end
I have defined my backbone.js models like:
var Task = Backbone.Model.extend({url:'/projects/1/todos/20/tasks'})
I can now create a new nested task as simply as:
task.set({description:"This is backbone.js created task!!!"})
task.save()
This, is pretty awesome.
However, note that I hard-coded the project/:project_id/todos/:todo_id/tasks url.
Of course, I can generate this dynamically but I was wondering if there was a better way.
Thanks for any suggestions.
Backbone.Model.extend is used to create subclasses, not objects, so creating a new class with a static URL and then instantiating it seems to be a particularly hairy method of going about things.
For problems like this, I'm very fond of Backbone Relational, which allows you to define a parallel set of structures as classes in Backbone, and have the Project object upload itself with all of its associated ToDo and Task objects. You would only ever send Projects as the RESTful "coarse document" you send to the client and receive from the client. See The Richardson Maturity Model for a discussion of REST, because backbone fully supports this particular model.
Another way is to SOAPly send change messages as updates, but that would take some hacking and understanding of Backbone's internal sync method.
What is the best practice to switch a boolean attribute e.g., un-/publish an article?
For the Model side, I saw Object.update_attribute(:only_one_field, 'my_value') is best for this job, instead of update_attributes.
What about
the View (use a link, a submit button in a form, other ideas?) and
the Controller side?
Views usually use forms for updating models. The form_for helper makes this pretty straightforward.
If you are using a standard update action (your controller inherits from InheritedResources::Base) then your update! method in your controller should handle this fine.
I would actually advise against using Model.update_attribute(:published, value) unless you are aware that this call bypasses your model's validations. This is generally why forms just post to the update or create methods in the controller - those by default go through the entire ActiveRecord lifecycle, calling your validations as well. If you have a reason to bypass them, then by all means use update_attribute.