I am working on a web service built on ASP.NET MVC 4 and have run into some trouble figuring out how to manage a model after log in so that it is widely available to all action functions created in the back end.
For example) Let's say I have built a service that allows a user to log in and manage multiple databases. After he logs in he is redirected to a view that allows him to pick which database he would like to manage, which inherits the old layout. After he clicks on the database he wants to manage, the model of this database is passed to the index view of a manage controller which utilizes a different layout than before. All of the managing action links are coded in the layout but the model was passed to the index page. He needs the model to be available for all the ActionResults in the managing controller, but a model can't be passed to a layout, so this is where I'm stuck.
Does anyone know of any good references or guides on how I can utilize a model throughout a whole layout? Or something a long these lines? I'm not sure the technique I used for this problem was the best but I don't know how else to go about this. If anyone knows a better technique of going about this please let me know.
Thank you!
Related
I have a new multi-tenant web application in ASP.NET Core 2.0, single DB.
I've established a method of determining a particular request's 'TenantId' by examining the domain in a simple piece of middleware.
I've also established a DataContext which applies TenantId filters to applicable tables as needed.
The last thing I'm unclear about is how I can differentiate Views/partial views based on the TenantId whilst sharing the controllers.
I think some scheme where the app first looks in some kind of TenantId sub-folder for the customized tenant's view and if it can't find it, it goes through the regular steps to locate the view... might work okay? Is this a reasonable approach? In other words, it should use the specialized tenant view if it exists, otherwise use the default view.
Would this involve building a custom view engine of sorts?
I've tried something similar with tenant based Html fragments, but it was a pain maintaining it, so I'm looking for something more straight forward on this project.
I'm open to other suggestions of how to implement this functionality as well.
Thanks in advance!
You don't need a whole custom viewengine, you can implement an IViewLocationExpander to make it check various locations for views.
In my project I have mutliple tenant support with both shared themes and tenant specific themes. I can override any view by dropping a copy below the theme folder, ie the main view could be Views/SiteAdmin/Index and I can override it in /pathtothemes/themefolder/SiteAdmin/Index
You can see my implementation of IViewLocationExpander here.
How you register your IViewLocationExpander is like this:
services.AddMvc()
.AddRazorOptions(options =>
{
options.ViewLocationExpanders.Add(new cloudscribe.Core.Web.Components.SiteViewLocationExpander());
})
.SetCompatibilityVersion(CompatibilityVersion.Version_2_1)
;
I have several pages of my web application done. They all use the same master page so they all all look very similar, except of course for the content. It's technically possible to put a larger update panel and have all the pages in one big update panel so that instead of jumping from page to page, the user always stays on the same page and the links trigger __doPostback call-backs to update with the appropriate panel.
What could be the problem(s) with building my site like this?
Well, "pages" provide what is known as the "Service Interface layer" between your business layer and the http aspect of the web application. That is all of the http, session and related aspects are "converted" into regular C# types (string, int, custom types etc.) and the page then calls methods in the business layer using regular C# calling conventions.
So if you have only one update panel in your whole application, what you're effectively saying is that one page (the code behind portion) will have to handle all of the translations between the http "ness" and the business layer. That'll just be a mess from a maintainable perspective and a debugging perspective.
If you're in a team that each of you will be potentially modifying the same code behind. This could be a problem for some source control systems but one or more of you could define the same method name with the same signature and different implementations. That's won't be easy to merge.
From a design perspective, there is no separation of concerns. If you have a menu or hyper link on a business application, it most likely means a difference concern. Not a good design at all.
From a performance perspective you'll be loading all of your systems functionality no matter what function your user is actually doing.
You could still have the user experience such that they have the one page experience and redirect the callback to handlers for the specific areas on concern. But I'd think real hard about the UI and the actual user experience you'll be providing. It's possible that you'll have a clutter of menus and other functionality when you combine everything into one page.
Unless the system you are building a really simple and has no potential to grow beyond what it currently is and provide your users with a one page experience is truly provide value and an improved user experience and wouldn't go down this route.
When you have a hammer, everything looks like a nail.
It really depends on what you are trying to do. Certainly, if each page is very resource-intensive, you may have faster load times if you split them up. I'm all for simplicity, though, and if you have a clean and fast way of keeping users on one page and using AJAX to process data, you should definitely consider it.
It would be impossible to list too many downsides to an AJAX solution, though, without more details about the size and scope of the Web application you are using.
I am very new to Flex (started learning a couple of days back), I now have some understanding on how to create user interfaces with Flex and how to do MVC with Cairngorm and I really started liking it. But I am still lost with changing views using Cairngorm or entirely in Flex. Being a Java/J2EE developer for more than 10 years, it helps me understanding new technologies comparing it with Java. Typically in java world or in any MVC framework, the controller once got the updated modal it redirects or sets the new view to the user. Lets say once I added a new movie to movie database, I want to show the user a view Movie screen and when he deletes a movie I want to take user to list of all movies. The example which I have seen so far(including the diagram explorer) are just changing the modal values and the data is updating in the same view (using [Bindable]), but my question is how to change the view depending on the result or if it's a fault I want to take user to a different screen. How to do that in flex and in Cairngorm. Are there any best practices available and somebody please point me to right direction/resource. Thanks in advance.
The usual way to do this with Cairngorm is to put the data about the state of the application (eg. the screen the user is on) in the model too. You can, for example, use the ViewStack as the main container of the different parts of your application and bind it's selectedIndex to a variable in the model which will be used to control the screen that is displayed to the user. Putting it shortly - the state of the application is a reflection of the model.
You may also want to take a look at the Mate framework. We recently switched to Mate after using Cairngorm because we found it was a much easier framework to use and understand.
For your example, you would have a faultHandler event listener that would call whatever method you wanted in your model. You could easily use that to show or hide whatever you needed to.
Has anyone ever tried to integrate AspDotNetStorefront and Sitecore? I've been trying for the past couple of days to come up with a way to get the two systems to play nicely together, but it doesn't seem feasible from what I can tell. A couple issues I've run across so far:
Authentication between the two (AspDotNetStorefront has its own implementation, Sitecore just uses/extends .NET Membership)
The main DLL for AspDotNetStorefront is what pops up in the stack trace when I get yellow-screened, but that DLL is obfuscated so I can't figure out what the problem is.
The biggest issue is that we need to keep our existing AspDotNetStorefront application as an e-commerce backend and use Sitecore to do everything else. AspDotNetStorefront has a CMS as part of it, but it's really not an acceptable solution for anything but really basic content pages.
Any thoughts on how I might go about this?
EDIT:
I've decided to break this whole thing down into the different problems that I am facing at the moment and solve each one as efficiently as I know how. I'll detail the ones I have here and then update when I run into new ones.
Problem 1: Authentication between the two systems.
This one isn't too bad actually if you're knowledgeable about forms authentication tickets, which I wasn't at the time but am learning quickly enough. As long as the two systems share the same encryption info, it's easy enough to pass information back and forth between them using cookies as stated below in the accepted answer. The other kicker is that I needed to set the CustomerGUID in the AspDotNetStorefront Customer table to be the user ID from the Sitecore user tables (standard ASP.NET membership). So far this approach seems to work pretty well (I'm still in the proof of concept stage at the moment.
Another thing to keep in mind if you ever need to attempt this is that AspDotNetStorefront comes with a web service that you can use to basically do anything you need. Since they use the same encryption keys, I am able to log in on the storefront side using this service more securely than just passing over clear text passwords (I had to write the method myself, I don't believe it comes standard, if I am mistaken please let me know). Although I doubt it's a huge deal since it all happens server side anyways.
Problem 2: Getting at the product data
This one was a little more troublesome. The aforementioned web service has a few issues I've had difficulty working around. However, since the databases are going to be on the same server, I simply decided that since all I really need is the price and ID I would go ahead and set the ProductGUID column of each product in the Storefront database to match the Sitecore item ID of the corresponding item in the Sitecore database. This way I just need a quick query to grab the ProductID and price information which is only used in a few places. Everything else is going to be housed in Sitecore.
If anyone has anything to add feel free, as far as I can tell from Google, no one has actually done this before, so I'm having a lot of trouble finding resources on this particular topic.
UPDATE:
The integration is in fact possible and our site has been up for a week and a half now with very few integration related problems. This isn't something I recommend doing really on a personal level, but it is in fact possible to pull off.
I know ASPDotNetStorefront and other CMS systems (but not Sitecore). If I was approaching this, I would probably start simple and create a custom URL structure for sitecore 'content' pages that ASPDNSF would direct to Sitecore to handle. [possibly replacing the existing topics system in ASPDNSF]. So, for example: a URL such as www.domain.com/p-1234-aproductpage.aspx would be handled by ASPDNSF whereas www.domain.com/content/123/a-content-page would get sent to Sitecore to render. This is a straightforward web.config edit.
Security sharing across the systems should be possible across the same domain as the cookie information will be available (you should be able to create some code in Sitecore using the ASPDNSFCommon.dll and a cast of HttpContext.Current.User into a AspDotNetStorefrontPrincipal class to detect if a customer is logged in)
Another way to approach the problem would be to write a function that retrieved Sitecore content from the database based on a URL id and then write an ASPDNSF XML template to use the function to retrieve this content based on the URL. For example, you could create a custom URL structure in ASPDNSF such as www.domain.com/sc-1234-sitecore-content-item.aspx which is sent to your custom code; 1234 is used as the sitecore content id and the XML template retrieves the content and renders it on screen.
This second approach has the advantage of using Sitecore for all non-product content management while keeping the live application in ASPDNSF. Also one set of design templates and all your security issues go.
I have a View which needs to show and hide details based on the users role. I have 2 options
using an inline if statement in the View to show and hide details
Create multiple partial views and use to controller to detect the role and then load the appropriate Partial view.
Im a newbie to MVC so can someone please advise what the best way is for approaching this problem.
If it is something related to how the information displayed on the screen (and it sounds like it is) then it is best to keep that in the view. Personally I would use partial views and only load them when needed, this supports better reuse.
I'd probably do different views for every role. I've found that over time the views for each role diverge in "common" content.