Om Templating

707 views
Skip to first unread message

Joel

unread,
Jan 24, 2014, 6:16:17 PM1/24/14
to clojur...@googlegroups.com
Is there a way to convert html to Om/ClojureScript syntax easily? Or, is there a way already to simply use some kind of templates that are closer to html?

J

Creighton Kirkendall

unread,
Jan 24, 2014, 6:38:04 PM1/24/14
to clojur...@googlegroups.com
Check out kioo, it does exactly what suggest.  It uses a model similar to enlive to pull html in and compile into react nodes.



CK


On Fri, Jan 24, 2014 at 6:16 PM, Joel <jo...@harpsoft.com> wrote:
Is there a way to convert html to Om/ClojureScript syntax easily? Or, is there a way already to simply use some kind of templates that are closer to html?

J

--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

David Pidcock

unread,
Jan 24, 2014, 6:47:33 PM1/24/14
to clojur...@googlegroups.com
On Friday, January 24, 2014 3:16:17 PM UTC-8, Joel wrote:
> Is there a way to convert html to Om/ClojureScript syntax easily? Or, is there a way already to simply use some kind of templates that are closer to html?
>
> J

Well, there's two different plugins for component syntax, but I imagine that's not what you're looking for. Perhaps something akin to React's own JSX, I expect.

You might get some leverage from using Enlive to parse the HTML into Enlive-form, and then output it for use with kioo (https://github.com/ckirkendall/kioo) .. which works with Om.

I'm not sure if there's an alternative as yet.

Mike Haney

unread,
Jan 24, 2014, 6:48:37 PM1/24/14
to clojur...@googlegroups.com
Creighton, I've been meaning to thank you for kioo, so - Thanks!

I've always been a big fan of the Enlive/Enfocus method of templating, and was excited to see kioo when David added it to the OM readme the other day. Planning on putting it through its paces this weekend with a POC of a fairly large webapp I am putting together for a customer.

David Pidcock

unread,
Jan 24, 2014, 7:00:53 PM1/24/14
to clojur...@googlegroups.com
... err , ninja'd..

@ Creighton -- Cool, I didn't know kinoo does the slurping part as well. Neat

Joel

unread,
Jan 25, 2014, 6:39:06 PM1/25/14
to clojur...@googlegroups.com
Hmm... It reminds me of using JQuery style of "programming", by decorating html ad hoc.

Sablono on the other hand has the template and "decoration" together, which I think I prefer, but really neither is quite like JSX that has raw html with code embedded.

Correct me if I'm not "getting it"

Creighton Kirkendall

unread,
Jan 25, 2014, 7:42:03 PM1/25/14
to clojur...@googlegroups.com
Enfocus, Enlive and Kioo were designed to fully separate out the view (HTML/CSS) from the code logic. It separates these by design. I built Enfocus and kioo to better integrate the designer into process of building interactive apps. The ideal workflow for this model generally starts with a static prototype built by the designer. Small changes to the UI automatically flow through to the application without the developer having to modifying the code logic. Where JQuery is all about the live dom, I tend to think of the Enlive style template as SQL for a static prototype.

Sablono and hiccup style templating are designed to make it easy for developers to manage the UI directly. In a workflow where the developer is also operating as the chief UI designer this works great.

Given you like JSX it doesn't surprise me you would prefer Sablono. Both JSX and Sablono combine markup with the component logic. My guess is your workflow is much closer to the traditional hiccup style workflow. Obviously I prefer to have the view separated but it is driven by my workflow. I have found that its best to use what makes you most productive and if it doesn't exist build it. :)

Hope this help.

CK

Joel Trunick

unread,
Jan 25, 2014, 10:40:25 PM1/25/14
to clojur...@googlegroups.com
I'm kind of torn I guess. I wish web-dev was more like desktop dev, where you tend to just use off-the-shelf components, and wire them together. Then templates aren't much of an issue.

I've seen the advantage splitting view/logic in webdev, and actually we are at a bit of a crossroads on our current project, so not sure which way to go at the moment.


--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to a topic in the Google Groups "ClojureScript" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/8ptKyAV2mjE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.

Don Jackson

unread,
Jan 26, 2014, 4:33:33 PM1/26/14
to clojur...@googlegroups.com

On Jan 25, 2014, at 4:42 PM, Creighton Kirkendall <ckirk...@gmail.com> wrote:

> Enfocus, Enlive and Kioo were designed to fully separate out the view (HTML/CSS) from the code logic. It separates these by design. I built Enfocus and kioo to better integrate the designer into process of building interactive apps. The ideal workflow for this model generally starts with a static prototype built by the designer. Small changes to the UI automatically flow through to the application without the developer having to modifying the code logic. Where JQuery is all about the live dom, I tend to think of the Enlive style template as SQL for a static prototype.

This is a really good articulation of the use-case target of these libraries.

Each of us will have our own requirements, and my requirements match exactly what Creighton has described above.
I use professional UI/graphics designers (when I can!) to create the style and layout of my apps.
Typically the furthest they can take things is HTML/CSS markup. They aren’t going to produce Clojure templates...

Right now, I am attempting to use Kioo/Om to re-implement a front end, and it is great to have actual HTML files
describing individual components/snippets that are stitched together.
And the HTML files are easily shared/updated with/by UI/graphics designers.

> Sablono and hiccup style templating are designed to make it easy for developers to manage the UI directly. In a workflow where the developer is also operating as the chief UI designer this works great.
>
> Given you like JSX it doesn't surprise me you would prefer Sablono. Both JSX and Sablono combine markup with the component logic. My guess is your workflow is much closer to the traditional hiccup style workflow. Obviously I prefer to have the view separated but it is driven by my workflow. I have found that its best to use what makes you most productive and if it doesn't exist build it. :)

When I don’t need/want the “plain old HTML file”, I use Sablono…


Joel Holdbrooks

unread,
Feb 16, 2014, 5:41:21 AM2/16/14
to clojur...@googlegroups.com
> Sablono and hiccup style templating are designed to make it easy for developers to manage the UI directly. In a workflow where the developer is also operating as the chief UI designer this works great.

I'd just like to say that this line really nails it WRT hiccup templating! My background was originally as a designer and I became a developer a long time after. And all this time I was wondering why Enlive never appealed to me.
Reply all
Reply to author
Forward
0 new messages