attribute matching inside at-form

[juhofriman]

Hi,

I don't know if this is a bug or by design, but this one caused me some weirdness so I decided to write a brief report on this. If this is by design, just close this issue please :)

If given html contains attribute already, it looks like attr= is matched as string directly.

; Following does not match because (not (= 1 "1"))
user=> (sniptest "<div dummy=\"1\"></div>" [(attr= :dummy 1)] (content "matching"))
"<div dummy=\"1\"></div>"

; Following naturally matches
user=> (sniptest "<div dummy=\"1\"></div>" [(attr= :dummy "1")] (content "matching"))
"<div dummy=\"1\">matching</div>"

But if attribute is set inside transformation it retains type information during transformation.

; Setting dummy="1" (as number!) inside transformation and refering to it as number
user=> (sniptest "<div dummy=\"1\"></div>" [:div] (set-attr :dummy 1) [(attr= :dummy 1)] (content "matching"))
"<div dummy=\"1\">matching</div>"

; But if it is referenced as string, it of course does not match
user=> (sniptest "<div dummy=\"1\"></div>" [:div] (set-attr :dummy 1) [(attr= :dummy "1")] (content "matching"))
"<div dummy=\"1\"></div>"

Bottom line is that setting an attribute as number effectively creates dummy="1" which is then again read as a string. I think this in an inconsistency but I do acknowledge this can be by design as well.

Because attributes in xml do not really have type information I would suggest that matching would always be done as arguments interpreted as strings. But I really don't know all the details. If this is an inconsistency I can even try to put on a pull request.

Loving enlive and using it daily! :)

[cgrand]

Not by design, more like undefined behavior. `set-attr` should definitely serialize.

…

On Mon, Feb 6, 2017 at 4:29 PM, Juho Friman ***@***.***> wrote: Hi, I don't know if this is a bug or by design, but this one caused me some weirdness so I decided to write a brief report on this. If this is by design, just close this issue please :) If given html contains attribute already, it looks like attr= is matched as string directly. ; Following does not match because (not (= 1 "1")) user=> (sniptest "<div dummy=\"1\"></div>" [(attr= :dummy 1)] (content "matching"))"<div dummy=\"1\"></div>" ; Following naturally matches user=> (sniptest "<div dummy=\"1\"></div>" [(attr= :dummy "1")] (content "matching"))"<div dummy=\"1\">matching</div>" But if attribute is set inside transformation it retains type information during transformation. ; Setting dummy="1" (as number!) inside transformation and refering to it as number user=> (sniptest "<div dummy=\"1\"></div>" [:div] (set-attr :dummy 1) [(attr= :dummy 1)] (content "matching"))"<div dummy=\"1\">matching</div>" ; But if it is referenced as string, it of course does not match user=> (sniptest "<div dummy=\"1\"></div>" [:div] (set-attr :dummy 1) [(attr= :dummy "1")] (content "matching"))"<div dummy=\"1\"></div>" Bottom line is that setting an attribute as number effectively creates dummy="1" which is then again read as a string. I think this in an inconsistency but I do acknowledge this can be by design as well. Because attributes in xml do not really have type information I would suggest that matching would always be done as arguments interpreted as strings. But I really don't know all the details. If this is an inconsistency I can even try to put on a pull request. Loving enlive and using it daily! :) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#142>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3scQci5lcpUxithR832SNmEGkOOj3ks5rZzxogaJpZM4L4VYN> .

-- On Clojure http://clj-me.cgrand.net/ Clojure Programming http://clojurebook.com Training, Consulting & Contracting http://lambdanext.eu/