Building a Virtual DOM in SSJS

#1

Hi guys,

I’m wondering if anyone has been able to add any DOM parsing or HTML parsing with server-side JS.

Currently, I have Squiz forms that I want to customise the form without using body-copies as the form only needs minor changes to all fields and this will force the form to be maintained by developers from now on.

I have been unable to get keyword appears to not be parsed within the input ‘Extra Attribute’ section so my next step would be parse the output of %form_contents% into a virtual DOM and manipulate it that way, but due to inability to use Node packages I’ve been looking at including something like jsDOM/phantomJS in a browserify-ed form, but have been unsuccessful.

Performing these operations client-side is all prohibited so the manipulation must occur before the page arrives to the client.

Has anyone had anything similar?

(John gill) #2

I deliberately haven’t tried to add any kind of dependencies or modules to SSJS. Apart from performance concerns, I suspect it’s a mistake to spend effort trying to add complex code in an environment with such limited debugging options.

I have hit a few situations where it would be very handy to be able to massage a DOM rather than strings, but so far nothing compelling enough to try.

Specifically on the form front, I think that the safer option would be to write a tool to generate the HTML you want and then add it to a custom bodycopy. Basically something that can take the structure of the form (from an asset listing of sections and questions) and run it through a mustache-or-whatnot template. Each time you change the questions you would just re-run the generator and update the bodycopy, rather than having to maintain the bodycopy manually.

#3

Yeah I was thinking that but just trying to be optimistic. Haha, thanks for the info and I’ll probably crack into that using JSAPI or something.

(Mark Graham) #4

We’ve had quite a lot of success using Handlebars to build out dynamic content container templates.
All of the logic is in SSJS and we just use a standard page as our “template”.

https://handlebars-draft.knappi.org/

(John gill) #5

Very interesting. Do you mean you have content templates that publishers can modify by providing their own handlebars snippet, or do you use handlebars in building the content template itself?

I’ve pondered something like this to give publishers more flexibility before but always figured it wouldn’t be worth the effort. Maybe I should reconsider and give it a shot.

(Mark Graham) #6

Right now we’ve got it locked down to admins, but in theory that’s a possibility.

The standard pages just feed in the HTML as a string variable to the SSJS that “compiles” it.
There’s no reason that users couldn’t provide their own templates in the future, so long as they followed a set of predefined rules.

It’s really easy for us to stand up new content container templates with dynamic elements (i.e. carousels with multiple layouts that can be selected in metadata of the content container) on short notice using this method. The only real draw back is it isn’t as performant as if you did it with pure keywords and nested content.

(John gill) #7

I can see how it would make multi-format templates much cleaner. I’ve tried a few methods to give templates a “Choose layout” dropdown and none have been great.

Out of curiosity, what data are you feeding into the template? Custom JSON built with keywords or are you working directly with %asset_data(_metadata)% or similar?

(Mark Graham) #8

We’ve tried to keep the metadata simple enough that we can do either conditional keywords on the metadata fields to define simple JavaScript variables, or at least use some if else statements.

the %asset_data% keyword would work, be we just didn’t need access to that much information.