This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-04-01
Channels
- # announcements (21)
- # architecture (6)
- # aws (18)
- # babashka (14)
- # beginners (231)
- # boot (1)
- # calva (2)
- # chlorine-clover (22)
- # cider (34)
- # clara (16)
- # clj-kondo (53)
- # cljdoc (5)
- # cljs-dev (22)
- # cljsrn (3)
- # clojure (283)
- # clojure-europe (24)
- # clojure-italy (9)
- # clojure-nl (5)
- # clojure-spec (5)
- # clojure-uk (57)
- # clojurescript (14)
- # core-typed (8)
- # cursive (4)
- # data-science (11)
- # datomic (41)
- # docker (24)
- # duct (2)
- # emacs (2)
- # exercism (29)
- # fulcro (96)
- # graalvm (4)
- # jobs-discuss (1)
- # kaocha (53)
- # lambdaisland (20)
- # malli (5)
- # nrepl (4)
- # observability (7)
- # off-topic (40)
- # pathom (44)
- # pedestal (8)
- # re-frame (19)
- # shadow-cljs (58)
- # spacemacs (2)
- # sql (9)
- # tools-deps (15)
- # vim (3)
- # yada (10)
just fyi, there is a new #observability channel, for monitoring, logging, traces, alerting and higher level observability discussions :)
core.match lists a paper which mentions an optimizing compiler for a backtracking automata based matching solution. I could never find a copy of the referenced paper except the ACM archives are free to use now so its finally online for free if anyone is interested. https://dl.acm.org/doi/abs/10.1145/507635.507641
The tradeoff is one of code size versus run-time speed. Since core.match can throw some methodsize too large errors I wonder if this might be useful
How do HTML relates with XML? HTML is a "superset" of XML? There is a subset of HTML that is XML, and all HTML features are accessible from this subset? Context: I'm planning to do a SSR library in clojure and thinking if use clojure.data.xml will be a powerful choice
they are both markup languages but in general you should not expect to be able to parse html with an xml lib
I thought the relationship was that XML and HTML had a common ancestor of SGML, but diverge from there
I seem to remember there being a variant called XHTML that was supposed to be XML-compliant HTML, but I don’t think it ever went anywhere.
I think that the options are:
(mylib/render ctx data)
;; 1 => "<html>string</html>" ;; bad :(
;; 2 => [:html "hiccup-like"] ;; meh
;; 3 => #clojure.data.xml.Element{:tag :html :content "will be useful?"} ;; ??
;; 4 => #object["something like j2html representation"]
;; 5 - comments
there was
Looking for https://developer.mozilla.org/en-US/docs/Glossary/XHTML
Should be possible (and useful) to write a XHTML
=xml/parse=> clojure.data.xml
=custom-emit=> HTML
Any reason why you don’t like hiccup syntax? To me it seems a lot more succinct.
hiccup is nice to write/type, but i don't think that it's a good programmatic representation
You mean like it lacks something? Or it’s just too easy? 🙂
if you are manipulating it (creating it, but taking it and changing it) you constantly have to be checking if the second thing in a vector is a map or not
True. Would XHTML be better for that?
even though it is represented as data, it is a data format that is geared towards humans reading and writing it
it depends, xhtml is a serialization format, and you won't be directly manipulating that
I’m asking mostly out of idle curiosity, I don’t have a stake one way or another, but I’ve always found hiccup the easiest HTML-adjacent syntax to work with, so I’m surprised and interested in hearing about situations where it is arguably less than ideal.
it works very well if you are sort of top down building a page from fragments, it works worse if you then take that page and want to change some nested thing it
there is also hickory that converts between hiccup style and data.xml style . I have used it for small things in past for editing html
Ok, so working with {:tag :div :attrs {:foo 1}}
kind of stuff as opposed to [:div {:foo 1}]
the biggest downside to programmatic use of hiccup is probably that it's at least partially positional
if I’m remembering data.xml style right
positional stuff tends to be more compact and easier for people (b/c it's implicit) but harder for programs (b/c it's implicit) - usually maps are better there
also see ... spec :)
i thought much of the programmatic pain was alleviated by first normalizing any hiccup data before manipulating it?
I wrote a simple function that takes a vector of args and breaks it into opts
and children
based on whether or not the first value was a map. That made it pretty easy for me to work with hiccup for the use cases I was concerned with.
(let [normalize-hiccup (fn normalize-hiccup [[tag & [attrs :as vs] :as element]]
(let [has-attrs? (map? attrs)
v {:tag tag
:attrs (when has-attrs?
attrs)
:children (map normalize-hiccup (if has-attrs?
(rest vs)
vs))}]
(reify
ISeq
(first [this]
tag)
ILookup
(valAt [this key]
(key v))
(valAt [this key not-found]
(key v not-found))
Indexed
(nth [this i]
(nth element i))
(nth [this i not-found]
(nth element i not-found)))))
hiccup (normalize-hiccup [:div {:foo 42}
[:div {}]])]
{:as-hiccup (nth hiccup 1)
:as-map (:attrs hiccup)})
Just for funI thought hiccup already provided this, https://github.com/weavejester/hiccup/blob/abc97943ee0fb72e5c94f8fac170be5535f9f2d4/src/hiccup/compiler.clj#L110
though that was more for generating hiccup than manipulating it, now I think of it.
but it seems like it wouldn’t be too hard to build on that to convert hiccup to data.xml
-ish maps.