Development Model Selecttion Feedback

Sharon, I would not agree with your assumptions.

We do heavy customization and use the Portal Model Only. There is nothing you cannot accomplish in this mode with any customizations, and it makes it very modular. We are .NET Developer's minimum 7 years experience and have found through trial and error that the portals mode is the best way to go.

Once you get used to it and the nuances, making changes, deploying custom libraries and classes, custom modules and custom web parts is quite easy. There is no reason to create any .aspx pages from scratch. Develop .acsx controls and use them on pages, one or many.

Honestly I cannot think of any reason whatsoever to use .aspx templates, and believe me I have tried. You limit your functionality as well.

Sharon,

I couldn't agree with Charles more.

I've been working with Kentico since 2008 and being a .NET developer since about 2000, like you starting in VB and VB.net. What I've found is once you know the equivalent of what you're doing in ASPX in Portal mode you won't go back. For instance, I came across something as simple as this in an aspx template:

<cms:CMSRepeater ID="rptListing" runat="server" ClassNames="cms.event" WhereClause="EventDate >= GetDate()">
  <HeaderTemplate>
    <table>
  </HeaderTemplate>
  <ItemTemplate>
   <tr>
     <td><%# Eval("EventTitle") %></td>
     <td><%# Eval("EventDate") %></td>
   </tr>
 </ItemTemplate>
 <FooterTemplate>
   </table>
 </FooterTemplate>  
</cms:CMSRepeater>

This can easily be done by configuring the site using the Repeater web part and a simple transformation vs. writing code. The whole point of web parts is to be reusable.

I've done heavy integration with several systems and have found there really is no need to use ASPX as it just complicates things. One of the most frequent calls I receive is to do upgrades. In most Portal modes, things are pretty smooth. When you add any kind of ASPX development into the mix, it only complicates matters and more opportunity for failure.

Ask any one of the MVP's who work for some great Kentico Partners, they will tell you as well, Portal all the way. Some of them have been working with Kentico since v1 or 2.

If you're looking for some additional reasoning, look me up and I'd be glad to share more with you. I'm all about client experience and using ASPX, really limits their possibilities and makes them more dependent on a developer, which ultimately isn't a good thing for the client.

Hi Sharon,

I started developing websites on Kentico two years back. I was back then a Python developer. I had a lot of exposure to web development back then when I started with Zero ".NET" background.

In last two years, we were able to deliver around 15 websites, big and small. Few are that large that they are still under development.

I thank that I didn't know anything when I started due to which I picked Portal Engine as a preferred development model.

95% of the development we are able to achieve is using Out of the box web parts and components.

Now I am convinced that 80% of the functionality on your websites can be straight away achieved using Repeaters and rest with Hierarchical/Universal Viewers.

My team compromise of UI designers/developers and we are able to achieve almost everything. We have not done more than 5% of custom development in last 2 years.

I hope this write-up helps in the smallest possible way to get started with Portal Engine development model.

Regards Chetan

Thanks to Charles, Brenden and Chetan for your input.

Charles and Brenden, not really sure what you mean by "limit your functionality as well", but I take your points. As a matter of fact, in the past I've been able to demonstrate to potential clients that the advantage of a Kentico system over many other systems is that it is a standard asp.net application, and that any competent .net developer would be able to pick up the Visual Studio project and "run with it". On the other hand, a project (site) that is purely Portals mode will require quite a bit of Kentico-specific knowledge to manage and implement any future modifications.

And Brenden, that is the strangest CMSRepeater I've ever seen! No transformations? You can use web parts in aspx files with transformations exactly as you do in portal files. As a matter of fact, I try to use custom web parts with transformations for custom functionality wherever possible - the power and simplicity of transformations is second-to-none! Perhaps that repeater is an example of something implemented by a .net developer who had no Kentico-specific knowledge, but it also shows that - even though it's a "bad" way to go about things - it IS possible to implement something that your client wants immediately into their .net Kentico project using your standard .net skills.

I agree with your sentiment, Brenden, about forcing clients to become dependent on the developer, but the situation I'm describing here is really where a client WANTS the developer to do everything for them (except actual content creation/editing) - and if the relationship with the client breaks down and they want to move on to another developer, they can simply find a developer with adequate .net skills who can take over the project.

Upgrades - I've upgraded many aspx projects over the years, one or two of them from a version such as 3.1a right the way through to version 7 all at one time, and the only problems I've ever encountered were related to the changes in the Kentico API than to any customizations that I had been implemented. So I'm not sure why you believe upgrading an aspx site is more difficult than upgrading a portals site.

Nevertheless, only last week I've discovered that, when a site/project has been originally developed in portals mode and you want to "upgrade" it, you can just export it from it's current version and then import it into the higher version. There are still a few things you've got to fix up manually, but the whole process was much less time-consuming and painful than having to step through all those "upgrade" procedures - which includes having to have individual VS projects for each version along the way, and "run" the site at each version step to complete the relevant upgrade. I did this with a version 5.5R2 portals site, importing it into the latest version 8.2. The project also has a complex custom module, which required some modifications to the c# code to update various classes and procedures, but as I said, much less time-consuming and painful than actually "upgrading" the original site. AND all the content comes with the import, including all the database records created by the custom module.

I recommend this blog post