plumatic / dommy Goto Github PK

Was looking for the companion to listen! just now and didn't find it. I'd be happy to write something up if you'd be interested in including that in dommy.

When I change the value of an input field the value returned is the original value, not the new value. For example running the js below returns the new value:

document.getElementById("test").value

But the cljs code below returns the old value:

(dommy/attr (sel1 :#test) :value)

Is there something I need to do to refresh it, or am I misunderstanding something?

We are attaching click handler events but for some reason on older android 4.0 stock browsers they do not seem to attach properly.

On Android 4.1 and higher everything is working fine:

(dommy/listen! elem type callback)

any thoughts or testing/compatibility info for these versions of android?

Yes old versions of android have crufty browser engines!

I'm wondering if deftemplate should explicitly reference the non-compiled version of node, and a sibling macro created defctemplate that explicitly references the compiled version of node. Perhaps these two macros could be put in a separate file?
Right now you can't use deftemplate with the compiled and non-compiled versions of node, which seems like a shortcoming.

When I try to compile cljs with Clojure 1.7, I see a bunch of warnings like this:

WARNING: Use of undeclared Var dommy.template/->node-like at line 37 file:/Users/sritchie/.m2/repository/prismatic/dommy/0.1.3/dommy-0.1.3.jar!/dommy/attrs.cljs

I'm guessing that requiring dommy.template in that namespace will fix this up.

Hi,
is there any one (two) -way binding?
Thanks.

I tried something like:

(defn- mk-node []
  (node [:p.flash " "])

then

(replace! (sel1 :body) (mk-node))

I see a literal " " rather than a space. Same with • or ©, etc, etc.

Principal-of-least-surprise suggests those should actually render properly, but I'm okay with there being some other way to do this.

(set-html! (sel1. :.flash) "message • here")

works just fine. However, using set-text! seems to quote the character entities. Might the node macro need to treat that text as HTML or something?

Hello, Aria,

Can you please tell what is the proper way of adding the "disabled" attribute to a button via dommy.template/node. E.g. how to build ?

Thank you!

In the README file the following example is given:

(dommy/append! (sel1 :#todos) [:.todo "Eat some cake"])

This doesn't work since append! expects a DOM Node:

Uncaught TypeError: Failed to execute 'appendChild' on 'Node': parameter 1 is not of type 'Node'.

Either the documentation should be fixed or append! should accept hiccup-like markup.

listen-chan! could either set up a listen that writes to a provided channel, or create the channel itself. The latter is more convenient in the usual case, the former is more desirable in the general case.

I have no idea whose fault this is, but I want to file the ticket so it's at least known. Whenever I have polymer enabled in Chrome, (dommy/append! (sel1 :body) "foo") fails, with the following error:

"Don't know how to make node from: #<[object HTMLBodyElement]>"

If I use (sel1 :#mybod) (or some other way to get the body), it works.

Maybe Polymer somehow changes the semantics of "document.body"?

To be specific, I'm only including Polymer's platform/platform.js in order to get this behavior.

Is there any way to do delegated event handling, a la jQuery .live(), in Dommy? I looked through core.cljs, and live-listener, from the name, looked like it, but my reading of the source suggests that isn't the case.

An unrelated frustration, probably deserving an issue of its own, is the absence of tagged releases. It means I can't go back to v0.1.2 on Github, which my team uses, and look up the implementation of, say, live-listener, for the specific version.

Custom Elements is a new w3c specification that introduces a new API to create DOM element: document.createElement(localName, typeExtension). This API reflects a new html syntax <button is="my-button"></button> where button would be the localName and my-button the typeExtension.

The equivalent hiccup syntax [:button {:is "my-button"}] should generate the proper DOM call when used with dommy to support this spec as setting is as an attribute (current behavior) has no effect.

Query selectors must use css syntax, which means things like semicolons and backslashes need a backslash to precede them.

Example where this causes failure:

(sel "#:0.inp")

This will produce a SYNTAX_ERR (== DOM Exception 12). The crazy-looking ":0.inp" is the typical format of ids produced by goog.ui.Component/makeId which are regularly inserted into id attributes of dom elements (which is how it bit me).

An at least partial fix is to use an escaping function like this (cljs):

(def requires-css-escaping #"(?:^[^a-zA-Z]|[\u0000-\u002c\u002e\u002f\u003a-\u0040\u005b-\u005e\u0060\u007b-\u009f])")
(defn escape-css-char [c] (str \\ (.. c (charCodeAt 0) (toString 16)) \space))

(defn css-escape [s] (clojure.string/replace s requires-css-escaping escape-css-char))

And then patch dommy.core/selector:

(defn selector [data]
  (cond
   (coll? data) (clojure.string/join " " (map selector data))
   (string? data) (name data)
   (keyword? data) (if-let [prefix (some #{\# \.} (aget (name data) 0))]
                             (str prefix (css-escape (subs (name data) 1))
                             (css-escape (name data)))

I think dommy.macros/selector will need a similar transformation.

However you can only safely use this on keywords since strings may use css characters for their intended meaning. This argues for making "css-escape" or "selector-escape" a public function users can use.

Previously, with Clojurescript r1853, the following worked:

(listen! js/window :load f)

However as of 1909 (and maybe before) this fails because js/window does not implement the INamed interface:

Doesn't support name: [Object object]

This is as much as I can tell based on a reading of the diff between the two revisions.

Hello. Naturally things are continually shifting when using a stack consisting almost entirely of pre-release software... but it would be helpful to have a few words here (or better yet, in the README) about what version(s) of CLJS Dommy is believed to work with.

Can you please add the following macro.

(defmacro defnode [name data]
  `(def ~name
     (node ~data)))

It seems that naming these files core_macros and template_macros would be more suitable. Your thoughts?

Just a minor issue:

(set-class! elem class)

should return the element to allow for proper threading, currently it returns the name of class

Would it be possible to do tagged releases, to make navigation of the source code on Github easier? #90

Because it sets the style display to blank, which effectively means revert to original.

This is what zepto does, so is arguably not a bug.

Right now, to select multiple classes, you have to do the following:

(sel ".c1, .c2")

This is fine as a fallback, but selectors should be composable like they are in enlive:

(sel #{:.c1 :.c2})

For more detail, see http://enlive.cgrand.net/syntax.html

Release 0.1.2 is pretty old and there are a number of important fixes in master.
Any plan to cut a release soon?

Is IE8 intended to be supported?

In IE8, js/Document doesn't exist (it uses js/HTMLDocument instead).
Also things like js/SVGElement don't exist, which causes extend-protocol to throw a null pointer exception.
The fix to #28 probably exacerbated this.

Would you be interested in a patch to test for the existence of some of these types before attempting to extend them?

Hello,

I am trying to do this:

(dommy-attr/set-style! el :padding-top "-3px")

but it doesn't take the negative value, it works only for positive ones, tried as well with margin-top and it worked, so I switched to margin, just wanted to report this behaviour

id's or classes that have a / character aren't processed. (This is usually caused in clojure by accidentally using name as a generic keyword-to-string function.)

Note this is a legal character in html5: http://www.w3.org/html/wg/drafts/html/master/dom.html#the-id-attribute

I'm assuming not all characters can easily be supported, but perhaps this is an easy fix.

A solution would be something a function like (subs (str :abc) 1), but there may be something better.

I'm stumbling across this when I am taking HTML generated by existing code and run it through template/node. Input like [... {:style "background-color: lime"} ...] leads to an exception along the lines of name not supported, because attr/style-str assumes that its input is always a map.

If it's ok with you I can provide a pull request that changes style-str to return its argument unchanged if it is a string.

I just figured out that a really subtle/annoying svg-related bug I was experiencing was actually fixed in 0.1.2. Maybe you can go ahead and update the readme to reflect this new version?

Probably has relation to this:
http://stackoverflow.com/questions/12272288/how-can-i-get-firefox-to-set-style-attributes-using-styleattribute-name

E.g.
document.getElementById("firefoxDiv").style['backgroundColor'] = "Red";
vs
document.getElementById("firefoxDiv").style.setProperty('background-color', 'red');
in Firefox

This is literally my first hour with Clojure*, so I could be doing something stupid, but if I add (:require [dommy.core :as dommy]), I get the following JavaScript error during build: "PersistentArrayMap.fromArray is not a function". This prevents me from testing out dommy/listen! .

I am using lein-cljsbuild 0.3.2, which uses ClojureScript 0.0-1806.

I am able to use the sel and sel1 macros without any issue so far, as long as I leave out that :require.

Hi,

I was updating from 0.0.2 to 0.1.0 and noticed some breakage related to the deftemplate macro and inline styles. The compile-add-attr! macro refers to dommy.core/style-str, which leads to:

Uncaught TypeError: Cannot read property 'style_str' of undefined
if(cljs.core.truth_(cljs.core.ObjMap.fromObject(["\ufdd0'width"], {"\ufdd0'width":"100%"}))) {
        dom3877.setAttribute("style", dommy.core.style_str.call(null, cljs.core.ObjMap.fromObject(["\ufdd0'width"], {"\ufdd0'width":"100%"})))

Workaround for this is to require dommy.core somewhere in your application manually. Shouldn't the deftemplate macro work independently, though?

Could you upload 0.1.1 or 0.1.1-SNAPSHOT to Clojars?

Using the latest version of clojurescript, I get alot of warnings similar to this:

WARNING: Use of undeclared Var dommy.template/->node-like at line 234 file:/Users/skinney/.m2/repository/prismatic/dommy/0.1.3/dommy-0.1.3.jar!/dommy/attrs.cljs

Refer to #72

Some valid ids (e.g. containing .) are not recognized by sel.

According to html 4 spec : and . are valid id character. html 5 relaxes that to any unicode character.

Just started playing with this library, and crate was downloaded. I'm on Leinengin 2. Is that suppose to happen?

Hi,

looking at HTML/DOM libraries I have come across dommy and domina, both of which seem to have similar scopes of application. Is there a reason why they are different projects?

Hey guys,

Currently (count (children (dommy/sel1 :body))) throws [object HTMLCollection] is not ISeqable. Is there an easy way to make it so that it is ISeqable?

Cheers!

Can this framework convert html to hiccup?

Would it be possible to setup a help site, with examples, and detailed description of API functionality? I'd be happy to contribute to that, given the framework for it. I've only been writing Clojure/ClojureScript for about a week now, so I don't know if it's typical in the Clojure community to read the source code when you're getting started with a lib 😄

Your definition

(def +svg-tags+ #{"svg" "line" })

does not include most of the svg tags.

The next definition completes the set.

(def +svg-tags+ #{"svg" "g" "rect" "circle" "clipPath" "path" "line" "polygon" "polyline" "text" "textPath"})

And that's all !!

Thanks,

Juan Manuel

Is there a list or matrix anywhere showing which browsers dommy does and does not support, and which features it supports on which browsers (and, more importantly, which it does not)?

I just started using dommy the other day, and the first thing I tried to do was use it to detect when a button was pressed and append text somewhere on the page. The problem is, dommy doesn't appear to listen for click events, or at least call the handler for it. My site.cljs looks like this:
(ns site
(:require
[dommy.utils :as utils]
[dommy.core :as dommy])
(:use-macros
[dommy.macros :only [node sel sel1]]))
(defn test [](dommy/append! %28sel1 :#topbar%29 %28node [:p "test"])))
(dommy/listen! (sel1 :#Home) :click test)

And my html file looks like this:
http://pastebin.com/7718eTGV
When I click on the home button, the word test should be added to the

Is this a bug, or simply user error?

Wondering if it would be better to use Google Closures Events for the listenors which has good cross-browser support.

-See here
https://developers.google.com/closure/library/docs/events_tutorial

Predicates should have a ^boolean type hint so that they can be properly optimized by the ClojureScript compiler.

There is a way to listen for a key{press-down-up} ?

I haven't found it...

(dommy/listen! js/window :load (fn [_] (println "meow")))

That works fine up to :simple optimizations, but breaks once you go higher. I've found that the issue also happens when selecting the body as well.

(dommy/listen! (sel1 :body) :load (fn [_] (println "meow")))

So far, I haven't found anything in dommy that works, with :advanced, for listening to onload. As a replacement, I've been using a more primitive approach.

(aset js/window "onload" (fn [_] (println "meow")))

Once this has been setup, all other dommy calls I'm making seem to work just fine. The indication here, I gather, is that the issue is with :load listening.

Why is the following not possible?

[[:div#first "first"]
 [:div#second "second"]]