We are about to rebuild a our public web site. We don't change platforms often. We pick one and stick with it for about five years. When the platform is showing its age we begin to research currently available options.
At this time, we have decided to abandon DotNetNuke. Orchard CMS is high on our list of options. There is no need to discuss our reasons or other options. This is not an opinion survey. But I do have a question.
.NET Core would be our preferred platform. I see that the Orchard CMS team is working on a .NET Core version. It seems premature for us to use it right now because it is not yet stable. On the other hand, activity in Orchard CMS on ASP.NET seems to be waning. We are concerned that if we go that route, we would investing in a platform near the end of its life cycle.
Does anyone know if there will be a viable migration path from Orchard ASP.NET MVC to .NET Core MVC?
Although nothing is set in stone yet, I expect that realistically, you will be better off re-implementing the site in Orchard Core CMS. The two systems are very different in terms of data schema in order to automatically migrate, and any custom modules and themes you create in Orchard CMS will have to be recreated in Orchard Core CMS. Even if that work consists primarily of copy paste and accommodate here and there, there are certain things that are so different that it’s incompatible with the new CMS. One such example is the Layouts module in O1, which is replaced with something entirely different in OC. Additionally, there are different and better solutions to certain problems in OC when compared to how you would do it in O1.
My personal opinion is that you’d be better off building your site directly in OC and skip O1, despite the fact that O1 is more mature, for a couple of reasons:
OC is vastly more performant and scalable than O1.
OC is built on top of .NET Core, which means you have the option of running it on a Linux image. Not to mention that .NET Core is optimized to run as a server when compared to the full .NET Framework.
As you correctly noticed, activity on O1 is dwindling, whereas activity on OC is quite high.
Although there is still a lot of moving ground in OC and it’s not as mature, the above reasons would be compelling enough for me to go for it.
Orchard Core (OC) is a complete re-implementation of Orchard CMS (01) and the changes are really important.
So even if there is no easy way to migrate your content form O1 to OC, I managed to generate a recipe by exporting the blog posts I had in my older O1 site with the expected new json format.
Related
Good day, I've been using ServiceStack for many years, I currently designing and planning a rewrite of an ASP MVC (Razor) project. #Script seems to be an almost perfect fit, without hands-on experience of the technology I have some doubts and questions.
My question is how relevant is #Script today and what is the future plans of this technology. I ask these questions because when I looked at GitHub example I noticed that there is not a lot of activity, and searching the internet I am also not finding a community around it.
As #Script's author I would say that #Script is a complete library for what it's designed for as an embeddable sandboxed .NET scripting and templating language that's ideal for exploratory programming with seamless integration into .NET APIs (including Win32 APIs) that includes a vast built-in library (1000+) of filters that's easily and highly extensible to the point that it's even able to natively support multiple languages (inc. built-in LISP Repl) within the same page that's been a joy to develop with thanks to its built-in Hot Reloading support where changes are instantly visible upon save - so technology-wise IMO it's pretty great.
If we were to compare it to comparable libraries in other languages like the Ruby's Liquid it should be pretty clear that #Script is vastly more capable where it scales from a user-friendly templating language to a powerful scripting language where it's capable of developing entire Windows Desktop Apps that fits in a Gist.
On the activity front, Liquid is also an established library with low activity with only a handful of commits in 2021, the difference is that it's vastly more popular and used in popular products like Jekyll as used in GitHub Pages which ensures it will always have a rich, vibrant ecosystem which is the most important indicator for assessing a technology's longevity.
Technology not as important as ecosystem
However in the end the technology doesn't matter nearly as much as its user base, community and ecosystem behind it which is where #Script is sorely lacking. Unfortunately this is the reality of libraries that compete Microsoft's defaults like Razor which are exclusively promoted for .NET and will always retain the majority of adoption in .NET.
#Script is a "complete" library in that I've added all the features I planned for it and there's basically nothing I can think of to add to it to make it more appealing, but facing the realization of its indefinite lack of adoption I wouldn't recommend using it for large living (i.e. multi-year) Websites, given it will never have the community and adoption enjoyed by other ecosystems since the benefits of a community and ecosystem are ultimately the most important attributes in order to continue investing in a technology.
Continue to be actively supported
Like all of ServiceStack, #Script is still an actively supported library with no outstanding issues so it's safe to use in that any issues will be promptly resolved should you wish to.
Website Development Recommendations
I'd say it's still a fine option for smaller definitively-scoped projects since its compile-time-free and Hot-Reload makes for a very productive Dev UX for server-generated dynamic pages. However even then I'd first evaluate if a static generated framework like Jekyll, Hugo or other popular static generators would be more appropriate since they enjoy a vibrant community and a statically generated site results in a more performant, resilient and cheaper to host and deploy website.
Static Site Generators
Having recently redeveloped the servicestack.net website to split it out into using Jekyll for static content and ServiceStack.Razor for dynamic content, my recommendation for large websites with large static and dynamic components is to use a static site generator for its static content which yields several benefits:
Although it does require a fair bit of overhead to setup as you're effectively maintaining 2 different websites however it greatly benefits if the static content is actively updated as there's a lot less friction to change and update content on a static generated site then a dynamic one and it results in a superior end user UX thanks to CDN Edge caches that's also cheaper to host from free sites like GitHub Pages and Netlify.
In order to preserve existing URLs we needed extra functionality not possible from a static host so our static content is deployed to a S3 bucket where we use CloudFront for CDN edge caching, CF Behaviors for proxying "external static" routes to our .NET5 dynamic website and a CF Function for supporting pretty URLs. For internally deployed websites you'll be able to accomplish similar functionality with reverse proxy and redirect rules.
SPA or Razor
For small websites or mostly dynamic websites that wont benefit from a content site split I'd recommend either an SPA Project Template if you prefer TypeScript and an established SPA FX like Vue, React, Svelte or Angular or Razor or MVC if you instead prefer C# server generated websites.
Progressive Enhancement
My personal preference is for read-heavy dynamic sites to use ServiceStack Razor utilizing API First Development approach so that all writes are made to the same clean ServiceStack APIs that Mobile and Desktop Apps would also call. This typically involves using some kind of progressive enhancement like our Client TypeScript Validation example which utilizes the Form & Validation Binding in #servicestack/client to take over <form> submissions to perform TypeScript API calls and apply any validation errors back to the Form's UI.
The Client jQuery example accomplishes the same thing without the tsc -w watched build step whose form & validation binding utilizes the older jQuery ss-utils.js library but it does mean you'd need to author logic in an older broadly ECMAScript 5 supported version of JS.
Future of #Script
As I don't expect #Script Pages will ever achieve any meaningful adoption required for self-sustained active development, it's unlikely we'll continue in investing in further development for usage in dynamic websites (i.e. the script project template), it's a complete and extensible library so further development isn't strictly necessary as it can be easily extended with your own local Plugins, Methods, Transformers and Blocks. But it does mean we're unlikely to be creating and including new methods/plugins designed for dynamic websites in the library OOB.
Still a critical ServiceStack component
#Script is still a critical component of ServiceStack where it's used to provide integrated SPA templates since it's able to render dynamic websites from static *.html pages in npm dev hot-reload servers which can't use Razor's *.cshtml pages. It's also what makes ServiceStack's Declarative Validation possible where validation rules can be defined on dependency-free DTOs as it allows defining binary-decoupled logic in dep-free attributes. It's also what makes vuedesktop.com Desktop Apps like ServiceStack Studio possible as well as command tools like Post Command - HTTP API Command Line Utils and cross-platform dotnet scripts which makes usage of its internal functionality, so it's going to continue on as a actively developed & supported library.
Good future use-cases of #Script
However I'd limit any #Script usage to where it excels, e.g. as an embeddable scripting .NET sandbox given it's more versatile & flexible than Razor for tasks like Rendering Emails, authoring & rendering Live Documents (e.g. if needing to maintain live user-generated reports in an RDBMS) or as an embeddable Template, JS or LISP DSL or for evaluating adhoc JS/LISP Expressions or .NET logic.
Future replacement project templates
For developing server-generated websites with ServiceStack we're looking at shipping a couple of new templates which encompasses our latest recommendations (e.g. embracing an API First Development style), if they result in a great Dev UX we're looking at:
An Integrated Static generated (e.g. Hugo/Jekyll) + Dynamic Project template
An API First MVC Pages + ServiceStack template with integrated progressive enhancement
Please follow #ServiceStack to get notified as soon as they become available.
We have a ASP.NET Web Api project.
A colleague has removed the Microsoft.AspNET references.
We use IIS web hosting.
I would like to use swagger as api help replacement.
But Swagger or the .NET package Swashbuckle/Swagger comes in the CORE with Microsoft asp.net dependencies.
My colleague said we can not use this swagger.
I would like to know what the real problem is (colleague does not really say...) or what the advantage is of a decoupled web api project with asp.net dependecies?
I mean we host on IIS...
I would like to know what the real problem is (colleague does not
really say...)
Not code but, I think this is the first problem. Try to get your "colleague" to explain "why" it's better. (Not just cool code, but also mem/cpu footprint, team-capability-of-take-over, future path, etc.) Good code is maintainable by any qualified developer, not extremely complex and 'understood by only the one'.
what the advantage is of a decoupled web api project with asp.net
dependecies?
Decoupling is a good thing. First, "if you don't use it, don't reference it". To many projects end up having completely useless coupled libraries. Why? Because the "new project" template had them when the project was first created!
In the specific case of Asp.Net core libraries: The current Asp.Net is old, and a new version is on the way. One that will consolidate the knowledge and techniques of "Asp.Net, MVC, WebAPI, OData, OAuth, etc, etc). https://msdn.microsoft.com/en-us/magazine/dn913182.aspx
This means breaking changes are coming.
Not being coupled to the core libraries that are going to change seems like a good idea. If you want to move to this next version you'll have a lot less problems if you're not relying on 'old Asp.Net' functionality.
My colleague said we can not use this swagger.
I think the better way of saying it is; "We will not use anything that tightly couples us to Asp.Net core libraries again since we're decoupling from it".
VS2013 update 5, MVC5 using Areas
I have a stand-alone function programmed for a website. The functionality is a specific user interface to collect survey responses in a particular way. It has several controllers, a model and a group of views. The functionality is completely contained in an Area of the project, except for the Shared _Layout file that provides the main menu for consistency.
'Is it possible for me to' / 'how do I' compile this Area into a single or set of .dll file(s) that I could then add conveniently to other websites? I'm assuming creating something for transfer/download is very standard functionality. For example, I used Elmah.MVC for this site. What I want to do is pretty much create a package that can be downloaded in a similar way to how we integrate Elmah.MVC into a site. (Be certain I'm not talking about creating error logging software, I'm only using Elmah.MVC as an example of software that is easily integrated into other website applications.)
I've never compiled any website functionality into a .dll(s) for use elsewhere and would appreciate either some specific guidance, or perhaps what would be easier is to provide a link with a good step by step tutorial or explanation for how to do this. Most of what I've found on the web describes bits and pieces of doing this, but it's not enough for me to feel confident with it.
It seems to me there are a lot of 'moving parts' to taking a particular piece of an MVC application and turning it into something that is easily added to other projects.
A particular issue I don't quite grasp is the difference in downloaded packages between getting code and getting just the .dll(s). For instance, when I download an MVC5 site, I get controllers, models and views, but when I download Elmah I get a .dll and no code files. Also, I do understand the concept of transforms, but I'm just struggling right now with even getting from my programmed application into a 'package' regardless of the transforms that make it easy to integrate into another website.
These are just some of my questions I have about how to perform this particular process in developing deliverable and/or shareable software.
What you are looking to do is create a portable MVC Area project. A Portable Area is a set of reusable multi page functionality can be dropped into an application to provide rich functionality without having to custom build functionality that is literally the same in every application. An MVC Portable Area is really just a dll that contains the views, controllers, scripts, etc… needed to use in a website that is either a Web Forms website or an MVC website. A developer can use them for a reusable widget or a complete engine. I have actually used them for both. Here is a link with some basic info to get started. http://elegantcode.com/2012/04/06/mvc-portable-areas/
I'm looking for a free, simple and efficient CMS for building website for a small company.
Prerequisites are:
The website is nothing more than a presentation - with informative content and gallery. The website should contain a nice-looking gallery with js/ajax flavour. Nothing more is planned for now, but it would be nice if CMS would feature some more generic modules/extensions in case I would like to use them in future.
Design templates should be easy to adopt and change.
Coding as little as possible.
I thought about Drupal, but is there any other CMS which would better fit to these requirements?
Please don't list available CMS-es here. Give it a reason!
Wordpress is nice too :p It has a big community behind...
I say Drupal.
Drupal is really good in content management. You can create different content types, and assign them fields (in Drupal 6, you will need the CCK contrib module). You can create a gallery with Views and it's output plugins. There are dozens of them, using different layout and JavaScript effects (mostly different jQuery plugins, but there are plugins for lightbox and thickbox also).
Drupal has a group of themes called "starter themes". These themes are half-ready, and it is very easy to create your own custom themes with them. All you need is to create a subtheme. (Basically making an info file and copy some other files. There are really a lot of howtos out there.) There are also starter themes for 960 (CSS framework), so you can make the site layout really fast. The most famous starter theme is called Zen. You might want to use that.
Except for the theme, I don't think that you have to write any code. Writing a theme for Drupal is not hard, since it uses PHP to render the themes.
Still in beta (0.5) phase but looking very promising: Orchard, a new ASP.NET MVC based CMS created by the people from Microsoft.
Orchard will create shared components for building ASP.NET applications and extensions, and specific applications that leverage these components to meet the needs of end-users, scripters, and developers. Additionally, we seek to create partnerships with existing application authors to help them achieve their goals. Orchard is delivered as part of the ASP.NET Open Source Gallery under the CodePlex Foundation. It is licensed under a New BSD license, which is approved by the OSI.
The intended output of the Orchard project is three-fold:
Individual .NET-based applications that appeal to end-users , scripters, and developers
A set of re-usable components that makes it easy to build such applications
A vibrant community to help define these applications and extensions
In the near term, the Orchard project is focused on delivering a .NET-based CMS application that will allow users to rapidly create content-driven Websites, and an extensibility framework that will allow developers and customizers to provide additional functionality through module extensions and themes.
It depends on what kind of CMS you are after
pity you don't like programming otherwise i would suggest django, an awsome CMS framework
if you are after something simple like a few static pages and a news feed or something like that then wordpress might suit your needs well, except i have found i don't like how it handles gallery's
if you need anything more, like more advanced custom content types for products, i would recommend Joomla or Drupal, and have plug-ins that has good support for photo galleys
Joomla! will probably be a better choice. It is very easy to use and is highly extensible.
Have a look at:
CMS Made Simple
CMS Made Simple provides a fast and
easy way to create a professional web
site and manage its content, whether
it's for a small business or a
multinational corporation!
Features
General Features
SEO Friendly URLs
Integrated and online help
Modular and extensible
Easy user and group management
Group-based permission system
Full template support, for unlimited looks without changing a line of content
Easy wizard based install and upgrade procedures
Minimal server requirements
Admin panel with multiple language support
Content hierarchy with unlimited depth and size
Integrated file manager w/ upload capabilities
Integrated audit log
Friendly support in forums and irc
Small footprint
Design Features
Accessibility WAI, WCGA, Section 508
XHTML and CSS compliant
Auto-generated menu
Every page can have different theme
Design protected from content editors
Multiple content areas on one page
If you have a little C# experience then you can try Umbraco.
It is a very powerfull CMS written in C# for ASP.NET
It is one of the most powerfull both free and commercial CMS out there.
i recommend to check out the Feature Matrix so you can see if it fulfills your needs.
As an example http://asp.net uses Umbraco
have you tried DotNetNuke ?
I am a junior developer and I have just graduated from university this year. I am working private with some people and I have just been given a music website to develop using DotNetNuke. I have a some experience using DotNetNuke which I have gained making small modules that take care of certain functionality on a webpages but I have never taken on a whole website before. I would love it if some one would give me some guidence on how to approach this project and answer some of my questions.
What are the steps involved in developing a dotnetnuke website?
How different is it from a developers perspective to develop a dotnetnuke cms website from a cms website which was developed from scratch?
When it comes to the database do you add tables to the database incrementally as you develop new functionality or do you plan everything in advance and create tables and stored procedures at once?
What are the steps involved in developing a dotnetnuke website?
Pick your version (if you're starting now, pick 5.1.1)
Installation (use Source package locally, Install package everywhere else)
Settings Configuration (performance, security, user info, etc.)
Adding & configuring core/third party modules
Adding & configuring third party skins
Custom Extension (typically module or provider) Development
Custom Skin Development
How different is it from a developers
perspective to develop a dotnetnuke
cms website from a cms website which
was developed from scratch?
Very. When you're starting with an established CMS you're inheriting solutions to tons and tons of solved problems. In the case of DNN, you have a substantial framework at your disposal. The focus will be more on learning and leveraging the existing API/features. If you're starting from scratch you're providing that foundation yourself. Using an established CMS is not necessarily better than the other - it depends on what you're trying to accomplish. If you require fine-grained control over everything and you want a great learning experience, rolling your own may be the best way to go.
When it comes to the database do you
add tables to the database
incrementally as you develop new
functionality or do you plan
everything in advance and create
tables and stored procedures at once?
No matter what your project is, I'd suggest doing things as they are needed and not before. I think "doing everything in advance" would be impossible/horrible anyway. The heart of this question is really going to be defining your development process - I don't think this would necessarily be any different than in other projects. I like to define the features I want, organize them based on their relation to each other (which should come first due to dependencies, etc) and start implementing them one at a time and give each one the attention it needs.
You may also want to look into Lee Sykes' tutorials on module development using OpenWebStudio. However, I'm more on the design end, mainly just skinning, configuring, SE optimizing sites and matching client needs to our library of licensed 3rd party modules. However, the DNN community is VERY supportive and VERY helpful. There are some great resources out there, and I've found several blogs by the core development team to be essential for helping me wrap my head around the DNN framework.
Keep with it, and don't be scared to ask questions.
References:
www.dnncreative.com - Lee Sykes' Site, many tutorials on the how-tos of the DNN system. It's well worth the yearly subscription IMHO.
www.dotnetnuke.com - The main site for the DNN community
www.snowcovered.com - Central (AFAIK) site where many module developers sell their products, everything from skins to modules.