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.
Related
I need to "split" my website to three parts and have its structure lite his
homepage.com/
homepage.com/second/
homepage.com/third/
and in each should have ../login/ and ../user/create/ and all that
Do I need to add additional views and controller for the other ones or it is my server that should do the work (its a tomecat-server, but I have not much experience with it)
or is it something else I need to do?
It sounds like you're talking about Multi Tenancy - there are a lot of options but here's a start:
http://gorm.grails.org/latest/hibernate/manual/index.html#multiTenancy
http://guides.grails.org/discriminator-per-tenant/guide/index.html
http://guides.grails.org/database-per-tenant/guide/index.html
Do I need to add additional views and controller for the other ones or
it is my server that should do the work (its a tomecat-server, but I
have not much experience with it) or is it something else I need to
do?
It really depends on what the application needs to do. Conceivably you could have all of this serviced by a single view and a single controller:
homepage.com/
homepage.com/second/
homepage.com/third/
Don't think of a 1-to-1-to-1 mapping between URLS to controllers to views. You can have 1 controller and many views. You can have 1 view and many controllers. You can map multiple URLs to the same controller. The framework offers you a lot of flexibility around all of that. To optimize that, you have to understand what the application needs to do, which isn't expressed here.
The bottom line is you have options.
Let's say that I have an MVC view that has one set of features available to non authorized users, and an extended set of features that is available to authorized users. Currently, I have implemented this by marking up my view with
#if(User.IsInRole(...)) {...}
in several places in the view file. This wasn't a big deal when it was just 2 or 3 things that authenticated users could do beyond the non-authenticated functionality, but now I have this all over the place in a "dashboard" type of page. It seems to be getting kind of messy.
Is there a cleaner or more elegant way to implement this? I am using viewmodels. I am wondering if I should use different viewmodels/views based on role, but then using different viewmodels seems like it might be more difficult to maintain. I am not sure what the best practice is for this, and I am open to ideas.
Edit
One example of what I am doing: I have several lists/tables that allows managers to edit the record, so the code adds an extra
<td>
for the manager-allowed actions. Another use case: when the manager is signed in, an employee name is now an actionlink instead of just text.
What you could try is encapsulating each portion of the view that will be interchanged based on roles into partial views. This has worked well for me in the past, and is much cleaner when trying to troubleshoot code as opposed to seeing a bunch of #if statements in a single view.
Hmmm. I have this idea. You need list of dashboards enumerations where you have a property like RolesAllowedToAccess (string[])
On the view you can foreach by dashboards enumerations where RolesAllowedToAccess contains current user role.
After you can render partials for each of dashboards. Make sence?
I have a service that is currently given away for Free!
Im now reaching the point where I have enough clients that I want to offer them a "Premium" Version.
So, some of "premium" features will include some extra text boxes on views.
I've built some custom attributes to handle security on the controller, but whats the best way to handle the view?
Should I create another view and present either the free of premium view?
Should I only have a single view? (if so how would I handle showing only certain text boxes\areas)
Suggestions and samples welcomed.
One option would be to make your main URL's very simple, and simply have them render a child action based on the membership level of the user.
Using HTML.Action() you can completely render a different view, and simply have your view look like this:
#model mymodel
#User.IsInRole("Premium") ?
Html.Action("PremiumView", "MyController") :
Html.Action("NormalView", "MyController")
If you have parameters, you can just pass them along.
Also, make sure you mark those subactions as Child Actions, using [ChildActionOnly] so they can't be accessed independently.
This way you can keep your free and premium versions totally separate but keep the same URLs.
You could also use Route Constraints to route to different controller actions based on various factors such as membership level.
You could create a custom view engine that supplied premium content when applicable, then name your views according (e.g. MyView.cshtml & MyView.Premium.cshtml). This gives you the flexibility to extend views with premium content while also not committing yourself to a major change up-front. You'll also need to validate when and when not to accept "premium" changes in the actions, but that should be simple role checking when you go to process.
If your views contain more controls than your models are different and therefore your controllers are different, too. Your paid version may evolve at the different pace than the free version so I would suggest you keep the code separate.
This seems like it would be best done on a per-view basis. If the free vs premium views are mostly the same with a few differences, then I would suggest using partial views within the main view checking the membership status for altering the display.
If there are major differences in the views for UI and functionality, then you might look at swapping out a different view entirely within the controller.
I have a question about how to design my controllers properly.
Project is fairly simple: blog, immage gallery with categories and images inside them, news secion.
However I don't know how to organize my controllers for this because I want to make somewhat admin panel where administrators can edit, add and modify these things. I've came up with 3 scenariosu so far...
Admin panel will have links to site/controller/edit, but layout for these action results will be different from standard one.
Admin controller will have all these actions like BlogAdd, BlogEdit so that url will be something like /site/admin/blogedit.
Create copies of Blog controller in admin folder so url will be like /site/admin/blog/edit - i sense problems with routing since 2 controllers with same name does not sound like a good idea, however I like ho URL looks in this situation.
What I'm trying to make is CMS somewhat similar to wordpress, where blog creation,editing and deletion is completely separated from default blog itself.
I suggest you stop thinking about URLs and Controllers being a 1->1 relationship. This will make things MUCH easier and less confusing. You can make the URLs work however you want with MVC's routing mechanism and there's no reason to restrict your controller design/organization because of the URLs you want, because you can always adapt the routing to with with the URLs you have in mind.
While building the website, just focus on the controllers (and the general interface) and ignore the URLs until you get to that point, and then when you come up with a good URL scheme go into the routing system and add the routes to connect to your existing controller actions as you want.
Once you code out your blogging engine you will have a much better idea of the user workflow and will probably find different ways to organize your URLs, and you can then reorganize your URLs without touching the controllers themselves.
As to your first requirement:
There are two ways to do this depending on your end goal. If your goal is to display the same core content, but have different user options available (different overall layout, additional buttons on the page, etc..) then the best idea is really to just pass in an IsAdministrator property in your view model, and make the slight changes to the page based on if that's true or false. The reason is because you still (most likely) want the core of the page to be the same, and this keeps you from duplicating code that is related to the core data (data that's being displayed for both admins and non-admins).
Edit: So in summary, organize your controllers based on what makes it easier to develop with, not based on how the user interacts with the system with. You can always change the latter, changing the former is harder and will make maintenance annoying.
You can create Areas in your MVC project and have your admin functionality in a controller in your admin area.
This will allow you to easily seperate your administration functionality from your general blog functionality.
That's how I'd do it.
Why don't you keep the routes the same and handle the different roles via security? For example:
/blog/name-of-topic/view to view a topic (all users)
/blog/name-of-topic/edit to edit a topic (only enabled for logged in users)
/blog/add to create new topics (only enabled for logged in users)
You can handle these actions in a single controller and decorate the actions that require logged users via the [Authorize] attribute. Same thing with the links on your views, you would enable the links to edit and add topics only to visible users.
You could still have a separate panel to allow admins to hit the aforementioned add/edit links .
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.