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.
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.
I'm rewriting an app to ZF2 and I got stuck on problem of aggregating views from many modules on one page. What I want to achieve is to separate functionalities into modules, but still be able to display their views/actions (not sure how to name it) on one page. Let's say I'd layout a page with 4 containers and each of them would display some view from 4 different modules. Is it possible, if yes then how? Or maybe my though process is wrong here (I'm set on separating those functionalities though).
I've tried defining same or similar routes (eg. Module1: /boo/[:yah], Module2 /boo/[:whatever]). It didn't work because first module loaded was apparently served. And it looks like a mess too.
I've read a little about view helpers, but seemed to be aimed at a different purpose of providing common functionalities across many views. Whereas what I need if something like a layouting helper, view aggregation or something. I've worked with a home-made framework before that had this concept of site controllers, that would fire up different controllers actions. I can't find a way to emulate this in ZF2.
I'd appreciate any suggestions.
I've been applying forward plugin for this purpose as described in the blogpost suggested by Sam. It doesn't look elegant, but then I can't think of anything better myself.
I didn't see anyone talking about this. What I have is login logic that's common to three projects. I have my model in one project (shared).
Can I have the controller and views in another shared project? I just don't want to have to duplicate things in each.
Also interested in any other ideas people may have to solve this problem.
Robert
Take a look at Precompiled Razor Views
Well, when it comes down to loading views, you can implement your own ViewEngine and instruct it to load your view from wherever you want (database, dll, ...). I just saw a nice video from TechEd NA yesterday, where the creator of the spark view engine shows how to implement it. In your case, you can just fetch the view and feed it into the razor view engine. You should have no problems, since razor was designed to be flexible, and you can easily spawn your own instance of the engine to have it render your loaded view.
I'm working on my first real ASP.NET MVC project and I've noticed that the controller I've been working in is getting rather large. This seemingly goes against the best practice of keeping your controllers thin.
I've done a good job keeping the business logic out of the controllers. I use a separate layer for that. Each action primarily calls a method in the business layer and coordinates the end result based on whether or not the modelstate is valid.
That said, the controller has a large number of action methods. Intuitively, I would like to break the controller down into sub-controllers but I don't see an easy way to do that. I could simply break the controller down into separate controllers but the I loose the hierarchy and it feels a bit dirty.
Is it necessary to refactor a controller with a large number of thin actions? If so, what is the best way to do this?
First, when you hear that it's good to keep controller code to a minimum, this mainly refers to keeping each action method as thin as possible (put logic instead into business classes, not into Views and ViewModels.) It seems you're doing this, which is great.
As for having "too many" action methods, this is a judgment call. It could actually be a sign of good organization, that you're having each action focus on one thing. Also, maybe you're using actions specifically for use with RenderAction? And, it could just be the nature of your solution that there are many things to do relating to your Controller's theme.
So, my guess is that you're probably fine. However, to make sure, on note paper break out the controller into 2 or 3 controllers, and sketch out how your stories would work moving from action to action. And if you find that your workflow works with more controllers, you should break it out. Especially if you're going to be adding to this functionality later. The sooner your break it out the better.
Good question.
I believe a "thin" controller may still need to be "wide" or "tall" depending on how you want to stretch the analogy. If there is no clean way to break up a controller that needs to do a lot of things, I don't think that's a problem as long as each Action is focused exclusively on preparing Views/ViewModels and is of limited code size.
Another structural option you have is introducing partial classes for logical groupings of actions. And using something like vscommands to group the files together.
I doubt anybody can come up with a magic number of actions that tells you when it's a good idea to break stuff up and introduce new controllers, it really depends on your domain.
Another solution can be to separate the controllers based on the business concepts of the actions that are included in them, but the route of each action is in accordance with the REST rules.
However, I think it is better to use this solution only in cases where there is a fat controller, otherwise, it is better to categorize actions based on their output resources.
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.