I am beginning a book on Ektron.

I am beginning to read a Wrox book called "Ektron Developers Guide" in advance of diving into an existing Ektron project on Tuesday. I wish there was a way to download a trial copy of the software, but unfortunately, all I can do in advance of Tuesday is flip through the one book (from 2011) that seems to have been written on the proprietary CMS. The software is not trivial. It has a significant footprint, expanding into many things. Beyond being a CMS, it offers a canned shopping cart too.

Ektron started in 1998 as what the book calls a WCMS (web content management system) and at the time must have been something other than web forms ASP.NET. It is today of framework 3.5 web forms ASP.NET, with an heavy emphasis on breaking chunks of screen real estate up into .ascx (User Control) widgets. The widgets may be "Ektron Widgets" which one builds using something called PageBuilder. These developers may build out themselves and get creative with. There are also over eighty canned ".NET Server Controls" which are for things that Ektron's own realize arise as common wants. Both varieties of widget take into account whether or not a user has permissions to see the widget, edit the widget right there in the page, etc., so there is likely a robust way to administer privileges for various varieties of users within Ektron. (I assume that is coming later in the book.) Ektron's stuff is a hodgepodge of home-rolled and not home-rolled. They defer to a bigger player in a given space when it makes sense. For analytics for example, one may use Google or Omniture. An API uses the following namespaces:

1. Ektron.CMS is the oldest namespace and the book seems to admit that it could be better.
2. Ektron.CMS.API is newer and allows one to do bulk data processing in code that is not easy elsewhere.
3. Ektron.CMS.Framework is the newest and is apparently slowly being expanded in scope to offer a better alternative to what one may find in Ektron.CMS which is piecemeal and not intuitive. The book suggests that once you're used to this namespace that things will be easy to find using IntelliSense and some guessing. One thing leads to another.

• System.Web.UI.UserControl will be used by a widget (an .ascx).

 
 

A surprising upfront chunk of the book is on Agile versus Waterfall and what the roles should be on an Ektron team. The book asserts that the better part of your team can just be persons who manage content and not actual developers. This is, after all, the whole reason to have a CMS. The book suggests that one should build a "CMS implementation guide" and that there is a sample project called "OnTrek" to be had that shows off how Ektron may be done with many widgets in use.

• http://documentation.ektron.com/current/OnTrek/PDF/OnTrek.pdf is on OnTrek.

 
 

When you set up Ektron, a wizard will walk you through the process and put folders in the right places. Some content is kept in an MSSQL database while other content exists as "assets" which I am guessing to be images and text/XML files. Even if all developers use a common database like a communal bowl, there is the problem of keeping copies of assets synchronized across all independent development environments.

Ektron has a feature called "Load Balancing" for this sort of synchronization concern and it also has a feature called "eSync" which allows each development environment to keep its own independent and standalone copy of the database without being so isolated that one cannot get the database updates another developer makes.

eSync doles out the database updates to the otherwise isolated environments. Think of The Tarantino Project, as it is going to be something like that. It looks like there are attempts to address speed issues with complication too. The book suggests that pages will not "recompile relevant files" unless there is a change, although what I have read thus far of this is vague. There is a "Workarea" folder that takes forever to compile and cannot be set to be excluded from its project given Ektron's nature. One can hack around this pain point by making the folder hidden in Windows itself. There is a way to debug libraries without launching the debugger or running unit tests, but what I have read so far is also vague on how to do this.