[langsec-discuss] Fwd: HTML syntax trees for Ruby

Arne Brasseur arne.brasseur at gmail.com
Wed Aug 28 13:07:05 UTC 2013


On 28 August 2013 02:03, Will Sargent <will.sargent at gmail.com> wrote:
> So I've used projects like Erector before, and I have to say that Erector
> was extremely difficult to use, ironically because it was a real programming
> library.  Almost immediately, the programmers started working it into
> patterns that the designers couldn't maintain.  The end result is that
> programmers found themselves writing almost all of the view code, while the
> front end developers and designers were hamstrung.  Counter intuitive, but
> there you go.

Actually I'm not surprised at all, I've had the question asked on how
to work with designers a couple of times. Designers usually aren't
coders, and putting too much complexity in "their" front end will
typically not be very appreciated.

I do think it's possible though, and that there might even be new
opportunities, but it's something organizations will have to figure
out how to do best. The approach I'd like to promote is to work
extensively with widgets that create rich semantic markup, and leave
the designers to focus on the CSS. This does bring some of the
responsibilities that before were clearly with the designers now more
towards the developers. You might want to have a "design engineer" in
between who makes sure both sides work together well.

The upside of this approach is that you get higher reuse of front-end
components, hence a more consitent UI. And by simply rendering all of
the components on a single page you get a great "styleguide" that
designers can target with styling.

If you do want a more traditional approach with templates that's also
possible. Designers are getting used to work with languages like Haml
or Slim, and these could be made to generate syntax trees.

In my talks I've been talking about the "Apples and Snakes
Architecture". Snakes are strings, they bite you. Syntax trees yield
apples, they're tasty. You want to keep the snakes out of your app,
and convert from/to apples (syntax trees) at the boundaries.
Templating language implementations, like most other existing tools,
are not "Apples and Snakes", but they could be reimplemented that way.
This gives you enhanced security, but it also makes these tools more
compatible/composable.


----
Arne Brasseur
Twitter/Github : @plexus


More information about the langsec-discuss mailing list