We develop very business-case specific applications, but all applications have something in common: some pages or some parts of pages need to be freely content-managed. We often rebuild the same functionality in each application: display and editing of CMS pages.
There must be a better way! Is there any .NET CMS that can be plugged in the way we can in the main application iterate on the available pages and display them using a simple API which outputs HTML, and management of those pages is done in the backoffice / administrative pages of the CMS application.
I would imagine, for example Umbraco, which offers an extensive backoffice. You would in the backoffice be able to add, remove and edit pages. The developer would in code simply use an API like:
UmbracoCms.Core.PageManager.GetPage('CONTENTBLOCK-HOME')
This would for example retrieve the HTML content for a content block on the home page.
Does anything like this exist in the .NET ecosystem, or are there alternative solutions? The basic question is here: How would you add CMS functionality (by preference, already from a well-known CMS like Orchard or Umbraco) into an existing web application without rebuilding and reinventing a wheel each time over and which solutions already exist? What solution would allow plugging in the CMS into the existing application instead of trying to get an existing application to work in a new CMS application?
If you have properly separated application, there would be no problem to integrate it with Orchard as module.
Modules in Orchard are like MVC area so it is like subapplication.
Separate business logic, domain entities and data access to separate libraries which will know nothing about Orchard. Create Orchard module just as presentation layer and as point for registering all your dependencies in Autofac IoC which is used by Orchard.
If your application is improperly designed ... ex .. all business logic is in controller, then you are in trouble.
Related
OrchardCMS, Umbraco and DotNetNuke are CMSes in .Net galaxy. They work as stand alone applications well. Suppose I have a requirement that need CMS features in an another ASP.NET MVC application. I do not like to implement CMS again in the application. Rather I like to use current CMSes as a component of application.
Is it possible at all to use for example OrhcardCMS as a component of my MVC application? It is ideal to have relations between CMS and application itself, for example I can load entities from CMS, update them etc.
I know there are integration techniques in .Net. For example ASP.NET Identity integrates with ASP.NET applications in core level, but view (CSHTMLs) must be copied and customized in most cases. Or Hangfire and ELMAH that integrates with an application without need to copy view (cshtml, html, css) to the target application. Indeed it is good to know that integration methods are available regarding plugging CMSes into ASP.NET applications.
I can tell you more about Umbraco as I don't know other CMS as much as this one. There is a whole course / training for those who want to integrate their apps with Umbraco: https://umbraco.com/products-and-support/training/umbraco-application-integration/. So yes, it's possible and it's even suggested way from my perspective to use already done piece of software rather than building the wheel once again.
Umbraco is an ASP.NET MVC application. You can use Umbraco components, backoffice, membership and everything else CMSish delivered out of box and still you're able to write and use your business logic, controllers and everything else what you've created inside your ASP.NET MVC / C# app. Still, it's an ASP.NET app, so you can use anything what you want from the .NET world. We're using ELMAH.io for example to take care of logging and keeping the errors in the cloud. We're also using a ton of 3rd party, both open-source and commercial tools and softwares to do multiple things around our web components. Umbraco is not blocking us from using them or anything else. I like to consider Umbraco as a framework or library helping us to deal with content editing and giving us a massive number of opportunities to offer for our clients or editors.
Speaking for OrchardCMS, there are some questions touching this subject already, see
Reusing Orchard's Core to build another extensibility framework
Extracting a Module from Orchard
If it's possible for you then try to setup Orchard as the base system and move your MVC application in a module. This will be much easier than trying to cut out peaces of Orchard. In return you get amazing possibilites when running Orchard as the underlying framework, e.g. Localization, Modules, Themes, the whole user / role management etc.
OrchardCMS 2 is currently developed towards single components that can be reused in any application but it's far from finished yet.
i have existing asp.net web application it includes membership and roles and admin section,etc. Now i would like to integrate dotnetnuke journal module in my asp.net web application.
is it posible to integrate dotnetnuke module in my web app? i download dotnetnuke source and i compiled journal module.
can any one update me how to integrate dotnetnuke module in my web app..i don't want to switch to dotnetnuke for now.
Your best bet would be to utilize the APIs to access the journal from your custom application.
The module itself is dependent upon DNN and its context (users, pages, modules, etc) in order to function properly.
I am sure you could rip a lot of that out, but I am not exactly sure what you are trying to do.
is it posible to integrate dotnetnuke module in my web app?
No.
Your only way to succeed in your quest would be to convert your ASP.NET application into the DotNetNuke application. To do that, you're going to have to merge the authentication side of the two sites. This shouldn't be impossible since DNN uses the ASP.NET authentication provider.
If you can merge the user database into a DotNetNuke installation properly, you're halfway there. You could then use the DotNetNuke page management features to load your custom pages by linking to them directly, and gradually merge your existing application.
Otherwise, you have no hope of integrating the Journal module. And you're up for hundreds if not thousands of hours of coding to try and replicate it.
We currently have a product that uses Sharepoint and a number different Web Part libraries to display realtime data to customers. The way this has been set up is that each customer has a custom login (Active Directory), a custom site with their specific data hooked up in the web parts. That means for every customer we have a completely separate site. Eg:
Customer 1 -> www.site.com/sites/customer1
Customer 2 -> www.site.com/sites/customer2
Customer X -> www.site.com/sites/customerX
As you can imagine, this is impossible to maintain as any small change that we make has to be manually propagated across all of the site, a task that has become impossible.
We are also developing separate ASP.NET MVC application that live on the same server under their own Virtual Directories Eg. www.site.com/App1/
I've been tasked with investigating how to best redesign the system to provide a more integrated and "application platform" type architecture.
Personally I would love to just ditch the Sharepoint as I think we are using it incorrectly (not as a CMS at all), but my manager wants to keep the Excel Services for customers who pay extra (a customising service).
We currently embed the MVC applications in Sharepoint using the Page Viewer Web Part, but this gives us less control over the layout of these applications
My next thought was to have a standard ASP.NET masterpage across all MVC sites and sharepoint so that they look the same, whilst still providing the functionality required, but investigation and testing seemed to be that Sharepoint master pages are horrible beasts that barely resemble a clean master page.
Basically I'm stumped, and I'm getting a little disheartened about Sharepoint and it's god awfullness.
Does anyone have any experience with this or could provide some ideas/tips?
Very much appreciated.
CodePlex - SharePointMVC
A helper project for hosting asp.mvc content inside SharePoint.
I'm looking to take advantage of SharePoint's document management features for an intranet portal. Portal users, find SharePoint rather cumbersome so I would like to build most of the site in ASP.NET, and integrate SharePoint document libraries so that i don't have to create a document management system.
How can I do this?
In my honest opinion it sounds like you are trying to reinvent the wheel. If users are finding it cumbersome it is generally do to lack of understanding or incorrect implementation and training.
However if you do want to integrate into SharePoint, you can reference the full SharePoint API Library. It is .Net based and allows you to access any aspect of SharePoint in code. You need to reference the Microsoft.SharePoint assembly to access these classes. You will need to setup a development environment for this, since you can't develop for SharePoint without having it installed. The detailed documentation on the namespace starts here
From personal experience we had much more success implement a solid SharePoint structure, with training, and also building the SharePoint portal the same way we would have built a website. Users now insist on having applications in SharePoint.
Basically, you can set up and administer your document library (or libraries) through the standard SharePoint pages, but you build your own ASP.NET site for users which will access the information in the document library. This site will use either the SharePoint object model or the SharePoint web services to retrieve, manipulate and store documents in your document libraries.
Generally the rule is that if you are deploying your ASP.NET site onto the same server as your SharePoint instance, then use the Object Model; if you are deploying to a separate web server, use the Web Services.
Some of the common issues for SharePoint development, and how to avoid them can be found here:
http://msdn.microsoft.com/en-us/library/bb687949.aspx
The “Working with Folders and Lists” section will be particularly relevant to what you are doing.
Use an IFrame :)
Seriously.. you'll have to work within the context of SharePoint or you will find yourself rebuilding SharePoint. This excludes building it as a regular ASP.NET app. But it is not that far off.
Why not adapt the way SharePoint works to how your users like to work? It was made to be changed and appended.. within limits.
Are both completely different concepts? Or is there an overlap in their meaning?
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
If yes, then should the Web Framework use the same technology as the CMS? For example could Ruby on Rails be used in combination with Drupal? Or doesn't that make any sense at all?
Are both completely different concepts? Or is their an overlap in their meaning?
A web (application) framework is a lower level, generic toolkit for the development of web applications. That could be any type of system managing and processing data while exposing it's data and services to human users(via web browsers and other interactive clients) as well as machines via the http protocol.
A CMS is one type of such applications: a system to manage content shown in websites. Usually/historically, this mainly means managing (pieces of) text of "pages" shown in a web site, and useres that have different levels of access to manage this content. That's where the C and the M come from.
With a CMS, you can manage web content. With a Web framework, you build web applications.
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
No. It would be correct to say that a web framework can be used to create a CMS.
Both contain parts that work on the backend as well as on the front end.
Often, a CMS is based on a web framework - sometimes CMS developers build there own web framework, and sometimes they even expose the API of this framework, so a developer can create extensions to the CMS in a way as if he would develop an application with a web framework. Drupal really does this, so you can create real web applications based on the integrated framework - with the upside that they will also be easily to integrate into the CMS.
But that(exposing the API of a web framework) is no necessary criteria for being called a CMS.
If yes, then should the Web Framework use the same technology as the CMS? For example could Ruby on Rails be used in combination with Drupal? Or doesn't that make any sense at all?
It's be possible to combine two existing systems build with these two, (e.g. because you want to show some data in a web site managed by drupal, that already exists in a Rails-based system).
But as Drupal also provides you some of the genric functionality of it's underlying web framework, it might not be necessary. You would have to manage and learn two very different systems and handle all the problems with there interoperation. So, I'd try to build a Website with only one of these if possible and only combine them if theres a good reason to.
They're different concepts. A CMS can be built on top of a web-app framework, but a web-app framework has no direct relationship to a CMS. Its at a lower level, providing a platform for any type of web-app to be built on top of it, of which a CMS is an example.
Drupal runs on php and Ruby on rails runs on, well, Ruby, so they wouldn't play together.
Just to muddy the waters a bit, Drupal describes itself as a content managment framework which is essentially a content management system with hooks to extend it. Which does create an overlap. The drupal overview describes this better than I could.
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
It's not "correct" but it's not wrong, either. A web framework is a general concept -- many things count. A CMS is a specific concept, often built within a web framework. Sometimes CMS's are stand-alone web applications. More often, however a CMS is a back-end things that require a customized presentation front-end.
Should the Web Framework use the same technology as the CMS?
Shouldn't matter. At the end of the API definition, the Framework and CMS can have any implementation at all.
Web App Frameworks -- generally -- must either serve HTTP requests or plug into something like Apache.
A CMS is a glorified database, and any sensible API is good. Most often, however, they're also using HTTP as their interface protocol.
Could Ruby on Rails be used in combination with Drupal?
Sure. Purists will object, but there's no technical reason why they can't cooperate.