Strong +1
This is a great idea.
This would allow more flexibility in some corner cases and
prevent unnecessary duplication, not to mention sharing.
Another example: I believe crate compiles templates using the DOM API,
which is often fine, but sometimes you'd want it to do this using raw
strings (when working with a large number of Elements), for performance
reason. This would help to solve such issues.
Max
On Sunday, November 25, 2012 12:11:09 PM UTC+1, Dave Sann wrote:
>
> I wonder if it would be worth making the effort to separate the hiccup
> rendering from the hiccup generation in these libraries.
>
> By hiccup generation, I mean constructing data of the form [:tag {:attr
> val} contents] ...
> By rendering, I mean
> in the case of hiccup - producing HTML strings
> in the case of crate - directly producing DOM nodes in the browser
>
> My thought is that this would give a generic set of hiccup data generating
> functions that could be easily used across both libs with rendering
> specific to the environment.
>
> I don't generally use the libs in hiccup or crate because they are not
> portable and slightly inconsistent in places - all my hiccup data
> generation code can run on the server or on the browser. It might be good
> to have a core unified set for both...
>
> thoughts?
>
> Dave
>
>
>
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
