Currently I'm using resources files to localize MVC4 project in a standard key/value way. I'm now looking into best solution to separate some keys based on controller/action they belong to. There is always raw solution in creating keys such as Home.Index.Title but that's just workaround. Is there a way to work with resx files where they could be designed with parent/child nodes, where highest node would be Controller, then Action and finally Field, so that they can be queried by LINQ?
Resx files always have a simple key/value structure. If the aim is to organise the resources and make them easy to locate for maintenance, I can suggest a couple of other approaches.
If the resources in question are for use in views, you can create one resource file per view in an App_LocalResources folder within the view folder and organise them that way, indirectly linked to a specific controller and action.
If the resources are for use in the controller itself, you can create a set of folders within (say) a ~/Resources folder that represents the controllers and within each, a resource file for each action. That way, the resource namespaces will indicate the controller/action where the resources are consumed.
Related
I've an existing MVC3 project that implements a certain functionality, this project has it's own views, and a separate Database.
now I'm required to use the same functionality inside one of my orchard project,so I thought that I can host this solution in somewhere and view it inside an iframe or something.
Am I thinking right?,
is this the correct step to take in order to achieve this requirement inside Orchard?
to make it more clear, all I need to do is to view this solution and interact with it's controls and views from a hosting page inside orchard, and the subsequent requests should be handled by my solution in order to hit it's own data store and get back with the requested data in order to be displayed to the user.
any help would be appreciated.
Update:
thanks for Bertrand Le Roy for his answer, I can now view my solution inside my
orchard website.
I came in to one more HUGE problem, which is that my application can no longer connect to my external database.
I've a DB that is hosted in some where else, and I'm using EntityFramework to deal with it.
the problem is that if I put the connection string inside my module web.config, or main orchard web.config, I run into several types of errors like:
"System.Reflection.TargetException: Object does not match target type."
or
"System.Data.MetadataException: Unable to load the specified metadata resource."
My question is: How could I pass my connectionstring correctly to my solution, assuming that I'm using Entity framework as my ORM.
Many thanks.
You will need to put it into a module.
You will have to move route definitions to a Routes.cs file (look at any existing such file for examples).
You will also need, in order to access your data store, to opt out of the ambient Orchard transaction around the data access code (using (var scope = new TransactionScope(TransactionScopeOption.Suppress))).
If you are using dependency injection, you may have some work to move that to the Autofac-based way of doing things in Orchard.
If you want your work to appear seamlessly in the Orchard admin, you may want to decorate your admin controllers with the Admin attribute. If you want your front-end to use the current theme, you'll have to add Themed attributes and maybe refactor your views so that they only emit HTML for the content zone instead of for the whole page.
Add a manifest (module.txt) to your module folder and you should be good to go.
As often happens, I have a nice solution to one problem, which unfortunately causes another.
We have an app that provides services to members of various organizations, parts of a larger parent. The organizations require custom URLs. So, members of org A access the URL https://server/vdir/OrgA, and members of org B access the URL https://server/vdir/OrgB.
Both of these would map to the exact same area, controller, and action in the app, although they might look different to the end user due to some custom view content.
Because the list of organizations using this app is dynamic, and because not all organizations will start using it at the same time, I started out setting up the route mapping programmatically. In the target Area, I override the RegisterArea method, pull the active organizations from the database, and execute a custom context.MapRoute call for each.
Doing it this way avoids another problem, which was that the the URLs that have the organization sitepath ("OrgA") in them look exactly like those that have a meaningful area name in them, which actually does map to an area. Treating the organization sitepaths as virtual area names and explicitly mapping them to the target Area avoided certain misdirections.
And this works, nicely. But: it's all executed at Application_Start. If we add an organization, it doesn't become active until we restart the app, which would be highly disruptive to anybody who was using it at that time.
So my questions are two:
Is there a better approach than mine for doing this? I did research the problem, but the relevant keywords are so ubiquitous that it was a bit of a needle-and-haystack situation.
If there isn't one, is there a way to refresh the route mappings without restarting the app?
Phil Haack wrote an article dealing with exactly this problem.
The really, really short version of which is that you place your route registrations in a file other than Global.asax and cache the contents of that file. The cache has the file as a dependency and calls a method when the cache is invalidated (read: file is altered) that re-registers your routes.
I have been doing a lot of research on MVC and file structure. Mainly I've been looking at how to start a new layout. I have downloaded a few open source applications to take a look at file structure and how files are developed.
In the first application it was set up to use the standard way (at least the way it seems to me) of putting all the controllers, models and views each in their respective folders. This is the way that all the books say to do it.
In the second application, all folders are in a modules_core or modules folder where each controller (at least what I would assume to be controllers) are in a folder in there that contain three folders: controller, model, view.
Which of the two versions is accepted as standard and common practice? Are the two applications different because of versions of Codeigniter?
The standard of Code Igniter is to use those three folders:
Controllers
Models
Views
You can also create sub folders to better separate your files.
Searching a bit, I found that MyClientBase use something called codeigniter-modular-extensions-hmvc that is like a extension for CI.
Modular Extensions makes the CodeIgniter PHP framework modular.
Modules are groups of independent components, typically model,
controller and view, arranged in an application modules sub-directory,
that can be dropped into other CodeIgniter applications.
HMVC stands for Hierarchical Model View Controller.
I don't have experience with hmvc so I cannot tell you what is better. For the standard CI structure, try to separate well in sub-folders (controllers, views and models) related files and try to use helpers to better reuse your code when you need to use functions in more than one place.
I think MyClientBase (which seems to be far from the "standard" exemple), seems to be using HMVC more then MVC.
I'd just like to get some clarification in the MVC pattern as to what belongs in Models, specifically the contents of the Models folder in MVC3, versus repositories and objects.
Right now, in my current MVC3 Solution, I have 4 projects:
A Project called "Objects", which holds information about all the core objects in my application.
A Project called "Data" which holds information information about the Data Context and repositories for each of the objects (created using MVC3 scaffolding)
The Web project, which holds the Controllers, Views, and -- the subject of this question -- Models
A Unit Testing project
What I really would like to get clarification about is the difference between what should go in the Objects project vs. what goes in the Models folder of the web project. Right now I'm only using the Models folder for holding what I'd call "View Models", which typically contain combinations of the core objects. Should the files in this folder only contain definitions defining the model contents, or should it contain other code that the controller may call?
I think that I have a pretty good understanding of both controllers and repositories, but sometimes I get confused as to whether certain code should go in one or the other. Are there any specific guidelines or limitations out there as to what absolutely should NOT go in a controller but should go in either a repository or a model instead?
Thanks as always.
We do something very similar except that the Objects and Data are combined in a Core library which is referenced by all projects. The models folder in the MVC project is strictly for View Models.
If your controller require additional classes, it really depends on what it needs as to where it goes. I will typically include a Helpers folder with subfolders for HtmlHelpers, Attributes and Filters. If it's a dependency that makes sense to exist outside the MVC project (common classes which are used across all projects) I'll add it to Core.
I am delving into custom validation attributes and am curious to know how others structure the projects. Where do you typically store custom attributes?
My first thought was to simply create a new folder and be done with it.
Any suggestions?
My first thought was to simply create a new folder and be done with
it.
It would depend on the nature of those attributes and what thety are supposed to do. For example if they are validation attributes you could put them into a Validators folder. If they are action filters you could put them in the ActionFilters folder, etc... so your initial thought is correct. Personally I group those attributes based on their function and place them in a separate folder which indicates this function.
I use 2 different approaches.
Set up a common Class Library to store common validation that will be used on many MVC applications. Then reference this library from your MVC application. You can use http://dataannotationsextensions.org/ to view the source code on how to setup this project.
Place them in folders as suggested by Darin. This folder would be used to store custom validation. If you app was used to keep golf scores a custom validation only to the application could have something to do with a handicap calculation or something specific.
Thanks,