I have learned much and solved a lot of problems coming up with multi-tenancy.
But one problem still exists. I have to offer a tenant-specific resource file because our customers want some text a little different then other customers.
Is there a way to implement a multi-tenant resourceManager? I haven't found anything else in the www.
We needed the same functionality in a web forms project and ended up implementing our own IResourceProvider, finding inspiration in http://msdn.microsoft.com/en-us/library/aa905797.aspx. That way we could have files like Default.aspx.rex, Default.aspx.da-DK.resx and Default.aspx.da-DK.xyz.resx, where xyz was the customer name. This worked quite well. Going this way seems to imply using the App_LocalResources and App_GlobalResources folders.
However, those folders are not the MVC way of using resources and will cause problems. For instance, they will not work properly with unit testing. As a last resort you might find it useful though.
Related
I'm developing a site in umbraco, and integrating uBlogsy (blog) in it.
But the problem is, uBlogsy offers its own look n feel. However i want to have my existing website design in Blogging part as well.
here is the link for the same :
http://our.umbraco.org/projects/starter-kits/ublogsy
I've done that manually. but its a time taking process.
Does any one knows, how can i do that? is there any automation available for the same?
Or if there exists any better blog than uBlogsy offering same feature and functionality?
Thanks in advance.
uBlogsy is the de-facto blog package for umbraco so i'd be surprised if you find anything better (the community is encouraged to build upon the best instead of spin up many sub-par competitors, but i digress).
I've done that manually. but its a time taking process.
^^This sounds like you have modified the cshtml markup and css from the package. This is indeed the way to go.
There isn't really any plug-in theming that i'm aware of and it sounds like this is what you're looking for, right?
I've used uBlogsy many times on past projects and usually don't keep anthonys files for template views but rather start with fresh markup to match my wire-comps. Since his files are included - they make a great example for how-to access the data.
Sorry it's probably not what you're looking to hear. But i think it ultimately gives greater control and better result to get hands-on.
When you start creating an application or site in ASP.NET MVC, what do you do before typing in that first line of code?
I'm personally fond of creating a new ASP.NET MVC Web Application project and then cleaning out controllers/views until I have what is essentially a blank project (i.e. it runs but doesn't offer functionality). Then I start working on my model and adding controllers/views as needed.
I've also read about starter kits and sample applications but I have not yet started actively working with any of them. However, in my reading I have seen authors suggest that it might be good to start off with an existing template and build on it.
I'm trying to determine if there are better ways of starting off a project such that time is saved and/or the resulting deliverable is of higher quality.
The other things I do (I also clear out the controller/views etc)
Put an IOC in place.
Put ELMAH into the project.
Then I grab a coffee and write my first test.
Kindness,
Dan
PS: At some point I shall get around to creating a template for this so I don't redo it everytime. As soon as I decide upon my favourite IOC. :-)
I usually clear out the Content folder as well and put in place a nice CSS reset file and/or a CSS framework like the 960 grid
Before starting any type of project you must know what you want to do. So take a sheet of paper and start writing on here:
The name of your application
Enumerate the features
Make a quick draft of the domain model (entities that you are going to have)
Try finding the ways (choosing a technology) you are going to do different stuff like: data access, validation (client and server side), logging, IoC, Security, Caching etc.
Do a quick draft of all the views you are going to have in your application
Identify any other problems you might need to solve/implement/develop and think how are you going to do that
Introduction:
Now I know this question could be very broad and it would be too hard to answer without me asking something specific. So All I ask is just some direction, or a brief high level explanation of a design, or maybe there is already some framework out there that could help me get started...I'm not sure.. I have never designed a plugin architecture before, so maybe there is some resource/example you could point me to on the web that would help me learn so that I may come up with my own solution.
Details of my question:
My intention is I would like to create a plug-in architecture for a new pet-project that I am building in ASP.NET MVC.
I would like to design it so that it has some sort of plug-in ability for all, or at least most, of the application's components.
The reason I would like to do this, is so that I may be able to do deployments with nearly zero down time. The idea is that when I want to deploy the latest version I would drop in the new DLLs into a specific folder, and the application would load up the new plug ins and that is it.
For exapmle, lets say I add a new "contacts" feature to my web application where users can search, add and delete contacts. I would like to be able to deploy that by way of plugins.
Is something like this even possible for Web Applications? Or am I just dreaming?
It's definitely possible.
You will need to define a pretty comprehensive interface that represents everything your plugins will have to do. You should approach it by differentiating what is "core" to your application, and where the extensibility points are. For example, where will the plugins be accessed? Will they be tabs on a page, or links in a sidebar? What properties does each plugin need to have in order to fit into the plugin container?
Generally, plugins are enumerated via reflection by looking for assemblies that implement the plugin interface.
Just for encouragement, we've done this with an enterprise product that provides a generic framework for "management" interfaces for web sites. Developers just need to drop in a plugin dll that builds specific property pages, and they show up in the management interface menu, all the navigation is taken care of, and their dll's just have to worry about their own domain logic.
There is always the dll-way where you define some interfaces that plugins follow.
But for web application, especially ASP.NET MVC, you need a controller, views and so. Probably these can be included in a dll file using prepared controller factory to handle that, but it would be hard to develop these plugins.
Some inspiration for code (or db) embedded content: Haacked about that
ASP.NET MVC version 2 will support areas, where you can put some parts of the application into different folders within the app. This way you can just upload some files and the app will recognize these new files. Read more there Haacked blog
PS: I found another person here on S.O. asking the same question as me:
Plug-in architecture for ASP.NET MVC It might be useful for someone researching the same topic.
I've done a large study into using MVC and thanks to the people here a lot of the issues revolving around it have been cleared up for me.
The problems I'm having now revolve around the sheer size of our application and how it would be organised within the project itself. For example, we have url's such as http://mylocalapp/folder/nestedfolder/subfolder/theapp. The reason we do this is because the application quite literally is that large. We need that kind of folder structure because otherwise the application would be unmanageable.
Phil Haack covers the registering of routes for nested folders in one of his blog posts which is very useful indeed, but our application has sub-applications and sub-applications within that. It couldn't be simplified any further.
What steps need to be taken to manage such a large application which spans a large amount of folders and has folders up to seven levels deep, as well as having about 15 databases? Is MVC really the answer for an application of this size?
Is another option simply to apply lots of URL routing and map route areas for all the separate sub-folders?
If you don't need to have everything inside of one application, why not create an MVC application in each folder?
I have a similar situation and what we did was instead of making a "fat" controller, we make them "skinny". Ian Cooper has an excellent write-up here.
So what we did is we broke down the "sub-applications" to be its own application. I think this is what the previous posters trying to convey as well.
As per a comment "Are you refering to "Areas"?" was the answer eventually.
There are a number of questions on this site related to how to access RESX files in an ASP.NET MVC application, and best practices of using them.
However after reading (for the first time I might add) the MSDN article on resources I'm left wondering if there are even any advantages of using RESX files since I'm not going to be using server controls. Theres all this talk of 'implicit' and 'explicit' localization but I'm not going to benefit from that with MVC.
Ultimately my application will need string resources for buttons and menu items and also much longer HTML items for longer miscellaneous content. I would like to use a CMS for the longer items becuase I'm pretty sure I don't want to go sticking them into an RESX file.
Are there any compelling reasons to use or not to use ASP.NET resources in a new application. I'm going to assume that any future MVC enhancements or RESX enhancements will work in harmony together, but for now I'm just getting a glorified IDictionary as far as I can see.
Should I proceed with RESX or look elsewhere? Should I even be considering a CMS for the kinds of resources that RESX is designed for?
Any lessons learned would be appreciated.
There are couple of advantages to the RESX infrastructure:
you don't have to load the proper per-language resources. Once the locale of the thread is established, the CLr takes care of finding the appropriate assembly and loading the resources.
it is easy to hand off the locale-specific resources for localizations to third-parties.
there is a default fallback mechanism for non-localized resources.
There is also one particular disadvantage to the RESX approach:
it is hard to support translation model where the users translate your resources for you.
I'd like to elaborate a bit about that last point. Take for example the Facebook translation model. Facebook has fairly simple way for people to provide and vote on translations of various resources. If these are stored in a database, it would be possible to use them after the proper editorial process without rebuilding and redeploying the application. With the RESX model, the resources assemblies will have to be rebuild and redeployed, which could have high enough cost depending on the deployment process.
Thus, before deciding what localization process to use, I would look at the decision of who is going to do the localization and what the deployment process for the localizaed resources would be after the main application is already deployed.
EDIT: I forgot to mention that these considerations are orthogonal to the ASP.NET framework choice (MVC or WebForms).
I'd say "yes", resx files are still a good option for new applications. I don't think ASP.NET MVC in particular changes anything about storing your strings.
What's great about using resources is
they're pretty easy to manage
localizing your site is a much easier task than without resources (and I stress much easier)
you can replace the resource store at any time because resources use the provider model. You can switch out resx files for db entries without changing the implementation of your site.
I recommend resource files for the "site strings" which are different than the large blocks of data you might edit on a frequent basis. So for a full recommendation, I'd say use resource files (resx to start) for buttons, labels, etc, and a CMS for the meaty content.
If you are going to use Resx and not use Server Controls as you are in MVC, why not extend the MVC Helper methods so you can create localised labels and text? Then simply call the text from resource in the helper method.
e.g.
'<%=Html.CultureLabel("ResouceId") %>'
or
'<%=Html.CultureButton("Name","ResouceId", HtmlButtonType.Button) %>'
Just a thought.
Also managing globalisation of a site is MUCH easier with resx for the text.