MVC + Portal Model (Widgets)
I would have like to start using MVC with Kentico since the company I work for prefers MVC pattern over Web Forms. However after talking to Kentico support we found out you can not use the portal model with MVC.
Is this functionaility planned for any feature release or part of Kentico 8?
We are currently trying to come up with the best model for enabling Content editors and Marketers to compose parts of pages using widgets also on MVC websites.
What do you think about the following:
1. The most important part is to enable business users (Content editors, Marketers) to add and configure components (widgets) in within specific areas (zones) on a page
2. MVC developers know how to create layoyuts/templates and can do that on their onw, only need to be able to mark part of the layout as a widget area/zone
3. MVC developers know how to implement reusable components. If there is a unified way to register such components with Kentico to be used in widget areas, there is no need to develop hundreds of out-of-the-box widgets.
4. The biggest wish for Content editors and Marketersis to be able to influence a section of a specific page, or multiple sections of the page by adding, reordering or configuring certain components. They do not need to build the entire website and its structure as this is something that an agency with developers would do for them.
Also, please comment on the following scenario, does it apply to you? Do you think that another scenario is more common and requested?
A Marketer is responsible for a new Campaign. The campaign needs a landing page. The page needs a short URL. The page can be based on one of several pre-designed templates (from an agency) with an optimal number of areass for widgets, The Marketer can Drag&Drop pre-designed widgets (from an agency) into these zones. Some of these widgets may contain personalization logic. The page may need to be AB tested.
Elmar Höfinghoff commented
For our company the missing MVC support (including page editor features) is the biggest showstopper for Kentico Websites!
This is such a big problem, that we can't even use Kentico on some customer projects anymore!
Thanks a lot for sharing comments. After conducting a research, we are aware that many project would move towards MVC nowadays, the only missing part being "widgets".
After evaluation of internal prototypes, we are certain that introducing widgets is one of the top priorities. From our recent evaluations, Kentico 10 MVC and Kentico 11 MVC projects could be switched to widgets once introduced, however, due to higher priority of addressing GDPR, this will not happen at the same time as the actual Kentico 11 release.
I can't even express how much I am looking forward to this functionality being available to you guys and see what you can achieve with it!
I just saw on the Kentico 11 Roadmap page this feature is now listed as postponed. Seriously!?
We are approaching the 10th anniversary of .NET MVC CTP in a couple of months and Kentico *still* can't do MVC? It boggles the mind. Other CMS's have had full MVC support for years.
When is Kentico going to get serious about MVC support?
Sounds good @David Komarek
Every new major version of Kentico we eagerly review the MVC functionality and decide it isn't ready. I was hugely disappointed to discover this missing in Kentico 10 as I was told it was coming by our partner contact. Without MVC widgets we'll never be able to use MVC as it is too restricting for clients.
I agree with Hans on the point about this being a must have for Kentico 11. WebForms is dying and developers don't want to use it anymore. This is probably without doubt the highest priority feature for us in Kentico 11.
Hans van der Linden commented
Great to read the above, I agree on all points. We currently have a lot of difficulty to convince the client that Kentico MVC is, from a technology point of view, the better option. Two important reasons for choosing Kentico is 1) flexibility for editors / webmasters by using widgets or webparts 2) out of the box functionality by having a lot of standard webparts / widget.
I am convinced that MVC widgets is a ‘must have’ for Kentico 11.
Graham Barden commented
There are two aspects for this for us:
- Allowing our developers to develop in the modern frameworks, our team want to move to MVC for many reasons and the lack of full support for the Portal engine is holding this back. Our clients sometimes express the requirement that they want the solution built in MVC because they may want to support the site with an existing team or hire new developers and MVC makes this easier.
- Our customers love the widgets and widget layouts within their solutions, this is a real differentiator to your competitors so if this is lost the product will lose a USP. If this functionality is combined with the MVC approach then we have a real winner against other products in the market.
Chris Percival commented
We recently nearly lost a major bit of work because customer insisted on a 3-tier model for security. In Kentico terms this means using the MVC model. However we also knew that the MVC model would not give them the flexibility they need to create the content they want going forward. Luckily they agreed to 2-tier in the end.
The ability to create a page out of components is key, and things like create a form for a campaign on the fly without needed large amounts of custom code to be written.
I'm sure it's a complex problem, but one I think that Kentico needs to address.
Jonathan Healey commented
I would agree with all 4 points.
The key thing here is that developers want to work in MVC (for very good reasons). Right now they can't because without "widgets" in some form marketers lose too much of their desired "out of the box" functionality such as: building their own landing pages, running MVT tests, making use of personalisation etc.
At some point developers will lose patience and stop wanting to use Kentico - this is already a major challenge for all of us in recruitment and staff retention.
If marketers can place a discrete component into a predetermined area of the page and configure the properties of that component to facilitate personalisation and MVT I think you have everything you need.
Drag and drop, placing widgets into a WYSIWYG area, previewing and permissions on zones are "nice-to-haves" for me. Probably more important than these would be support for layout widgets.
Our favorite part of portal engine is the ability to create wysiwyg templates for content editors to drag and drop widgets around in - however, this is also the biggest blocker to implementing this in kentico MVC.
If we can live without that, the workflow would be that the editor would "drill down" into a section and set widgets, then go back and see the changes rendered in-kentico, in a similar way to the current preview mode that portal engine has.
Ilesh Mistry commented
I would agree with the comments so far on this.
Being able to personalise the widgets is really important for us to have with the macros.
It would also be important to know that if or should the layout/zones be changed on the MVC side, the widgets should not be lost.
Are we okay to assume the default behavior we see in Kentico for widgets, e.g. copying and pasting will still be possible?
Also if possible the ability to move widget up or down within a zone would be good to have, like we have for web parts.
I agree with all your points. Especially about not needing hundreds of out-of-the-box widgets as I have never used these.
Personalization of widget/webparts created with MVC is the most import for me as this is the biggest selling point of Kentico when talking to our clients.
MVT testing with MVC widgets/webparts would also be a bonus.
Elmar Höfinghoff commented
1.) Agree, it is most important. I want to add: Widget Zones have to be configurable WHICH widgets are allowed to be inserted here. This is currently missing in the Portal Engine.
2.) Correct, template editing must not be included in the CMS. Nice to have.
3.) Correct, I do not need hundreds of out-of-the-box widgets. The most Web Parts or Widgets are too specific and come with not wanted markup. This is the biggest argument to develop in MVC. So we do not need ootb content.
4.) Agree, content editors need only some sections to add and reorder components.
More than OM tasks, default content management is focussed in our projekts. Widgets are nice to add some individual content to static templates, which are based on repeater content.
The mixture of data pages, used as source for these repeaters, and individual content added as widgets is a very common szenario. Too much widgets are confusing the editors.
In case it would be only in rich text editor, how "rich" would you expect it to be?
A) Would having that as just block element (no option to create more column layouts other than table-based) be somehow problematic?
B) Would you require a working preview (rendering) while editing that, or would it be enough to have a placeholder icon in the editor as with current implementation?
Could you provide some typical examples of the use cases for the widgets your users would insert into rich text?
I didn't get from your response if you would like widgets also outside of the rich text, or if they are not needed at all by you. In case you would still want them (just prefer rich text first), what would be the bare minimum that it should provide in that case?
Widgets (which could just be widgets in ck editor fields just like we have in portal engine) is a critical feature, without which kentico's MVC offering is sadly lacking.
This definately gets my vote. I want to move away from portal engine for maintainence and performance reasons.
Let me second to Marnix question.
How important for you is the WYSIWYG aspect of widget editing compared to editing widgets in some structured way, and just the ability to preview the result?
Similar to that, how important is some kind of inline editing (e.g. rict text) in the visual context of a page compared to doing the same through a properties form?
Both from ability to sell / usability perspective ...
Marnix van Valen commented
I've been thinking about the requirements and implementation of widget-like functionality for MVC and would love to hear some feedback on this.
In essence, a widget is just a piece of content. Much like a page but simpler. It has a type and a bunch of typed fields but probaly doesn't need URLs, aliases, metadata and all that.
So you'd need to be able to add and configure the fields for a widget, similar to managing page types.
Next it should be easy to associate a widget with an area on the page, like we do in Portal engine. That doesn't have to be wysiwig, it could be a simple table on the Form tab where we can add, remove, reorder or open the widget details. I'd imagine we'd call that a WidgetArea field. There should be a name on the field which is unique within the page type.
Then, on the MVC side, I would like to see some infrastructure that returns a list of typed view models for a widget area on a node/page.
MVC can perfectly well render the appropriate Partial View based on the type of each instance in the list.
The model that needs to be returned for a particular type of widget should be configurable through an API. Configuration through an attribute would be a nice-to-have feature. I would prefer these models to be POCOs (I have no love for the way TreeNodes are actually dictionaries of key value pairs).
With that in place I believe basic widget functionality is covered.
The thing I like particularly about treating widgets as content is that this would probably fit well with Kentico Draft.
Shannon Dunn commented
Kentico's portal engine helps them differentiate themselves from SiteCore and others with its ease of use and way of approaching a CMS that is easy to understand for non technical people. MVC is the only way forward if you want to keep up with Microsoft but Kentico needs to find a way to make MVC and portal engine work. I talked at 404 extensively about this with Martin during my 1 on 1. :)
Matt Nield commented
I'd echo Luke Ballantine here if at all possible, but just being able to have the configuration of the widget in place would help. You can always develop your controller to deal with the widget settings. I don't think I'd worry too much about web parts/design view. To me, it's more about adding the editorial control to the page.
Ideally in Kentico MVC we'd be able to build widgets with Partial Views and have the ability to add & remove these widgets from the page within CMSDesk, just like you can with Kentico WebForms.
Hi, what would be the most important behavior of Portal engine like functionality in MVC for you scenarios?
Or is the main motivation just having Portal engine and instead of writing web parts and transformations like in WebForms, you would like to implement MVC views?