A long one this - get a coffee...

We've had to use [proprietary .Net CMS] a little at work recently (for a client who wanted to sink half their budget in licence fees ;-), and it has got me thinking again about an area in mojoPortal that I feel needs improving - Feature Templates. 
The problem is that in mojoPortal there is no way of helping (and ensuring) that content editors create good and correct content.  The HTML templates are better than nothing, but they can be broken easily by the editor, require html coding skills (when the editor messes things up)  and they do not enforce valid content where a page/feature must contain certain things.

Maybe there's a good way of achieving this in mojo already, but if so I've missed it!

I've drafted a design below for your consideration, taking the broad concepts of a data template plus rendering from [proprietary .Net CMS], and thinking through how something similar could be done the mojoPortal way.

Component 1: Feature Template Designer (probably added to Administration menu), creates named templates that then appear as Features (virtual) that can be added to pages.

Component 2a: Feature Instance Editor: Once a Feature Instance has been created by dropping a Feature Template onto a page, this component presents/hydrates the editing form for the Content Editor.

Component 2b: Renderer.  Fetches the data for the Feature Instance, and executes either a default rendering or uses a bespoke XSLT/ascx renderer for the Template Feature Instance (see below).

I think this could be assembled almost entirely from existing mojoPortal elements, but packaged up in a very new way.
The Feature Template Designer could borrow from Survey and/or Form Wizard Pro. But instead of "questions" we are defining "fields" or perhaps "page elements". It would need additional data types: "HTML Content", "Image" (and this range could extend through time).
The resulting form is not for end users (as in a Survey), but is for anyone with editing permissions on the Feature instance. The form controls are not rendered onto the page for viewing, they are simply for collecting the data values that are then rendered onto the page i.e. what the real web site users will see.

Workflow (using the hypothetical example of a web site listing camp sites).
Site administrator uses the Template Designer to create a new Feature Template ("Camp Site Feature").
They configure some Feature Level properties for this Template:
• Feature Template Name: Camp Site Feature
• Custom CSS class for rendering: campsite
• (and other properties similar to but simpler than Form Wizard Pro, because these forms are only for content editors)
• Web Renderer (optional):  [none (for default rendering), or path to an XSLT or ?ascx that controls the rendering]
• Mobile Renderer (ditto):

They add the following elements to the Template:
Element 1:

• Label (aka question text): Camp Site Name
• Control Type / Question Type: TextBox
• Required?: True
• HTML rendering container (optional): [pick-list of HTML elements, h1, h2...p, etc]
• CSS class for rendering: campsitename
• Validation Regex: ^.{10}.*$
• Validation message: must be at least 10 characters

Element 2:

• Label (aka question text): Description
• Control Type / Question Type: HTML
• Required?: True
• HTML rendering container (optional): div
• CSS class: campsitedescr
• Validation Regex: ^.{100}.*$
• Validation message: must be at least 100 characters

Element 3:

• Label (aka question text): Picture
• Control Type / Question Type: Image
• Required?: True
• HTML rendering container (optional):
• CSS class: campsiteimage
• Validation Regex:
• Validation message:

(and so on, including contact telephone number, email , etc).

Once the Feature Template has been designed, any content author with permissions to add features to a page can add the "Camp Site Feature" to a page. To populate this instance, they click "edit" for the feature, then fill in the form defined above (or edit previously entered values for an existing instance).  When they save/update, the entered data is rendered in its final format.

The data would be stored associated with the Feature Instance ID.

It would be beneficial to have a "Copy As" [__________] tool when editing a Feature Instance (a camp site) (a bit like for skins), to create a new Named instance of the Feature that copied the existing data (one campsite is much like another!). It would also be useful for the Administrator to be able to "Copy As" the Feature Templates as well.

The rendering is important, and is where the true power of this approach arrives. For simplicity there should be a default rendering, that just spits out the data values in order, using the specified "HTML rendering container" specified above, or a div where not specified. Add the css class to the container if specified. OR, if the admin has specified a particular renderer, pipe the data through that (either > XML > XSLT > HTML, or  hydrating controls in the ascx by matching property names).  This approach means a developer can achieve highly sophisticated renderings, while the default rendering would still achieve effective and consistent results that could be poshed up with CSS.
I'm pondering over how to manage different renderers for different devices, but since you have a simple "web/mobile" model at the moment, that should be fine.  In due course it may be possible to go more advanced with custom devices defined (tablet, phone etc) but your ideas on this will be better than mine!

Finally, the above would combine well with improved "Page Template" management, meaning that a content editor could create a new Camp Site page with a couple of clicks, but that's another request that has been raised in other threads.

This could take mojoPortal to the next level, in terms of being a viable CMS for large organizations, so I hope you can consider it.  We'd also considering developing this for/with you, though we are running at capacity for a while. Happy to discuss further.