by So far, most of the difficulties in customizing a Ektron is that a lot of the abstractions in a standard web application are already encapsulated by the system. For example, containers and controls such as images, content blocks, pages, forms, the CMS already has a pretty rich set of data attached to these. The problem is, where the rubber hits the road, you need to provide a widget that will run in the Ektron platform and use the Ektron structures for persistence, and the UI rules will demand a title, body and image for numerous UI blocks, but Widget1 will only use an image, and Widget2 requires and image and body, but not a title, whereas Widget3 requires all 3. Ektron provides a “Smartform” concept that lets you define a structure of data via a graphical WYSIWYG form builder which represnets itself as XML. Once you have a Smartform, you can associate it with a content directory, then new instances of the smartform can be created and populated by the user then saved as a content item.
So great, I have a Audio Player widget, that takes has a resource selector smartform input control, which allows the user to pop up a graphical Content Folder browser, which can be limited to certain types of content and allow the user to pick. His choice is persisted when the new instance of the smartform is titled and saved.
Now I need to build 2 jukebox widgets, “Jukebox A” that has requires a audio resource and a body which is a standard HTML content resource (in ektron); and “Jukebox B” that just takes the audio resource. So, I can make a “Jukebox Item” Smartform, which has both an audio resource and a body resource and create 2 new smartform instances, based on the “Jukebox Item”. Roadblock… Since A requires both, and B only needs the one, the smartform allows us to require it, but we can’t put the same requirement on the body, because not both widgets will use it. Leaving you with the sad solution of spreading validation (and persistence) over the underlying items and the final widget edit UI. Custom HTML can be provided in the smartforms so custom javascript validation and manipulation could be performed, but doing that is the exception to the rule, not the standard way of doing it in Ektron.
Another problem using the smartforms are the when the resource picker control is used, it presents itself in terms of the CMS system’s content, where you’d like to restrict a resource to another smartform instance in particular such that if you have a Image Carousel Item and a New Item, you could restrict the content shown to contents that use that form as their base. Having said that, the content chooser is part of the workarea code, so it could be modified. The WorkArea is the code for the CMS system. It can be completely customized, the question is how far out of the box do you want to go, especially if you need to upgrade to a new version down the road.
It just seems like these would not be new complaints. I’m no SharePoint expert but this is why they have content types that can be created and treated like first class citizens, the less customizing of the actual CMS system, the better.
It’s not terrible, but something to consider.