by Well, as you may be able to tell, I have been, eating, drinking, and breathing Ektron lately. And I think I am beginning to see the light, by which I mean, how Ektron wants you to work within itself. It’s a pretty powerful system.
What I ended up with is creating a “Widget” content directory, and a directory within for each widget that I am backing the configuration with the results of a Smartform instance. So, I created a Smartform per Widget, and assigned that widget to be the default and only Smartform for that directory, and requiring only Smartform content in that directory. The net result is, I can now hook into the existing way to simply call that directory with a “add” command via http request, and popup the authentic CMS400 smart form content editor, my widget just needs to create the content and persist the new content id.
That way, when the widget is dropped on the page, in edit view, you can create the configuration Smartform, and then subsequently, you are displayed the XSL representation with a Ektron Edit “button” to bring down the standard Ektron contextual edit options. Downside is having the right named controls to receive updates from the Ektron Editor Add New form closing. It’s a little messy but there is precedent reference code to look at in some other widgets (hint: ContentBlock).
Additionally, I still need to create a page that will render a widget dynamically, actually, each widget will need a default template such that when the content itself is referenced alone (like an embed link) it will provide an appropriate rendering. The default behavior is to pass it though a rough xml render with nodes and elements and attributes, in a digestible format.
What you really need is what this page looks like alone, which doesn’t exist without the context of the widget, which needs to live on a page. Attaching it to a template with a dynamically populated Smartform of the correct type will yield a stand alone page for that Smartform instance. Complete with master page support at the .aspx level.
One could provide a pretty XSLT to render the Smartform’s configuration XML more attractively then the default, but for design / content author mode the default is passable, just not that pretty.
All in all it feels pretty right. It is an odd situation though, I’m providing Widgets to Content Authors, so since they are exposed to these Ektron built in editors, the consistency greatly affects the end result. Typically the widgets are meant to interface with external systems or provide relatively autonomous functionality and configuration wouldn’t be content. But my audience is a technical staff that will put the pages together using these widgets, and their customers will add the content in the pre-created locations and widget sets, so a more in depth configuration methodology was required. Turning out pretty well.
All in all, I like it, while it has some room for improvement. I think they should create a community edition.