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.
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.
I have been building multiple grails applications, which are basically just the different tabs (4) of my web dashboard. I had initially thought I could simply make a sidebar and use different views, their corresponding controllers and also their corresponding domain classes simultaneously in my final single grails application.
But, after reading the documentation I don't think this is feasible. Or am I wrong here?
So, I need to combine all of these and make one final grails application with a sidebar having 4 options there, wherein on clicking on each of the options - a different view is rendered.
But these different views are connected to different controllers and different domain classes.
Can these all be combined into one grails application? If yes, how do I go about accomplishing it?
I cannot find any documentation regarding these.
One useful link : http://javadeveloper.asia/grails-ajax-tutorial-remotelink-tag/
Any suggestions/approaches will be highly appreciated.
I come from an Asp.Net background and I'm evaluating Asp.Net MVC for a new project. I can't see how to structure a large project adequately.
I'm happy with the Model/View/Controller architecture and I'm presently trying to get Areas to work (which seems quite complicated for what it is).
Can you have Areas within Areas?
Can you put Views in dlls?
I really need a starting point here, are there are resources which show how to structure large MVC projects, assume that eventually there will be 100+ views in the project, I don't want them all in the same folder and ideally I'd like sub folders
thanks for any help
Edit:
I can see that each controller maps to a View folder, what I want is something more like this
Areas
Mail
Absence
SimpleAbsenceController.cs
ComplexAbsenceController.cs
Overtime
SimpleOvertimeController.cs
ComplexOvertimeController.cs
Etc
Edit2: Perhaps this is more of a routing question, can I map from:
http://www.mystuff.com/SimpleAbsence/Index
to Mail/Absence/SimpleAbsenceController
Fundamentally I want a way of structuring my project into folders
I hate answering my own question as I feel it undermines the work of others who try to help, at the same time others may look at this later and these really are newbie questions, so...
(this is all from reading Pro ASP.Net MVC5, good book)
I wanted to know how much flexibility there is in Asp.Net MVC with regard to using subfolders or dlls. This answer address the subfolders question.
Answers
You can put controllers where-ever you like in terms of folders on the disk, these are compiled, but...
When you use areas the MapRoute in the AreaRegistration.cs file automatically limits
the routes to the namespace for the area. So if for example you move a controller to an area you -must- change the namespace or methods like Url.Action will fail
Views must stay where they are, so for a controller called Fred there must be this structure:
View
- Fred
- Action1
- Action2
- etc
You can work around all of this using your own routing system, you could probably work around the namespace issue with a custom route, but my view is as a newbie you should work with the system until you know enough to fully understand the consequences of breaking the rules
So this means you could have a large project with a few hundred Views all lumped together in one folder. It's not quite as bad as it seems as the controllers can be in sub folders and you can directly map from them to the Views.
You also have flexibility in the routing system, so regardless where controller are on disk you can have any urls you like!
e.g. this route maps from
http://www.example.com/App/DoSomething to
http://www.example.com/Home/Something with no changes necessary
routes.MapRoute("NewRoute", "App/Do{action}", new { controller = "Home" });
NB If you do this make sure to use Html.ActionLink or Url.Action (or equivilents) as opposed to direct links, these are clever enough to generate the correct urls based on the routing.
As I say, complete newbie issues but I'm sure others will have the same questions, thanks to MiniRagnarok for his example of a real life project
What we're talking about here is very opinion based. I've seen people that prefer to have lots of Controllers with a mapping of every object to a Controller. I've also seen people that prefer to have tons of Views. So my example is what our team has decided to do and not necessarily the same as you would see in sample tutorials.
Take a project we did that has 200+ Views for example. The site is an auction and retail site.
Controllers
AccountController.cs
AdminController.cs
AuctionController.cs
HomeController.cs
PhotoController.cs
StoreController.cs
SupportController.cs
Views
Account
DisplayTemplates
EditorTemplates
ChangePassword.cshtml
_Favorites.cshtml
Settings.cshtml
Admin
Auction
Home
Photo
Shared
Store
Support
For us, we name all partial views with an underscore first. We also utilize DisplayTemplates and EditorTemplates. All of this really helps us keep things separate. You'll notice that our controllers are split by role or function. We were never bothered by the fact that there are many ActionResults within our controller since all of our logic is really in the models.
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 know this is odd. but I can't figure other ways to do what I need.
I have a controller: report and a view: report.
Also I have a view that acts as a dashboard where I can see several zones (partials).
I need to add this report view to my dashboard but don't know how.
This report view utilizes complex logic from controller and displays the results.
How could I "stuck" the (logic+presentation) of exising view (report) into my partial, so I could use it on my dashboard??
Thank you.
Valve.
(I hope I'm understanding the problem, here...)
This part seemed significant:
This report view utilizes complex
logic from controller
As a general rule, controllers should be simple. Really simple. The rule of thumb is "thin controller, fat model" (Rails Envy made some entertaining but useful screencasts on the subject)
What would happen if you created a new model (quite possibly not inheriting from ActiveRecord::Base) that encapsulated the logic you want to deliver into the partial? Then different controller/action combinations can deliver the information into your views as necessary/required.
Or have I completely missed the point (not impossible!)
I had a similar problem a while ago, when they deprecated render_controller. The only solution I found then was to use ajax, passing a parameter to the page you want to load that bypasses the layout.
If I'm not mistaken you can do a render_component, but this is completely frowned upon nowadays.
This is the easiest way to your problem though
I would suggest to refactor the code from the report controller (if this is the one that contains the "complex" logic) and put it into a wrapper class that can be used by the dashboard and report view.