Dynamically built html with Clay

Topics: General
Nov 2, 2011 at 9:04 PM

Just a random idea:

What if we used dynamic objects (I hope this is possible with Clay objects) to describe html markup? Let me show an example:

Instead of writing this in a view:

    <label for="field">
    <input type="text" name="field">

We would write something like this:

    ClayHtml.label(for: "field"),
    ClayHtml.input(type: "text", name: "field")
There wouldn't be actual templates hard-coded for every html element, such expressions would be resolved with some kind of "reflection", as it's today with shapes, to give the same result as above.

The benefit would be that this way additionally to the tree of shapes we would get the tree of markup (practically the DOM on the server-side); that means, parts of the markup could be modified without overriding a whole shape.

What I would have done with this technique is the changing of a select box of a form in another part. I wanted to change the select to a hidden field as I wanted a value to be given programmatically, unnoticed by the user. AFAIK this can be done by overriding the whole editor shape of the part in question (and copy-pasting the code still required), or hiding the field with JS. I've chosen the latter one, although it's not something I would recommend.

I know the new Forms module does something like this with forms, but what about being able to do everything with dynamic objects?

What do you think?

Nov 2, 2011 at 10:46 PM

That's actually what Forms is doing, I don't understand your point about it. Can you elaborate the differences ?
Also Forms introduces events so that anyone can alter a form before it gets rendered, or validated. 

Nov 3, 2011 at 12:33 PM

When I had a look into Forms, it seemed there were no field-level events, only form-level ones. This makes it hard to figure out how one would package any non-trivial functionality into an easy-to-use dynamic form control. Has anyone had any thoughts about this?

Nov 6, 2011 at 8:50 PM
sebastienros wrote:

Can you elaborate the differences ?

The aim of this approach would be to add a lightweight dynamic templating mechanism for every (customizable) piece of the site, not only forms (although the greatest need for this is indeed with forms, so maybe this is pointless altogether and Forms is just more than enough).

Or another random idea that would make this pointless again: what about adding a mechanism to add filters per-shape (template) basis? I'm really talking about intercepting the generated html corresponding to a shape here. The aim would be the same: if shape overriding would be too much, one could alter the html (with something like Html Agility Pack) just before it gets sent to the client. AFAIK currently this is only possible with the whole generated html on a per-page basis, and this only with some non-trivial output filters. I don't know whether filtering an individual view would be possible.

Nov 10, 2011 at 6:59 PM

I found out that my point about not being able to alter the generated html of shapes is incorrect. It's indeed possible:

    public class ShapeTests : IShapeTableProvider
        public void Discover(ShapeTableBuilder builder)
                .OnDisplayed(context =>
                        var html = context.ShapeMetadata.ChildContent.ToString();