One of our clients has a rather large website, currently build in Kentico 11 / Protal Engine. We are now preparing the transition to Kentico 12 / MVC.
We woul'd like to do this gradually, per section. We have a couple of concerns regarding this:
Is it possible to run parts of a website Kentico 12 MVC and other parts Kentico 12 Portal Engine?
Is it possible to handle specifice cultures first? So is it possible to have 2 versions (MVC / Portal Engine) of the same page?
Are there any best practices concerning a gradual transition to K12 MVC? Since this is a rather large site, we have to do this transition gradually.
I would highly highly recommend against mixing a Portal Engine site and MVC site in Kentico (Web Forms and MVC in the same project). While yes, this is techncially possible (see this link on websites that use MVC partially in the portal engine on an older version of Kentico) it is no where near a best practice. There is a performance consideration (overhead of processing requests in both the web forms lifecycle and mvc pipeline), long term maintainablity consideration (hard to rememeber what goes / went where), and overall technical debt to deal with.
I would recommend jumping to MVC for the whole thing when it is time for a redesign as a best choice, or when your version of Kentico won't be supported by Kentico on Portal any longer (see the Kentico MVC transition guide)
If you absolutely need to do this in chunks, consider creating a second site in your Kentico instance at a different subdomain and learning MVC for Kentico there while still connected to he same instance. You could start treating the content as a content model accessible through the Kentico libraries nuget packages in a clean MVC architecture. This site could live at subdomain.website.com while your existing portal engine site could be at www.website.com. Again, this would not be my first choice, but it could possibly make sense in your scenario.
There is no easy way of combining the Portal Engine and MVC together. In your scenario, it will be even harder as Portal site is on Kentico 11 and MVC site you are going to build on Kentico 12 I presume. Hence, the only strategy I see is:
develop, release and migrate content for a new site section by section
host both solutions separately (separate db, separate web servers)
set up a reverse proxy that will be routing requests to old or new site based on URL, so that for the site visitor it will still look like a single site
The only challenge in this approach is if you have some functionality that spends across the entire site. For example, it can be my account that is used for e-commerce, favourites, newsletters, etc. In this case I'd suggest considering moving this first alongside with the relevant sections.
Related
I am using Kentico portal to make an E-commerce site.If I wish to change the design of available sample E-commerce site.Would it be a tidious task ?
Example : If I download e-commerce design templates (i.e html and css files) and I wish to change design of each page of sample kentico site (home page,product detail page etc.)then, what is the most suitable and quick way to achieve this ?
How should I update the html/css of each page of available site with downloaded templates? OR Should I create entirely a new e-commerce site in the portal ?
The out of the box sites are meant to be used as examples and references not to build a production site off of. The markup used on the Ecommerce site will also be different, considerably different than your purchased template. I've found it much easier and faster to start from scratch with a blank site and implement all of the design that way. Make sure you take advantage of shared layouts and templates, this will help make development and re-skins in the future easier.
Is there an easy way to use an MVC controller in Kentico; and, return a specific page that has been developed in Kentico, as opposed to referencing something like ~/Views/ControllerName/SomeView.cshtml?
I'm trying to use the MVC controller to provide some needed routing functionality, and already had a working page prior to using the controller. I would like the display to be pulled from the working page I had before using the controller.
I'm using Kentico 7.
Especially in Kentico 7, MVC support was more or less "you can use it, but it won't be usable with portal functionality."
You can have MVC pages, and have Portal pages, but there really isn't a way to pull in a portal style page into it. You're best bet is to try to either use some custom logic to render the elements you need and pull in that content dynamically into the page.
I could be wrong, my MVC isn't as strong as my kentico.
Trevor is right - there is an ASP.NET MVC support in Kentico v7 you can use but there is nothing like MVC Portal Engine or something like that. There are two possible ways how to achieve your scenario:
You can use Kentico as a 'model' and read (manipulate) data via API in your controller and view (typically in Razor). Then you need to:
a) register route to your controller in CMS Desk > Node > Properties > URls and choose proper Path type (route or MVC) - this is prefered way
b) create MVC page template in Site manager > Page templates
You can find example on Corporate Site (part of default installation) in CMS Desk > Corporate Site > Examples > Development Models > MVC
You can learn more in Kentico CMS 7 documentation (MVC development overview section).
Please note there is whole new MVC approach in latest version (Kentico 9).
Portal engine is based on web forms and components such as web parts, page templates or widgets are not supported by MVC itself so you wont be able to display your page using MVC.
Kentico 10 will contain many new features regarding MVC, but mixing portal engine with it will not be the case.
I have a large ASP.NET 4.5.1 Web Application that I have just successfully added MVC 5 to (using this guide )
I am now presented with the challenge of making all MVC content look just like my Web Forms content. I use .Master files in all of my Web Forms as Microsoft intended, but I am not seeing a clear solution for how to share these .Master files with my MVC views (since Layouts appear to have replaced .Master files).
The almighty Hanselman posted a few options for MVC 3 over four years ago, but I can't believe that Microsoft hasn't come up with a cleaner way to share .Master pages between Forms and Views.
My GoogleFoo has failed me and I'm hoping someone has a slicker new way of making my frankenstein web application look consistent across both Forms and Views.
I am building a publicly facing website that does the following.
Users log in.
And then view a list of their customers.
They click on a customer to view their past purchases, order them, change them etc.
This is not a shopping site by the way.
It is a simple look up tool.
Note that none of the data accessed by the website is in anything other than a SQL database - no office documents. Also, the login does not use users Windows credentials on a VPN or something like that.
Typically I would build this using a standard ASP.NET MVC website.
However the client says they want to use Sharepoint.
As I understand it, Sharepoint is used for workflow and websites that are collaboration tools such as the components you can see here http://www.sharepointhosting.com/sharepoint-features.html
Here are my questions:
Would I be right in saying that WSS is completely inappropriate for this task as it comes with an overhead that provides no benefits?
If I had to use it, would I need WSS or MOSS?
If I had to use it, would I be right in saying the site would consist of :
List item
a) Web Parts
b) And a custom site layout. How do I create one of these?
Addendum:The book Professional SharePoint 2007 Web Content Management Development looks like a good start
1.) I agree that SharePoint would be quite inappropriate for this task. A few reasons:
It costs thousands of dollars to license SharePoint for use on the open Internet
SharePoint will use a lot of resources (SQL Server, IIS, Active Directory...) that are unnecessarily demanding for your task
SP will give you very little flexibility to develop a solution in your way -- it sounds like you would need to create a database-connected Web Part in ASP.NET anyway (so that could be entirely independent of SP)
SharePoint has it's place--it can be remarkably helpful as a company's internal document management, intranet, and workflow/approval system--but it is not well suited for custom code nor Internet use.
2.) I believe MOSS would be required for the Internet license (as in the link above).
3.) SP development is not like typical relation database systems (for example, it uses flat, unnormalized tables). If your SQL matched the SharePoint way of thinking, you might be able to connect to your database as an external List using SharePoint Designer. More likely you would need to use Visual Studio to create a custom Web Part in ASP.NET.
Hopefully this'll be a few reasonable arguments you can use to help the customer see how SharePoint is inappropriate for the task... In fact, I expect just the first point (the cost of licensing) will turn them.
You can technically use WSS for this task but MOSS has more features aimed at building public facing websites. The publishing infrastructure comes to mind. It has has the CQWP which enables you to build custom interfaces which perform well in SharePoint. With SharePoint there are potentially challenges around scalability. If you know the platform well then doing something like what you have suggested would be a pretty quick task. If you don't know SharePoint and the underlying system well you could face challenges.
You do not want to approach building the final application with SharePoint Designer. It has behavior which can cause major problems with scalability. You want to create a SharePoint Solution comprising a number of features which can be easily deployed to SharePoint. Going this route does not alleviate performance problems but you are going to be closer to the right solution. You can package up the custom user interface elements as CQWPs or write Web Parts. I personally prefer to write Web Parts.
You do the overall site design in a Master Page. Pages within a site are then inheriting from this. If you have MOSS then you can create what are called publishing pages which contain your Web Parts. These are not available in WSS which is why people recommend against it for public websites.
To decide whether SharePoint (any version) is worth it, you need to find out if they are going to use any of the core features. If everything is going to be custom and you are not going to make use of any workflow or document management features in your deployment then I would stay away. To see whether you want to go further with SharePoint from a development perspective, take a look at the WSS developer labs. I recently ran an intro course at my employer using the materials from that site. They are dated, and need more info on best practices but they provide a quick way for you to dip a toe in the water and decide whether you want to go any further.
1) For the core functionality as you describe it SharePoint isn't going to add anything, BUT if you build it on SharePoints premisses it allows your client to add a lot of functionality outside the core for "free" like:
They can add Content Editor WebParts to pages where they can add descriptions, and messages
They can add lists where the customers can enter requests/comments/... and automatically have new entries mailed to anyone in the organisation subscribing to changes
The functionality you develop can be reused on their intranet
Any future small "web apps" can be included in the same site
...
So all in all unless you have a better framework to use then use SharePoint
2) WSS is all you need for now
3) Your main deliverable for now would be:
a feature with some Site Pages and a few Web Parts
a feature with a custom masterpage and corresponding css
True. Well not inappropriate but it doesn't add anything either.. but maybe in the future?
WSS is enough
You'd need web parts to expose your data, yes. The custom site layout is not necessary. If you want your own look and feel a SharePoint Theme may suffice. Even if you want some real custom layout tweaks you probably don't need a site template but you can get away with using just SharePoint Designer to edit the pages or master page.
We've been asked to create a web application. One part of the specification is that in future, it can be integrated into Sharepoint. The last version of this app was written in PHP and "integrated" by means of an iframe embedded into Sharepoint; not ideal.
I'm looking to understand the use of Sharepoint in this context. I believe that you can write Sharepoint Applications which are more "native" to Sharepoint than the rough-and-ready iframe approach I discussed before. How easy is it to take a standard ASP.NET MVC application and fully integrate it into Sharepoint?
Does anyone have any thoughts, experiences, or resources on this matter?
I think the first question is what kind of integration with SharePoint are you trying to accomplish? The simplest is to use the Page Viewer webpart (i.e. iframe) method. You can also write custom webparts that show data from your custom application. That's a form of integration. The ultimate form of integration, of course, is to make your application run inside of SharePoint. That leads to my next point.
SharePoint (as of version 2007) is essentially a giant ASP.NET framework. So you can theoretically use it to host any ASP.NET web application. I have actually done it before and it works. However, that was a plain old ASP.NET webforms application (not MVC). If this is what you are trying to do, you definitely would need to rewrite your php application in ASP.NET.
In Sharepoint there is a Page Viewer webpart using which you can load a different url. This way you can easily "integrate" your application to sharepoint site ;-)
But if you are really looking at Re Engineering the application in SharePoint then its a different story. You have to study the current application and then develop it in SharePoint.
This fellow has an approach to writing PHP for SharePoint. A key statement:
There are two big tricks – getting the
XML right and using NTLM
authentication.