reconsider the builder logic

[mpo]

There are a umber of issues that all run around how the HTML is created in our form-controls.

#82, #199, #204, #103, #164, #174, #202, #207, #251

And the feeling is that those might easily be solved by reconsidering the self inflicted complexity we face today.

What is complex (but potentially nice)

• different kauri-role islands in an HTML template can not only be found, but also created individually if not found, and if a core 'input' role is not provided (if it is: then no other roles are being built)
• specific roles can be detected without kauri-role attribute set
• this approach calls for a complex 'elements' config-member that needs to express how to 'find' or 'create' the individual roles
• the 'isCreating' logic needs to be handed over continously, and evaluated at lookup of the different roles
• for all controls the 'input' role is the important one, allthough that doesn't seem to make sense for more feature/visual-rich controls that aren't even bound to actual HTML form controls

How would a simplified life look like?

• Drop the find-role-stuff and go for all or nothing approach: if no (==not one) elements are found that are tied to the current kauri-idref, then create them all at once using some predefined 'html' config member (simply using $.html(fconf.html); followed by a call to index the produced elements)
• the config member just holds a simple string versus the current 'elements' struct:

html: "<input kauri-role='...'>"

which can more easily be overriden at the fconf level

This should largely keep the same flexibility for doing extensive templating, but would make on the spot fconf driven template introduction more easy.

Note: this should not change anything to the ability to derive fconf settings from the HTML template.

[mpo]

Don't forget to look at the effects on the sample for #242 (we should be able to get that working without any HTML inside the </form>)

[mpo]

me thinks #266 smells like this as well

[mpo]

we should be able to just close #226 when this is done.

[freya]

The builder logic has been 'reconsidered' since r1433. The other opened issues (#174, #251, #207) remain but don't imply a reconsider of the builder logic