I started with a simple controller which would allow a user to create a single instance by selecting a user from a collection select. Initially this was fine but the users ended up needing to perform this action twenty or more times.
To ease the burden on the users I want to change this from selecting from a drop-down to selecting multiple items using check boxes. This turned my simple controller into a complicated function that required a transaction to ensure all or none of the records were created and ended up breaking things in the view such as reporting errors.
What is the best design pattern for this using Rails? Basically I'm looking a good way to do a batch create that still works with the traditional Rails MVC. This must be something that has been encountered numerous times before but I can't seem to find a solution that doesn't require some hacks.
To clean up your controller, you can use Service Object pattern.
https://netguru.co/blog/service-objects-in-rails-will-help
Probably you can split your logic into multiple classes.
Related
I'm a newbie to iOS and now trying to design an app for multiple roles who can log in from home page.
At first, I tried to give each role a completely separate line of its own view controllers. But later, I found a lot of interfaces and codes are the same among different roles and it will be a huge amount of work to copy and paste.
So now, I try to have only one major line of view controllers and then capture the user identity to change the display (hide and unhide functions) according to different roles. But I'm not sure if this is the real preferred way to handle this kind of multirole application?
(If my question is not clear, please tell me!)
Thanks!
have only one major line of view controllers and then capture the user identity to change the display (hide and unhide functions) according to different roles.
This is the most efficient way to do this, because that way you don't repeat yourself. Having too much code (view controllers) for just small changes will create unnecessary clutter, both code-wise and space-wise.
Even if you are a newbie, try to implement best practices wherever you can, because people generally get used to what they did when they were new, and changing how you write code when you are more experienced is much harder.
First you are new to iOS.Now you are going to develop application with
multiple roles like Register,Login,Showing List,Edit
Page,Settings.....etc.If you are a newbie you can create separate view
controller for above thing.If you want to use string,id,number,...or
anything globally you can create singleton class for access that.If
you gain experience or If you get more knowledge,you can create common
view controller and class for accessing functions,variables in whole
project.Now you must learn basic things for creating application and
use without any error,crash.Learn all basics first.
This question is purely conceptual, it does not include any code.
I am building an app with a single User model. I would like to give users the freedom to choose from 3 different site styles. These styles will affect other components of the UX, including a Message model and messages controller.
I am thinking the best way to go about this is to give each user a "style" column, and based on which site style they choose, either save the value as a string or an integer into the users table.
I have concocted a way to use the same Message model and messages controller, and the same actions inside the messages controller, for all three of the different types of users. Within each of the actions of my messages controller, I would basically start off by querying for which "style" attribute the current user has in their corresponding database row. Based on the three possible "styles", I could then use an if-else or a switch statement to complete the right thing inside of the controller action, depending on the current user's style, including rendering a "style"-specific template rather than the default view template.
Is there a better way to go about accomplishing this? Is it completely discouraged altogether? Am I better off just creating 3 different messages controllers, would that be more RoR conventional and less damaging to the performance of the app?
How catastrophic would it be for the performance of my app if I were to follow this approach with the actions of my messages controller and maybe even two more controllers?
Thanks in advance for any insight anyone can give me :)
I've done very similar things with little-to-no performance impact. As long as the changes are purely HTML/CSS/JavaScript this can be easily accomplished with a working knowledge of the Rails Asset Pipeline and a single column in the database. You'll end up hitting more if-statements in your views, but those handful of boolean expressions will have a negligible effect.
Just make very sure that your alternate view styles don't affect your Controller or the Models themselves (save any methods and validations pertaining to your new column in the User table).
Be sure to dish out unique scripts and stylesheets based upon which style the user has selected (it would be woefully inefficient to load a single stylesheet and dynamically change classes to use certain elements, for instance. Instead you'd want to choose which stylesheet to include based upon the user's selected style, and do the same for scripts).
If you have any specific questions about implementing this, feel free to inquire further. In the mean time this will prove to be an important read, if you are not already familiar with the material.
I have a Rails 3.1 "blog" type app and my Post#index has become a sort of overview (or dashboard or sorts) into the whole system. The main content is pulled from the Post model but a sidebar contains info from an Event model, there are other snippets from a News model, etc…
Post#index is a busy action that has to populate many instance variable before /view/posts/index.html.haml gets a call to render and then the many layouts and partials go to work.
Being as some of these other areas are self-contained, so to speak, I'm wondering if there's a better "Rails way" to approach this? Perhaps I should be looking at encapsulating the Event sidebar (which is effectively Event#index) into some kind of entity that can be re-used perhaps in other views? And, if so, how?
What are the options?
You might checkout
http://cells.rubyforge.org/
I would look into widgetizing it. A framework that I looked into in the past was: http://apotomo.de/ This provides a nice clean way to widget"ize" as well as callback functionality (Ajax) for specific widgets.
I need to have two separate pages on the site I'm planning to build that are very similar that I don't need to introduce new DB tables or models. I would also like to stay RESTful.
If I'm to use the same controller/model I will need to have new methods other than standard index, new, edit...etc which makes it non-restful or I will have to have a variable on page that identifies it and then inside each method I will render different view accordingly.
Another idea I got was to have separate controller and model but use the same DB tables and enforce the model to use the table although it doesn't match the convention.
I'm guessing there might be cleaner way to do this. Do you know any? if not which way do you suggest?
Thanks,
Tam
I'm not afraid of the restafarian police! Sometimes your controllers need more than the 7 actions (where's the get to confirm a delete, eh?), sometimes they will need less. That's just the way it is when you start to create real world software.
If the actions you're adding are not coherent with the actions that exist (for example off by just a little bit but still off in most actions), then we're talking about a new controller IMO - otherwise adding a few actions where you need to is ok in my book.
I just finished Scott Gu's Nerd Diner tutorial. I found it very helpful because it not only taught the basics of ASP.Net MVC, but also how to use with Repositories, Validation, Unit testing, Ajax, etc.. Very thourough, but still manageable.
However, I am curious about his site structure:
Specifically, he used this view strucuture for every object:
/ModelObject/Edit/
/ModelObject/Create/
Then extracted the common elements between the two views and put them into a partial.
I understand the logic, but it seems like it would lead to "view explosion" if you have even a moderate number of tables in your database.
Scott's really good, so I am assuming his structure is right. But I would like to know why.
Thanks!
[Edit for clarification]
I realize that many times it is necessary for there to be multiple actions (and views) to handle differences in creates and edits. It is the case of the very simple edit and create, where the only difference between the two actions is in one case the model has an ID and needs to be updated, and in the other case the model does not, so it needs to be inserted.
In this case, is the violation of the "Dumb View" rule by using the same view to handle both cases going to cause major problems?
The view structure is based on the controllers, not the model directly. In the Mvc methodology, you should have a view for each action (each public method, essentially) in a controller. The controller actions don't have to match up directly to each table in database but there is likely some sort of direct relationship between the number of tables in the database and the number of controllers and views. Controllers are higher level
It is standard to have CRUD type actions on the controller, when they are applicable:
Index: list the items
Details: view a specific item
Edit: edit an item
Create: new item
Delete: delete an item
Each of these actions will require a view (and sometimes more than one).
So, yes, you can collect a large number of views if it is a large application. The way to minimize the code is:
Extract shared functionality to partial views, as to keep the action views as small and simple as possible
Keep the views and controllers simple so that they are easy to maintain
Use AJAX to implement more functionality in one view
It's important to point out that any large application is going to have lots of forms. Whether it's Mvc or Web Forms, if there is a lot of data to work with, there are going to be a lot of forms necessary to do it.
It is true that this can indeed lend itself to a lot of views. However, I've found that in my real life applications, I'll have a number of tables that I don't have a 1:1 correlation to CRUD operations. While I certainly have data that goes into those tables, I've found that most times a view presents data from at least two if not three or more tables. Just like every other application, you've got to know what you're after so that you can plan things out. Any large size application is going to require quite a bit of planning up front (which would include analyzing the number of views/controllers for MVC).
It's only the small apps that you can sling together based on you hunches and past experience.
if you have a background as asp.net webforms developer, your answer is natural.
There are several questions, it depends on the point of view. At first, with asp.net-mvc we do not have fully-equiped server controls making many things for us, without a real awareness what they do. Now you have to type more code and have eyes like a surgeon on html.This way I can find a reasonable question for "view explosion"
Other projects follow more or less that structure, see the project by Rob Conery:
Mvc Storefront
PS: "Skinny controllers, Fat Model and… Dumb view"
[Update response to clarification]
Mhh.. I think there's no violation of "dumb view". The important thing is that the all the views has nothing to do with the code in the business logic layer or in your model. You can a have a button "Save", it is the controller has to know which action must be executed, insert or update.
On more reflection, this is what I am thinking:
Combining the edit/create views would be easy on simple models because
- Same properties displayed
- Same validations
BUT doing this would force you to either
- handle both the update and insert in the same action
- use a control statement in the view to determine which view action is used to update
Both options seem ugly and unnecessary when it is so easy to use separate actions and separate views with common code extracted into a partial.