I currently have an ASP.NET web application that is serving multiple clients from a single codebase. We use URL rewriting to detect which client is being served (pretty much a virtual vdir) and that drives which master page/themes/module version to run.
Right now, each client can have a different version of a module or the default module. A module may consist of a catalog (grid) of data with various links to other modules, or it can be a chart generation module with options for which data is pulled. The modules need to be themed and localized...
Right now, we make ascx controls (/modulename/clientid.ascx) that are a part of the website's solution. If we haven't registered a control for a client, the default is used. To publish an update to any module a full publish must take place. This can be an issue if a different client has work that isn't ready to be published. For the rewrite I'd like to address this. I'm just not sure what approach to take for this. Can WCF be used here? Maybe add-ins? Each client's implementation is its own dll?
Thanks
you might want to have a look at making the client controls proper skins that just style/load the rest of the control.
so possiblly a base control that all the client controls load (per module) then the client controls are simply markup, this would mean you only need to change the markup and not to code (so you dont have to build everytime)
"To publish an update to any module a full publish must take place" - this is a problem you need to address in your architecture.
Look to de-couple your modules from the rest of your code.
Putting your modules in their own assemblies may be the key to this, as you touch on in your question. This could be addressed by writing your own Server Controls rather than User Controls as Server Controls don't require an ascx file.
Related
Here is the task I'm checking:
1) have a product database, which is managed by another application (it has no relation with sharepoint).
2) now, my boss want to have an application within the sharepoint portal to search this database, plus, audit the searches, i.e. who searched what at what time....
There is no problem if this is a regular asp.net application. But, what's the best way to do this in sharepoint?
My plan is to:
use team site template (or blank template), create a webpart. then have UI, and gridview to show the result.
is this the way to do? I try to find an example of using gridview in webpart, but cannot find it. Is there any limitation of using asp.net control in webpart? what about use ajax toolbox control in webpart? any example?
thanks
Roughly there are 2 approaches you could go for:
The webpart approach, just as your describe it. You can use an ASP.NET gridview with no problems in your webpart. As such, a webpart is nothing more (simplified...) than a user control with some dress up.
Go for BDC/BCS. This will allow you to consume the external database and show the information as be it 'native' SharePoint data. This has the added benefit that the content can be made searchable from within SharePoint. Using this approach you also do not have to create a UI to present the data, as SharePoint will present it using the out of the box view pages, etc.
The downside of the webpart approach (option 1) is that if you have multiple front end servers in your farm you need to handle the session in a way (e.g. by setting up sticky sessions on your loadbalancer, or by sharing your session somewhere centrally (in a db for instance)), as you don't want users to switch between servers in one session while they are using your webpart probably.
The downside of option 2 is that at first it might seem complex, but let that not scare you away :-)
http://msdn.microsoft.com/en-us/magazine/ee819133.aspx
You should code this as one or several web parts. You can use pretty much any asp.net controls in web parts. If you want to use any third party tools like DevExpress you must ensure that the binaries are strongly typed so that you will be able to register them in web.config, note that the registration can be done by the wsp deployment if correctly configured.
Web parts behave as any .net code except for the fact as I mentioned all references assemblies must be "safe".
Using ASP.NET 4.0, IIS 7.5.
I have a website engine, I have just implemented a way for this to tell if it's being loaded on mobile and instead of loading Controls\MyControl.ascx it loads Mobile\Controls\MyControl.ascx. This works well for my controls and also my MasterPage.Master file.
What I can't figure out however is how I can do the same with Default.aspx. This needs to be done on the fly programatically as I need to be able to check if it's mobile version. I was thinking of doing something on a pre-init event in globals but not sure if that's the best way.
Note: I don't want to use inline code on Default.aspx and just display different content base on my Mobile flag as my scenario goes one step further by basing the file on customer as well and this would mean having one huge Default.aspx for all customers which wouldn't be manageable.
Changing the default document on the fly is not possible in any practical sense.
Writing to the web.config on the fly to load a mobile version of a default page is quite frankly terrible and not an answer to the true context of your issue. I would feel irresponsible as a developer if I even proposed this as an answer to loading a mobile version of a default page.
I was trying to help you solve your problem and not just answer the base question in the title. As we all know, changing the web.config will restart your application and would not serve as a true solution, as you could not do this and achieve any kind of performance.
Here is the BEST alternative (IMHO) to dealing with mobile browsers.
http://51degrees.codeplex.com/
HTH!
For anyone else looking at this I have found a solution but I am not sure I will implement it as I don't like the idea of updating the web.config file at run time. Using the Microsoft.Web.Administration namespace you can update the server.webServer -> defaultDocument section programmatically. Doing this allows you to change the path to default.aspx and it will load based on the variables you set.
This link should provide more information: http://blogs.msdn.com/b/saurabh_singh/archive/2007/11/24/accessing-iis-7-0-features-programmatically-from-configuration-file-s-c.aspx
Also, the Microsoft.Web.Administration dll isn't available directly in VS so you need to add it from %windir%\syswow64\inetsrv (64bit version).
We're having a restructuring on our application and currently the idea is to break the codes into Core library codes + customized codes for our developer.
I'm thinking of the possibility to have a folder (i.e. 'custom') that is empty by default, and when the developer need to customize any codes either from existing asp pages or new pages, they just need to put them into the folder and it will work. Example:
Lets say core folder store the default asp pages.
core\customer\createCustomer.asp <-- the default page
And when the developer want to overwrite that page, he needs to copy that asp page to the custom folder, like
custom\customer\createCustomer.asp <-- modified asp page
The application will automatically load the one in the custom folder rather the one in the core folder.
Is this doable in C#?
This MSDN article explains how to use an IHttpModule implementation to intercept HTTP requests and perform custom actions (they point out logging, but since you're intercepting the request you might as well fetch some different content, such as your 'customized' code).
You can use a VirtualPathProvider to load a different file than the "actual requested one". This works well with IIS and caching for instance as well.
Basically you inherit the VirtualPathProvider and override the FileExists, GetFile, and DirectoryExists, GetDirectory methods (there's an example in the linked page). Then, in your AppInitialize, register the provider with
HostingEnvironment.RegisterVirtualPathProvider(sampleProvider);
By the way, don't forget to have a different (non-editable) page so the user can revert any changes that was made, in order to restore a potential misedit so to speak. I would probably have a simple version control system and use commit whenever the user made changes, and allow the user to revert to a previous changeset.
As part of the development for a website powered by Sitecore 6.3.1, I will need to implement a way to manage data from a couple of external sources in Sitecore.
To accomplish this, the simplest solution appears to be to import the external data into Sitecore as content items with a special workflow that will export them back to the external data source when they reach the final state.
I came across this article which details the code required to import data into Sitecore, but I am uncertain as to the best way to make this functionality accessible.
Considering that this process will probably (but not certainly) only be done once after the site is completed, what approach (page/Sitecore item/shell application/?) could I take to provide a way for a developer user to perform the import?
Interestingly, the Sitecore classes are available even in web forms outside of Sitecore. I created a separate .aspx file and used Sitecore.Data.Database.GetDatabase("master") to interact with Sitecore's database.
I recently inherited a solution with about 10 projects in it. 6 of these projects are individual websites that are basically copy/pastes of the original.
This means that any changes that need to be made must be made to each project in order to update all the websites.
What I want to do is have one project for the website code and be able to deploy that code and some configuration settings to create a new website. That way when I make updates to the main Web project I can just deploy to all the websites.
How do people normally approach this? I'll outline my thoughts on it and hopefully some of you can point out better ways to accomplish this or at least give me some affirmation that I am on the right track.
Have a master markup with very general containers.
Allow the users/people setting up the site add widgets to the site which will be assigned to widget placeholders at the top and bottom of all the generic containers.
All styling and colors will be controlled with a stylesheet that can be swapped out.
I know there is some kind of theming you can do. Does this just swap out groups of css and let you configure which one to use in the webconfig?
For elements that will be the same across all sites such as footer images have a naming convention. So if I want Site A to have some footer image I just replace the footer.jpg in the project when I deploy.
Your approach is good.
You should use master markup
Your web system will be CMS
You can use themes to define styles of different projects or you can link css files dynamically
if they are really copies of each other than you can make it very general by defining all of them as one website and put all the settings of css images markups in database
If you don't want to make everything very generic you can make web user controls and load them dynamically at run time according to the project (Remember, you can load WebUserControls at runtime using the LoadControl method)
That's unfortunately a question that is likely to get the response 'It depends' as each of those approaches could be used or not used dependent on the needs of the project. If the projects only vary by presentation then master pages combined with CSS would make a reasonable solution.