I have a unique requirement which I need to meet to with sitecore, and I was wondering if it is feasible. The client has an existing .net solution, which is a web project (web site, not web application) that is built on the spring framework and commerce server. They now want to use sitecore to enable content editing on 'some' of their pages. THe requirement is that they do not want to maintain the master pages and any common items in sitecore, but they want sitecore to be able to use the master pages and all the controls they have in their custom solution. I've checked through their project, and they have a LOT of dependencies on many other references and projects, and so it is not a fairly simple application. They do not want to have the master pages specifically in sitecore, and they only want sitecore for the main content editing. They basically want all the layouts in sitecore to use their master pages. I've tried using virtual directories and then using the master pages in sitecore, but there are way too many dependencies in their project. I've tried to make sitecore an application within its own directory, but it doesn't seem to work very well. I can merge the web.configs as much as I can, but that is going to cause headaches down the road when its time to upgrade...My more high level question is, is this doable at all, and if there is a way I can meet this requirement.
Initial thoughts are that using master pages within Sitecore is bit of a non-starter. It seems odd to have such requirements and have Sitecore already prescribed.
Three ideas come to mind.
1) Consider keeping the solutions separate, and host certain Sitecore pages in a clean, standard, Sitecore solution. Use a load balancer to direct which urls point where. There could be many side effects to this approach to do with sessions etc.
2) Migrate the existing solution to Sitecore replacing master pages with Sitecore layouts and sublayouts. At the same time, migrate to a web application project. This is very likely the best long term approach. The main challenge would be mapping existing content to a set of templates in Sitecore, and various bits of refactoring.
3) Use Sitecore as a content repository, but serve content from your existing web site solution. This will have numerous complicating factors due to lack of a typical Sitecore item, site & domain context which would all need to be handled by custom code. The solutions could be entirely separate, and even use web services to retrieve content from Sitecore which is served by the existing solution. It gives full separation, but you loose a large chunk of Sitecore functionality and end up with an expensive rich text editor + database.
I'd opt for #2 where possible.
I think I can see a few options on how to do this. I'm currently doing something similar right now on a large enterprise project where there's an existing ASP.NET MVC application running the bulk of the site. Here are some options I can think of:
Use a sub-domain for the Sitecore-only stuff and <iframe> in the Sitecore content or do an HTTP GET to the Sitecore pages and pull the content into the existing app. E.g. sc.mysite.com is the Sitecore app. I'm currently doing this with MVC now and its fine. From a content management POV, editors can still use Page Edit mode on the Sitecore pages in their stand-alone state but the content is in production in the fed in state on the main MVC site.
Sitecore can use MasterPages, it just defeats the purpose of the presentation layer of Sitecore. Essentially, you can have your Sitecore layout inherit from the MasterPage and it works just like any normal application would with inheritance. I'm not sure of the caching implications though. As long as your app references the Sitecore assemblies, you can use the API as long as its part of the Sitecore context. If you DO use MasterPages with Sitecore, make sure you add a placeholder with the key webedit to allow page editor to work: <sc:placeholder key="webedit" runat="server" />
Related
We have a corporate website with a large amount of dynamic business application pages (e.g. Shopping Cart, Helpdesk, Product/Service management, Reporting, etc.) The site was built as an ASP.Net Web Application Project (WAP). Our systems have evolved over the years to use .NET 4.5 and various custom business logic DLLs (written in a mix of C# and VB.NET). However, the site itself is still using VB.NET Web Forms. We now have done a few side projects in MVC 4 using Razor/C#, and we want to use this framework for new pages on the main corporate site going forward. What would be the easiest way to achieve this?
I found this nice list of steps to integrate MVC 4 into an existing Web Forms app. The problem is that because our existing app is a VB.NET WAP, it compiles into a single DLL, and .NET allows only one language per DLL. The site is way too big for us to contemplate converting it to C# all at once (yes, I've looked at the conversion tools, and they're good, but even 99% accuracy would leave us a huge amount of cleanup work.)
I thought about converting the existing WAP into a Web Site Project (WSP) which does allow mixing languages and then following the steps above, but after a few pages of Google results, I couldn't find any steps for converting a WAP to WSP. (Plenty of sites offer the reverse steps: converting a WSP to a WAP.)
Another idea I had was to create a completely separate MVC project, and then somehow squish them together into the same folder structure, where they would share the bin folder but compile to separate DLL's. I have no idea if this is possible, because certain files would collide (e.g. Global.asax, web.config, etc.)
Finally, I can imagine a compromise solution where we keep all the MVC stuff in its own separate application under a subfolder of the main solution. We already use our own custom session state solution, so it wouldn't be difficult to pass data between the old site to the new pages.
Which of the ideas above do you think makes the most sense for us? Is there another solution that I'm missing?
After some more research and experimentation (and thanks to a suggestion from T.S.) I have narrowed it down to either the 2nd or 4th option from my initial question:
Convert our WAP to a WSP, and then follow the steps to integrate MVC into the site. I don't see moving from a WAP to a WSP as a complete step backward. As the MSDN link explains, performance does not suffer, and it's mainly a question of how to adjust our build/deployment process. The major advantage with this technique is that it allows multiple languages to coexist in the same project and root folder. Certain files, such as Global.aspx.vb, would have to remain in VB.NET. But specific folders and web pages could be designated as C#. The disadvantage for us is that our site has a lot of legacy pages that use old-style server-side-includes of ASPX page fragmets, and these cause build errors in a WSP. These would have to be changed into User Controls, or perhaps renamed to an unrecognized extension, such as .aspxinclude, so that they are not included in builds.
Create an MVC child application as a new .NET project (see http://support.microsoft.com/kb/307467). The parent web.config needs its <system.web> section wrapped with <location path="." inheritInChildApplications="false">, and the new app's subfolder needs to be converted to an Application via IIS Manager. The child app can be a WAP using a different default language (C# vs VB.NET). This makes it is easier to isolate from our existing project. But this is also a disadvantage because the MVC routing only works on URL's in the subfolder of the child application. So if we wanted multiple parts of our site to use MVC routing, it would require separate child projects, e.g. (/cart, /myaccount, etc.)
We are probably going to go down the path of option #1, converting to a WSP, and only resort to #2 if we encounter a big obstacle.
UPDATE: I was able to do the conversion using technique #1. It's been working for several months now, so I published a blog post with the procedure I followed.
Came up with a very simple solution.
Create new MVC C# project
Add the old vb project to the solution.
Move the VB aspx pages to the new C# project
REMOVE THE CODE BEHIND ATTRIBUTE FROM THE FIRST LINE OF THE VB PAGES eg...Codebehind="ProductDetails.aspx.vb" (this is the magic)
Add a reference to the VB project in the C# project
This will work for master pages as well
Strangely the VB aspx pages 'just find' the codebehind from the reference and the C# project does not seem to care about the aspx pages being VB.
Go figure!
Hope I saved someone some time. I spent many hours on this.
You have 3 options here:
Convert the ASP.NET Web forms from VB to C#
Convert your MVC 4 written in C# to VB.
Develop all old apps in ASP.NET Web forms again to MVC 4 (ugly but better for future changes)
My advise is keep them diferent projects only share your business logic. And in the same solution file.
I'm trying to switch my custom cms written in php into .net c#. I was thinking to use cms as a learning project. I'm going to use C#, NHibernate ORM layer, mssql, mvc3 and jquery.
I'm aware there are plenty of commercials or open source cms, but still I'm going to spend some of my free time trying to learn new technology working on project like this.
So, is there anyone out there who is willing to share some ideas on creating cms domain model, usefull link, ideas, etc.
Thanks
A really basic CMS consist of 3 elements:
one database table to hold your "pages". The table structure is "name" and "content"
a route to transform requests of type /cms/pagename to a fixed controller, the method called cms and pagename as a parameter
a embeddable html editor
Now, there are two ways your "page" can be invoked. It is either create mode or view/edit mode.
In "create" mode, the page is requested but it is not in the database yet (e.g. cms/announcement1). In this mode you create a view consisting of a html editor and upon submit, you persist the page to the database.
In "view" mode, the page is requested and is IS in the database. You perform any necessary rewriting (for example you rewrite internal links of the form [cms/pagename] to a fully routable http address) and render the content.
If the user is authorized to edit the page, you also show a "edit" button which then invokes the html editor with the page loaded and ready to be edited.
And that's it.
There are tons of additional elements (caching, different built-in page types, embedding images, youtubes, preformatted texts) etc. but all of them are optional and you can introduce new features when you have the core already implemented.
Once I wrote a simple CMS following the structure above, it was a part of a bigger solution and till now it's been sucesfully deployed several hundred times. An advantage of a custom CMS is that it can be really simple and easily maintanable.
Ok, I want to build a web site using ASP.Net. My web development skills are very small. However I have used C# a fair bit for some fairly intermediate level work (lists, dictionaries, custom classes etc)
The site I want to build will run on an intranet, and I'll be using the AD to get the current users information.
This information will be cross checked with an MS SQL 2008 database (that already exists on the network) to determine what links they can see.
Other parts of the site will allow the User Table to be viewed and modified if the current user is an admin, and have new users added.
So, what is the best way to do this? I've done some playing and basically confused myself with all the options available..
For example, I can create a New Project, which gives me options like Web Application, MVC2 Web App, MVC3 Web App, Empty Web App, Dynamic Data Entities Web App, Data Linq to SQL Web App, and then some Server controls.
But then I can also go for the New Web Site, which has Web Site, Web Site (Razor), Empty Web Site, Dynamic Data Entities Web Site, Dynamic Data Linq Web Site..
There are too many options!?!?!? And I don't understand what the difference is between them all..
What do people suggest I use?
Have you tried following some of the MSDN Beginner Developer Learning Center stuff? They have a module on Beginning Website Development.
May be I am not answering to the point, but my 2cents. Why don't you go for Sharepoint development in this case. You can use Sharepoint site (having inbuilt AD support too) and develop custom webparts (like the part which queries SQL Server 2008). The advantage of using this is that you can merge the feature in intranet site (if you got one already using Sharepoint), and you can learn new stuffs too. Even it will be quick one and if in future, you want to use the Intranet site for different things, it's easily extensible with minimal fuss.
There are some good tutorials for MVC here http://www.asp.net/mvc.
I suggest if you are building a web site to use MVC as it seems like the latest and greatest from MS at this time. My personal opinion tho.
You would want to just start with New Project.
Ok, this is a lot of things to look at and there a are a few ways to tackle this. First all all just stick to New Web Site for now.
First things is to know if this is an intranet or internet?
it seems like it since you want to use AD, that it is an internal app.
Although there are many ways to accomplish what you are trying to do. I Think the following would be the easiest to implement.
1) Enable digest authentication
2) Set a IE group policy to the User authentication policy to Automatically logon only to intranet - This way people dont get confused to what they enter.
3) Create groups for each type of user in AD
4) Separate each functionality into different folders.
5) Set the web.config for permissons to the appororiate directories.
#Matt provided a link to a useful video ("Choosing the right programming model"). In it, Microsoft's Scott Hanselman describes the distinguishing characteristics of the three primary ASP paths: ASP.NET Web Forms, ASP.NET MVC, or ASP.NET Web Pages. Here's the main bullet points from that presentation:
ASP.NET Web Forms:
Familiar control- and event-based programming model
Controls encapsulate HTML, JS and CSS
Rich UI controls included - datagrids, charts, AJAX (common tasks available out-of-the-box)
Browser differences handled for you
SharePoint builds on Web Forms (so, useful if you want to be a SharePoint dev)
ASP.NET MVC:
Feels comfortable for many traditional web developers
Total control of HTML markup (controls not provided; good grasp of HTML required)
Supports Unit testing, TDD and Agile methodologies
Encourages more prescriptive applications
Extremely flexible and extensible
ASP.NET Web Pages:
Easy to pick up and learn (similar to PHP or classic ASP)
Inline scripting model with Razor and C# or VB.NET
Simplified model with Top-to-bottom execution
Full control over your HTML
Friendly Helper syntax (encapsulated functionality, similar to Web Forms controls) makes extending your apps easy
All these models are built on common ASP libraries, so there is considerable overlap, and a fairly straightforward path to migrate an app from one model to another.
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.