This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-27
Channels
- # arachne (1)
- # beginners (31)
- # boot (84)
- # cider (9)
- # clara (2)
- # cljs-dev (102)
- # cljsrn (20)
- # clojure (254)
- # clojure-belgium (1)
- # clojure-dusseldorf (17)
- # clojure-greece (7)
- # clojure-italy (6)
- # clojure-russia (2)
- # clojure-spec (8)
- # clojure-uk (9)
- # clojurescript (93)
- # component (4)
- # copenhagen-clojurians (1)
- # cursive (24)
- # datomic (22)
- # editors (1)
- # emacs (8)
- # garden (2)
- # hoplon (357)
- # lein-figwheel (1)
- # leiningen (4)
- # luminus (27)
- # mount (13)
- # off-topic (7)
- # om (71)
- # onyx (35)
- # planck (3)
- # re-frame (53)
- # reagent (35)
- # ring-swagger (24)
- # specter (10)
- # sql (6)
- # untangled (47)
- # vim (157)
@jumblerg @onetom thoroughly enjoying hoplon/ui so far. I'm struggling to figure out how to reset! a form's fields after sumitting though.
(ui/form :sh (r 1 1) :sv (r 1 20)
:submit
(fn [data]
(save data))
(ui/text :key :message
:val (cell= (:message ui/*data*)))
(ui/submit :sh 100 :sv (r 1 1) :b 1 :bc :black
:c light-grey :f 20 :ft :bold :label
"send"))
is there a way i can (reset! ui/*data*
to nil from the :submit function? I might not be fully grasping binding here@jjttjj: glad to hear it! form implementations are incomplete though, hence the doomesday warnings.
the code there now is pretty ad-hoc, minimal thing designed to get me through a particular project.
@jumblerg: gotcha, i'll see if i can do my own thing for now for the form stuff, thanks!
@jumblerg I was trying to do that but ui/*data*
seems to evaluate to nil, not a cell, within the :submit function of the form (which didn't seem right)
i have a much better form implementation on my local machine, but it has certain deps i'm not ready to merge in yet.
cool, my thing is simple enough that it shouldn't be hard to do a quick workaround, just wasn't sure if i was missing something obvious
i can't recall which implementation is on master atm, too many branches, is data a cell or atom there?
@jjttjj we are also inlining the bindings what the ui/form
macro would do and hence we have access to ui/*data*
i rolled this macro as a convenience for editing existing data but it doesn't solve all our needs either:
(defmacro form-with
"Create form with initial data provided"
[{:keys [data]} & args]
`(let [initial-form-data# ~data
changed-form-data# (javelin.core/cell nil)]
(binding [hoplon.ui/*data* (javelin.core/cell=
(merge initial-form-data# changed-form-data#)
#(reset! changed-form-data# %))
hoplon.ui/*error* (atom nil)
hoplon.ui/*submit* (atom nil)]
(hoplon.ui/form* ~@args))))
i think the key to successful usage is to feel free to modify / extend what's already there. don't try to constrain yourself to the official version; fork it, experiment and pull-request 🙂
this is our build pipeline for example which reloads our frontend when the hoplon/ui
library changes:
(comp
(watch)
(speak)
(checkout :dependencies '[[hoplon/ui "0.0.1-SNAPSHOT"]])
(environ)
(hoplon)
(reload)
(cljs-devtools)
(cljs)
(from-cljsjs :profile :development)
(serve))
then in parallel im running a boot watch build-jar
process in the directory of our fork and our branch (https://github.com/addplus/ui/tree/addplus), so i can deploy our experimental additions and changes.
this way i can just very concisely add new components to src/hoplon/ui.cljs
, where everything is already :require
d.
thanks, that's better than my method of manually restarting things every time i build a jar haha. And I'm definitely going to experiment with ui a bunch going forward. I love it already compared to using css frameworks.
this way it takes around 3-4seconds to see a hoplon/ui change within our app on a 2.7 GHz Intel Core i5. on a more modern i7 you can expect 1.5-2.5s
Back at it today using hoplon.svg, and I’m having difficulty setting a class attribute on SVG elements. Anybody aware of any reason that (svg/circle :class “foo” …) wouldn’t result in a circle element having a class attribute on it? I’m very new to Hoplon so I may be doing something really dumb...
@keithsparkjoy you need to use my fix from yesterday for all the attributes, since the svg elements are created with namespaces
:svg/class “foo”
works
but it doesnt work for vectors or hashmaps, I just realized ill fix that in my PR
Ahh okay I thought class in SVG was the same as class in HTML. Makes sense.
it is but it’s how the JS element is constructed is different
all the attributes defined in: https://www.w3.org/TR/SVG/attindex.html will need the :svg/*
fix
since they are related to how the svg elements are constructed with the namespace
if you need other namespaces like xlink and xml, :xlink/* :xml/*
I have a PR for that
The typical suspects on circle, for example (cx, cy, r) work fine without the svg prefix
I added the svg namespace fix and indeed that did emit the class attribute on my svg element
I wonder why they are different...
It has to be a namespace conflict since thats the only difference between the :svg/*
attributes and the regular ones
ah good old stack overflow: http://stackoverflow.com/questions/31056625/when-is-an-xmlns-declaration-in-html5-really-necessary
you need an extra declaration probably
Interesting. I was under the impression in HTML5 that HTML was implicitly namespace aware - e.g. you don’t have to annotate the <svg> element with an xmlns element.
"HTML is also namespace aware, but namespaces are assigned implicitly. HTML is converted to a DOM using an HTML parser, which knows which elements go in which namespace. That is, it knows that <div> goes in the http://www.w3.org/1999/xhtml namespace and that <svg> goes in the http://www.w3.org/2000/svg namespace. Elements like <script> can go in either the http://www.w3.org/1999/xhtml or the http://www.w3.org/2000/svg namespace depending on the context in which they appear in the HTML code."
http://stackoverflow.com/questions/23319537/html-5-inline-svg-and-namespace-awareness-for-svg-dom
This is all very confusing - hehe - even for a guy who knows a little about XML and namespaces and such.
@keithsparkjoy there is a comment on SO about that being incorrect, it seems the default ns wont be included for an element created explicitly with createElementNs
Ahh gotcha
…and in Hoplon we’re talking about creating things dynamically.
right so each elements is really explicitly created in js
which for the regular elements is no problem
since they are created with createElement
This needs to be documented in the wiki for sure
I assume thats why the mozilla example for createElementNs
includes the html ns and the xul ns
Man I’d have been really screwed without that fix - thanks again for figuring that out yesterday 🙂
no problem, I havnt been working in clojure mush the past 2 weeks and my brain is literally exploding so it was a good little side thing to work out
life instantly gets harder without clojure
Or at least less fun 🙂
I wonder if we should change the the regular attributes to explicitly use the default namespace
no nvm
@flyboarder I fear we may have figured out how to get Hoplon to emit a class attribute on an svg element, but the browser isn’t recognizing and acting on it. I tried a jsfiddle to see what namespace the class attribute is in for a simple working example, and it’s null: https://jsfiddle.net/qcad0q7w/
This is really testing my knowledge of namespaces, but if I recall correctly, a default namespace on an element says nothing about the namespace of the attributes. IOW unless you explicitly specify a namespace for an attribute, they are not in any namespace. This makes sense for the class attribute - it’s not supposed to be in any namespace. The xlink:href example earlier was how we explicitly put a namespace on an attribute, but I don’t think we can apply that same technique to the class attribute.
Indeed my repro example works if you set the namespace to nil
(defmethod hoplon.core/do! :svg/* [elem kw val] (let [svgns "http://www.w3.org/2000/svg"] (.setAttributeNS elem nil (name kw) val)))
Right since that is changing the namespace of the attribute
When an element is created with the SVG namespace that is now the default namespace
for elements - not attributes
attributes are different
They are in no namespace by default, IIRC
So I think we went too far trying to put the class attribute in the svg namespace
(defmethod hoplon.core/do! :svg/*
[elem kw val]
(.setAttributeNS elem (namespace kw) (name kw) val))
@micha that would still need the declarations of the namespaces in HTML tho?
Otherwise you are only using the prefix
(Namespace kw) is SVG which isn't a namespace in xml
Hmm. I don’t think we should be using setAttributeNS for attributes in general. Sure xlink:href is special because it’s explicitly namespaced, but I don’t think attributes normally have namespaces. Certainly what I’ve verified with my jsfiddle is that class has no namespace (the class attribute, that is). Even in SVG.
(defmethod hoplon.core/do! :svg/*
[elem kw val]
(let [svgns ""]
(.setAttributeNS elem svgns (name kw) val)))
Right that does emit a class attribute
but it doesn’t work properly in the browser
The element doesn’t get styled by the class
because the browser isn’t expecting class to be in a namespace
check this out: https://jsfiddle.net/qcad0q7w/
The problem is that things created with createElementNs
do not have the default ns, when you create something with setAttributeNs($Null …)
the browser uses the default again, this doesnt affect the default attributes tho
Right, sadly Hoplon won’t emit :class on an svg/ element
yea that was my original problem
right so the solution is still the correct one, to set an attribute on an svg element you need to specify the namespace
either null which will then use the browser default or the svg class or xhtml class
using setAttribute
on an svg element created with createElementNs
will fail because it doesnt know which namespace to get it from
really?
attributes are normally in no namespace
yes because the browser document doesnt know about the default ns on the svg element
that what I suggested earlier but there are problems with doing that in regular documents then
when the elements dont have explicit namespaces
the namespaces in static html read by browser parser are not the same as the ones in javascript
@micha i think actually using null would work but not until we merge the jquery split
since right now we are using .attr js/jquery
but using the jquery PR requires a PR on boot-hoplon also
no very necessary to keep backwards compat, otherwise you need to add hoplon.jquery to your page declaration
that wont work since do! is in core
and hoplon.jquery requires do!
for the attributes
it’s an all or nothing deal 😞 but better once done, I think we need to make clear that the stable version of next hoplon will need boot-hoplon 0.3.0
feel free to audit the PR’s for anything you thing we should adjust first, but looking at the changes is pretty easy
sounds good
@flyboarder one thing we could do is make jquery the default
currently it is
yeah, it’s all documented in the boot-hoplon pr
I exposed a :require option
which if empty auto uses hoplon.jquery
the jquery/goog options just fill it
but the :require options does need the namespace to exist in clojure to pass the macro? check, I dont know how to fix that
yeah I wasnt sure if it was safe to just ignore the missing namespace at that point
or provide another :require-cljs option to include a different set later
figured you would have some fix 😛
on second thought I dont think using setAttributeNs by default is a good thing to change, that could lead to unexpected behaviour if the user sets a default namespace in their document
@flyboarder If the user sets a default namespace on their document, how does that impact attributes?
It’s been awhile so I reread the bit in Xml Namespaces that talks about default namespaces: https://www.w3.org/TR/xml-names/
“A default namespace declaration applies to all unprefixed element names within its scope. Default namespace declarations do not apply directly to attribute names; the interpretation of unprefixed attributes is determined by the element on which they appear."
…and then in the following paragraph, “The namespace name for an unprefixed attribute name always has no value."
@keithsparkjoy: Right but what is the namespace name on something created from JavaScript with a namespace, since attributes get their namespace from the element the default namespace should be that of the element, this seems to be where we start needing to specify the namespace on the attributes
I think that’s where I’m confused, because attributes normally have no namespace. I think it’s a common misperception that they are in the element’s namespace...
For example
But your quote says they are interpreted from the element which they appear
Logically they are interpreted
Which in the SVG case has an explicit namespace
but as far as xml is concerned, they have no value for their namespaceURI
SVG has a namespace for its elements
but the attributes are not in any namespace.
Right and it's attributes get the namespace from the element as per your quote
Well, technically they are in the “empty” namespace I guess.
Take an SVG element, for instance. Say, <circle cx=“10”/>
if you ask the DOM the namespace for circle, you’ll get the SVG namespace
if you ask the DOM the namespace for cx, you’ll get null
xlink:href is different, because there’s an explicit namespace there.
Right but a non prefix is empty namespace so it is using the namespace of the element
Can you clarify what you mean by “non prefix”? Are you saying a non-prefixed attribute somehow inherits the namespace of the element in which it resides?
Exactly which is what your quote says
Nope reread it
This is a common misperception about XML
the interpretation of unprefixed attributes is determined by the element on which they appear.
“Default namespace declarations do not apply directly to attribute names; the interpretation of unprefixed attributes is determined by the element on which they appear."
Right.
Right the only namespace available to the SVG element is the SVG namespace
Therefor the SVG attributes get that namespace
We’re comparing apples and oranges
The DOM is one thing - how you interpret it is another
But that’s pretty rare
Correct. And that is obvious and easy.
What isn’t so obvious to people is how non-prefixed attributes behave
non-prefixed attributes do NOT inherit any namespace from anywhere in the DOM.
They don’t get a default namespace
They have an empty namespace - it’s null
the user agent
interprets it
the DOM returns NULL
go try it
my jsfiddle from earlier demonstrates that
This was a key learning for me years ago when I was learning XML
Well there’s a spec for SVG, for example.
And they tell you how to use some attributes, say viewBox.
like the svg element implementation that is provided by the user agent interprets it in a way that might be specific to that user agent?
The SVG spec defines how viewBox is to be used
in the context of some SVG elements
viewBox is an attribute
and it has no namespace
but we all know what it means when we see it in an SVG frag
because the spec tells us
I hope all user agents interpret it the same way hehe
they should
according to the SVG spec
but when you program against the DOM you’ll find viewBox has no namespace
because it’s an attribute
But the contextual interpretation is done by the browser differently than when set with JavaScript, if I create an element and explicitly set s namespace there is no interpretation of default document ns
So attributes with blank ns don't know what to do
Which is what happens when you set an attribute usually since setAttribute uses blank ns
and that’s exactly what you want
a blank namespace for attributes
unless… one is specifically provided
like xlink:href
SetAttributeNs with a null ns is different
How is it different?
Well that's why it fails lol
It doesn't have a namespace to get the attribute from the element was created with a custom ns outside of the document
It’s very rare for an attribute to have a namespace
Right but not in the case where there is no default
Let me go hack up a jsfiddle that we can experiment with because we’re going in circles 🙂
Make sure your creating the elements from JS not HTML
I would assume that both createElement and setAttribute use interpretation to get the ns which is why the regular attributes fail, it cant interpret what a blank namespace means on something that has an explicit namespace and no default, so it fails
Right.
I’m working on one that creates the DOM elements dynamically for @flyboarder
been a long time hehe
If you create the element in HTML it has an implicit namespace
Right @micha attributes have null namespaces in the DOM
normally
Yea, this is kind of a mind fuck
believe me I felt it
totally
attributes don’t usually have any namespace
it actually is pretty simple, just not super intuitive since you’re used to how default namespaces work on elements
there is a case in SVG
where you actually do need a namespaced attribute
xlink:href
and Hoplon wasn’t liking that much
The problem is really only the default attributes once an element has an explicit ns, setAttribute can't handle the implicit namespace anymore
@flyboarder did you check out my fiddle?
curious if it does what you’d expect it to
Yes it does
So the SVG element has a namespace
and when I add the “viewBox” attribute
it ends up in there with no namespace
which is correct
Right so it gets the ns implicitly from the element
logically - the DOM doesn’t express this though
I mean how you interpret viewBox is because you know it’s SVG
but if you ask the DOM the namespaceURI of viewBox it’s null.
Right but that isn't the same as creating an attribute with a namespace of null
Sure it is.
It’s exactly the same.
I’ll go update my fiddle.
If you create an element with an SVG ns and then create an SVG attribute with a null ns it will fail won't it
nope - I think we’re honing in on where you and I are miscommunicating, fly
totally, Micha
@keithsparkjoy: for sure man, don't mean to be a pain ;)
right we need to be able to do the normal stuff like viewBox, but also the weird stuff like xlink:href
So is the solution to always set the ns as null then and not use setAttribute but setAttributeNs
no namespace
@flyboarder I think the two are the same
But they can't be because then the regular attributes wouldn't fail
Are you sure the failure was at setAttribute?
or could it have failed earlier?
The only thing we have done is specify a namespace
BTW guys one other thing - XML is totally case sensitive
…and viewBox gets crushed to viewbox.
along with all the other mixed-case svg attrnames
…which is why I’ve been using viewBox as an example so I don’t forget to mention that 🙂
Omg I think I know why we are having different views on this, I'm using the jquery split builds
So vanilla JS instead of jquery attr
Jquery attr causes problems
Might this go away with latest master build then?
I hope all this is helpful - sorry to be taking so much of your time guys
@keithsparkjoy: can you try building from master?
Hmm. Is that an easy dep change in my build.boot or something?
Sorry I’m kinda new to all of this.
If setAttribute is the same as setAttributeNs then this has already been solved by removing jquery from core
With a null ns obviously
@micha: can you push a snapshot?
For @keithsparkjoy to try
I think it's the difference in versions causing my confusion, I forgot I'm not on the regular hoplon builds
No worries man
BTW if you want a much better explanation, read Essential XML. It’s a quick read and the chapter on namespaces is worth the price of the book.
I used to work with those guys in a prior life 🙂
Oh man it’s getting slammed over on Amazon. Hehe. Oh well, the namespaces chapter is still the best explanation I’ve seen 🙂
@keithsparkjoy: I totally get what you mean by not needing the SVG ns on attributes now
@flyboarder i fixed the issues with the new thing
What is different? Sorry I'm on mobile right now
Why don't the ones in core work with jquery? My thought was that while jquery is deprecated if you wanted other attribute providers it would be specified in the boot task