Fork me on GitHub
#hoplon
<
2016-09-27
>
jjttjj15:09:59

@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

jumblerg16:09:10

@jjttjj: glad to hear it! form implementations are incomplete though, hence the doomesday warnings.

jumblerg16:09:50

the code there now is pretty ad-hoc, minimal thing designed to get me through a particular project.

jjttjj16:09:55

@jumblerg: gotcha, i'll see if i can do my own thing for now for the form stuff, thanks!

jumblerg16:09:20

if you blow away ui/data on submit, that should clear the form

jjttjj16:09:52

@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)

jumblerg16:09:25

i have a much better form implementation on my local machine, but it has certain deps i'm not ready to merge in yet.

jjttjj16:09:28

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

jumblerg16:09:46

i can't recall which implementation is on master atm, too many branches, is data a cell or atom there?

jjttjj16:09:53

it's a cell

jjttjj16:09:27

i'm currently using the addplus fork fwiw

jjttjj16:09:43

i think it's a cell in both though

jumblerg16:09:25

give me 10 mins, will follow up when behind my laptop

jjttjj16:09:16

cool, I appreciate it! no rush 🙂

onetom16:09:31

@jjttjj we are also inlining the bindings what the ui/form macro would do and hence we have access to ui/*data*

onetom16:09:43

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* [email protected]))))

jjttjj16:09:54

@onetom cool, thanks! playing with that a bit now

onetom16:09:03

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 🙂

onetom16:09:43

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))

onetom16:09:32

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.

onetom16:09:37

this way i can just very concisely add new components to src/hoplon/ui.cljs, where everything is already :required.

jjttjj16:09:41

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.

onetom16:09:54

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

onetom16:09:44

definitely a lot faster than a full restart 🙂

keithsparkjoy18:09:23

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...

flyboarder18:09:45

@keithsparkjoy you need to use my fix from yesterday for all the attributes, since the svg elements are created with namespaces

flyboarder18:09:04

:svg/class “foo” works

flyboarder18:09:33

but it doesnt work for vectors or hashmaps, I just realized ill fix that in my PR

keithsparkjoy18:09:46

Ahh okay I thought class in SVG was the same as class in HTML. Makes sense.

flyboarder18:09:04

it is but it’s how the JS element is constructed is different

flyboarder18:09:25

all the attributes defined in: https://www.w3.org/TR/SVG/attindex.html will need the :svg/* fix

flyboarder18:09:52

since they are related to how the svg elements are constructed with the namespace

flyboarder18:09:03

if you need other namespaces like xlink and xml, :xlink/* :xml/* I have a PR for that

keithsparkjoy18:09:47

The typical suspects on circle, for example (cx, cy, r) work fine without the svg prefix

keithsparkjoy18:09:36

I added the svg namespace fix and indeed that did emit the class attribute on my svg element

keithsparkjoy18:09:49

I wonder why they are different...

flyboarder18:09:46

It has to be a namespace conflict since thats the only difference between the :svg/* attributes and the regular ones

flyboarder18:09:21

you need an extra declaration probably

keithsparkjoy18:09:57

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.

keithsparkjoy18:09:07

"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."

keithsparkjoy18:09:29

This is all very confusing - hehe - even for a guy who knows a little about XML and namespaces and such.

flyboarder18:09:07

@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

keithsparkjoy18:09:03

…and in Hoplon we’re talking about creating things dynamically.

flyboarder18:09:18

right so each elements is really explicitly created in js

flyboarder18:09:36

which for the regular elements is no problem

flyboarder18:09:50

since they are created with createElement

flyboarder18:09:24

This needs to be documented in the wiki for sure

flyboarder18:09:09

I assume thats why the mozilla example for createElementNs includes the html ns and the xul ns

keithsparkjoy18:09:06

Man I’d have been really screwed without that fix - thanks again for figuring that out yesterday 🙂

flyboarder18:09:26

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

flyboarder18:09:57

life instantly gets harder without clojure

keithsparkjoy18:09:52

Or at least less fun 🙂

flyboarder18:09:35

I wonder if we should change the the regular attributes to explicitly use the default namespace

keithsparkjoy20:09:42

@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/

keithsparkjoy20:09:41

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.

keithsparkjoy20:09:49

Indeed my repro example works if you set the namespace to nil

keithsparkjoy20:09:00

(defmethod hoplon.core/do! :svg/* [elem kw val] (let [svgns "http://www.w3.org/2000/svg"] (.setAttributeNS elem nil (name kw) val)))

flyboarder20:09:35

Right since that is changing the namespace of the attribute

flyboarder20:09:30

When an element is created with the SVG namespace that is now the default namespace

keithsparkjoy20:09:40

for elements - not attributes

keithsparkjoy20:09:44

attributes are different

keithsparkjoy20:09:53

They are in no namespace by default, IIRC

micha20:09:03

i think you might want something like this:

keithsparkjoy20:09:10

So I think we went too far trying to put the class attribute in the svg namespace

micha20:09:41

(defmethod hoplon.core/do! :svg/*
 [elem kw val]
 (.setAttributeNS elem (namespace kw) (name kw) val))

flyboarder20:09:34

@micha that would still need the declarations of the namespaces in HTML tho?

micha20:09:40

i don't think so

micha20:09:49

not when you call setAttributeNS

flyboarder20:09:49

Otherwise you are only using the prefix

flyboarder20:09:25

(Namespace kw) is SVG which isn't a namespace in xml

micha20:09:38

var d = document.getElementById("d1"); 
d.setAttributeNS("", "align", "center");

keithsparkjoy20:09:15

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.

micha20:09:31

(defmethod hoplon.core/do! :svg/*
 [elem kw val]
 (let [svgns ""]
   (.setAttributeNS elem svgns (name kw) val)))

keithsparkjoy20:09:47

Right that does emit a class attribute

keithsparkjoy20:09:52

but it doesn’t work properly in the browser

keithsparkjoy20:09:59

The element doesn’t get styled by the class

keithsparkjoy20:09:10

because the browser isn’t expecting class to be in a namespace

micha20:09:35

(thingy :class "foo" :svg/omg 123)

micha20:09:47

^^ shows you can use :class with no namespace like that

flyboarder20:09:08

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

keithsparkjoy20:09:09

Right, sadly Hoplon won’t emit :class on an svg/ element

micha20:09:30

interesting

keithsparkjoy20:09:31

yea that was my original problem

micha20:09:49

do you have a repo i can clone?

micha20:09:57

it's some jquery bullshit i think

micha20:09:00

or something

flyboarder20:09:01

right so the solution is still the correct one, to set an attribute on an svg element you need to specify the namespace

flyboarder20:09:29

either null which will then use the browser default or the svg class or xhtml class

micha20:09:29

yeah the :svg/* stuff seems sound, no?

micha20:09:43

ah i see what you're saying now

flyboarder20:09:07

using setAttribute on an svg element created with createElementNs will fail because it doesnt know which namespace to get it from

keithsparkjoy20:09:32

attributes are normally in no namespace

micha20:09:34

but we can always use (.setAttributeNS elem null "class" "omg") right?

flyboarder20:09:45

yes because the browser document doesnt know about the default ns on the svg element

micha20:09:46

instead of regular setAttribute

flyboarder20:09:23

that what I suggested earlier but there are problems with doing that in regular documents then

flyboarder20:09:36

when the elements dont have explicit namespaces

flyboarder20:09:00

the namespaces in static html read by browser parser are not the same as the ones in javascript

flyboarder20:09:06

@micha i think actually using null would work but not until we merge the jquery split

micha20:09:11

the javascript world is probably saner

micha20:09:25

i say we merge that

flyboarder20:09:31

since right now we are using .attr js/jquery

micha20:09:44

we can merge it to master now

micha20:09:00

and adjust if we want to before next release

flyboarder20:09:23

but using the jquery PR requires a PR on boot-hoplon also

micha20:09:39

not necessarily though, right?

micha20:09:52

like we could have the jquery stuff still get pulled in

micha20:09:58

as the first step

flyboarder20:09:02

no very necessary to keep backwards compat, otherwise you need to add hoplon.jquery to your page declaration

micha20:09:18

we could add it to the :requires in hoplon.core at first

micha20:09:29

the separation of code is still valuable

flyboarder20:09:34

that wont work since do! is in core

micha20:09:42

i don't understand

flyboarder20:09:46

and hoplon.jquery requires do!

flyboarder20:09:51

for the attributes

micha20:09:53

oh i see right

micha20:09:20

circular dependencies

flyboarder20:09:28

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

micha20:09:50

yeah i think that's good

micha20:09:02

i say we merge both of them then

micha20:09:21

we don't need to push it to clojars yet

flyboarder20:09:44

feel free to audit the PR’s for anything you thing we should adjust first, but looking at the changes is pretty easy

micha20:09:57

ok i will merge them now

micha20:09:12

and we can change anything we want to change from there

micha20:09:32

@flyboarder one thing we could do is make jquery the default

flyboarder20:09:46

currently it is

micha20:09:52

that way if you do boot hoplon you get the same behavior as before?

flyboarder20:09:04

yeah, it’s all documented in the boot-hoplon pr

micha20:09:16

i was looking at the code i didn't see it

flyboarder20:09:21

I exposed a :require option

micha20:09:34

i see that, good idea

flyboarder20:09:35

which if empty auto uses hoplon.jquery

flyboarder20:09:52

the jquery/goog options just fill it

flyboarder20:09:26

but the :require options does need the namespace to exist in clojure to pass the macro? check, I dont know how to fix that

micha20:09:45

that seems like a bug in boot-hoplon stuff

micha20:09:52

which i can fix, hopefully

flyboarder20:09:18

yeah I wasnt sure if it was safe to just ignore the missing namespace at that point

flyboarder20:09:50

or provide another :require-cljs option to include a different set later

flyboarder20:09:10

figured you would have some fix 😛

flyboarder20:09:08

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

keithsparkjoy22:09:58

@flyboarder If the user sets a default namespace on their document, how does that impact attributes?

keithsparkjoy22:09:58

It’s been awhile so I reread the bit in Xml Namespaces that talks about default namespaces: https://www.w3.org/TR/xml-names/

keithsparkjoy22:09:06

“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."

keithsparkjoy22:09:20

…and then in the following paragraph, “The namespace name for an unprefixed attribute name always has no value."

flyboarder22:09:10

@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

keithsparkjoy22:09:49

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...

flyboarder22:09:20

But your quote says they are interpreted from the element which they appear

keithsparkjoy22:09:29

Logically they are interpreted

flyboarder22:09:38

Which in the SVG case has an explicit namespace

keithsparkjoy22:09:41

but as far as xml is concerned, they have no value for their namespaceURI

keithsparkjoy22:09:57

SVG has a namespace for its elements

keithsparkjoy22:09:08

but the attributes are not in any namespace.

flyboarder22:09:23

Right and it's attributes get the namespace from the element as per your quote

keithsparkjoy22:09:25

Well, technically they are in the “empty” namespace I guess.

keithsparkjoy22:09:56

Take an SVG element, for instance. Say, <circle cx=“10”/>

keithsparkjoy22:09:22

if you ask the DOM the namespace for circle, you’ll get the SVG namespace

keithsparkjoy22:09:30

if you ask the DOM the namespace for cx, you’ll get null

keithsparkjoy22:09:48

xlink:href is different, because there’s an explicit namespace there.

flyboarder22:09:24

Right but a non prefix is empty namespace so it is using the namespace of the element

keithsparkjoy22:09:33

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?

flyboarder22:09:51

Exactly which is what your quote says

keithsparkjoy22:09:56

Nope reread it

keithsparkjoy22:09:11

This is a common misperception about XML

keithsparkjoy22:09:23

the interpretation of unprefixed attributes is determined by the element on which they appear.

flyboarder22:09:30

“Default namespace declarations do not apply directly to attribute names; the interpretation of unprefixed attributes is determined by the element on which they appear."

flyboarder22:09:50

Right the only namespace available to the SVG element is the SVG namespace

flyboarder22:09:04

Therefor the SVG attributes get that namespace

keithsparkjoy22:09:08

We’re comparing apples and oranges

keithsparkjoy22:09:20

The DOM is one thing - how you interpret it is another

micha22:09:27

also prefixed vs namespaced

micha22:09:45

like the xlink: part

micha22:09:49

that's the prefix right?

keithsparkjoy22:09:58

But that’s pretty rare

micha22:09:02

but it's just a short alias for a namespace?

keithsparkjoy22:09:11

Correct. And that is obvious and easy.

keithsparkjoy22:09:22

What isn’t so obvious to people is how non-prefixed attributes behave

keithsparkjoy22:09:43

non-prefixed attributes do NOT inherit any namespace from anywhere in the DOM.

keithsparkjoy22:09:52

They don’t get a default namespace

keithsparkjoy22:09:59

They have an empty namespace - it’s null

micha22:09:13

and the element gets to decide how to interpret that

micha22:09:17

a default case

keithsparkjoy22:09:20

the user agent

micha22:09:26

oh interesting

keithsparkjoy22:09:29

the DOM returns NULL

keithsparkjoy22:09:40

my jsfiddle from earlier demonstrates that

keithsparkjoy22:09:06

This was a key learning for me years ago when I was learning XML

micha22:09:46

when you say the user agent interprets it what do you mean?

keithsparkjoy22:09:12

Well there’s a spec for SVG, for example.

keithsparkjoy22:09:22

And they tell you how to use some attributes, say viewBox.

micha22:09:27

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?

keithsparkjoy22:09:43

The SVG spec defines how viewBox is to be used

keithsparkjoy22:09:54

in the context of some SVG elements

keithsparkjoy22:09:58

viewBox is an attribute

keithsparkjoy22:09:04

and it has no namespace

keithsparkjoy22:09:17

but we all know what it means when we see it in an SVG frag

keithsparkjoy22:09:22

because the spec tells us

keithsparkjoy22:09:37

I hope all user agents interpret it the same way hehe

keithsparkjoy22:09:43

according to the SVG spec

keithsparkjoy22:09:57

but when you program against the DOM you’ll find viewBox has no namespace

keithsparkjoy22:09:02

because it’s an attribute

flyboarder22:09:20

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

flyboarder22:09:49

So attributes with blank ns don't know what to do

flyboarder22:09:38

Which is what happens when you set an attribute usually since setAttribute uses blank ns

keithsparkjoy22:09:50

and that’s exactly what you want

keithsparkjoy22:09:54

a blank namespace for attributes

keithsparkjoy22:09:01

unless… one is specifically provided

keithsparkjoy22:09:06

like xlink:href

flyboarder22:09:07

SetAttributeNs with a null ns is different

keithsparkjoy22:09:15

How is it different?

flyboarder22:09:24

Well that's why it fails lol

flyboarder22:09:51

It doesn't have a namespace to get the attribute from the element was created with a custom ns outside of the document

keithsparkjoy22:09:35

It’s very rare for an attribute to have a namespace

flyboarder22:09:52

Right but not in the case where there is no default

keithsparkjoy23:09:17

Let me go hack up a jsfiddle that we can experiment with because we’re going in circles 🙂

flyboarder23:09:40

Make sure your creating the elements from JS not HTML

flyboarder23:09:21

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

keithsparkjoy23:09:05

I’m working on one that creates the DOM elements dynamically for @flyboarder

keithsparkjoy23:09:15

been a long time hehe

micha23:09:11

hm this is interesting

flyboarder23:09:28

If you create the element in HTML it has an implicit namespace

keithsparkjoy23:09:01

Right @micha attributes have null namespaces in the DOM

micha23:09:23

i think the light bulb is drawing one milliwatt in my brain now

keithsparkjoy23:09:34

Yea, this is kind of a mind fuck

keithsparkjoy23:09:41

believe me I felt it

micha23:09:54

so the element's namespace might be different from a specific attribute's namespace

micha23:09:09

and, additionally, for extra wreck, there are prefixes

keithsparkjoy23:09:12

attributes don’t usually have any namespace

keithsparkjoy23:09:35

it actually is pretty simple, just not super intuitive since you’re used to how default namespaces work on elements

micha23:09:47

i think i might be understanding now

micha23:09:03

yes this is like what we have in hoplon now actually

micha23:09:11

with the latest attribute stuff

micha23:09:40

so now, what was the problem we wanted to solve again?

keithsparkjoy23:09:50

there is a case in SVG

keithsparkjoy23:09:58

where you actually do need a namespaced attribute

keithsparkjoy23:09:17

and Hoplon wasn’t liking that much

flyboarder23:09:30

The problem is really only the default attributes once an element has an explicit ns, setAttribute can't handle the implicit namespace anymore

micha23:09:07

one more fiddle

keithsparkjoy23:09:29

@flyboarder did you check out my fiddle?

keithsparkjoy23:09:37

curious if it does what you’d expect it to

keithsparkjoy23:09:54

So the SVG element has a namespace

keithsparkjoy23:09:01

and when I add the “viewBox” attribute

keithsparkjoy23:09:07

it ends up in there with no namespace

keithsparkjoy23:09:17

which is correct

flyboarder23:09:27

Right so it gets the ns implicitly from the element

keithsparkjoy23:09:41

logically - the DOM doesn’t express this though

keithsparkjoy23:09:50

I mean how you interpret viewBox is because you know it’s SVG

keithsparkjoy23:09:58

but if you ask the DOM the namespaceURI of viewBox it’s null.

flyboarder23:09:24

Right but that isn't the same as creating an attribute with a namespace of null

keithsparkjoy23:09:33

It’s exactly the same.

keithsparkjoy23:09:35

I’ll go update my fiddle.

flyboarder23:09:59

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

keithsparkjoy23:09:48

nope - I think we’re honing in on where you and I are miscommunicating, fly

keithsparkjoy23:09:27

totally, Micha

flyboarder23:09:34

@keithsparkjoy: for sure man, don't mean to be a pain ;)

micha23:09:37

and this is what we want to do in hoplon, basically?

keithsparkjoy23:09:07

right we need to be able to do the normal stuff like viewBox, but also the weird stuff like xlink:href

micha23:09:39

so cx is a svg attribute like viewBox, right?

flyboarder23:09:44

So is the solution to always set the ns as null then and not use setAttribute but setAttributeNs

keithsparkjoy23:09:00

@flyboarder I think the two are the same

micha23:09:08

my last fiddle shows that you can use .setAttribute("class" ... on an svg element

flyboarder23:09:17

But they can't be because then the regular attributes wouldn't fail

keithsparkjoy23:09:01

Are you sure the failure was at setAttribute?

keithsparkjoy23:09:07

or could it have failed earlier?

flyboarder23:09:12

The only thing we have done is specify a namespace

keithsparkjoy23:09:31

BTW guys one other thing - XML is totally case sensitive

keithsparkjoy23:09:38

…and viewBox gets crushed to viewbox.

keithsparkjoy23:09:51

along with all the other mixed-case svg attrnames

keithsparkjoy23:09:08

…which is why I’ve been using viewBox as an example so I don’t forget to mention that 🙂

flyboarder23:09:09

Omg I think I know why we are having different views on this, I'm using the jquery split builds

flyboarder23:09:26

So vanilla JS instead of jquery attr

micha23:09:40

ok i think i can hack together a good fix for this

flyboarder23:09:40

Jquery attr causes problems

micha23:09:47

right it downcases things

micha23:09:02

we used to patch jquery, but that has some obvious downsides 🙂

micha23:09:20

ok i think i am fully tracking now

flyboarder23:09:20

Might this go away with latest master build then?

keithsparkjoy23:09:23

I hope all this is helpful - sorry to be taking so much of your time guys

micha23:09:30

no this is awesome

flyboarder23:09:39

@keithsparkjoy: can you try building from master?

micha23:09:39

we're gong to get this squared away

keithsparkjoy23:09:11

Hmm. Is that an easy dep change in my build.boot or something?

keithsparkjoy23:09:18

Sorry I’m kinda new to all of this.

flyboarder23:09:40

If setAttribute is the same as setAttributeNs then this has already been solved by removing jquery from core

flyboarder23:09:53

With a null ns obviously

flyboarder23:09:27

@micha: can you push a snapshot?

flyboarder23:09:16

I think it's the difference in versions causing my confusion, I forgot I'm not on the regular hoplon builds

keithsparkjoy23:09:29

No worries man

keithsparkjoy23:09:02

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.

keithsparkjoy23:09:18

I used to work with those guys in a prior life 🙂

keithsparkjoy23:09:36

Oh man it’s getting slammed over on Amazon. Hehe. Oh well, the namespaces chapter is still the best explanation I’ve seen 🙂

flyboarder23:09:15

@keithsparkjoy: I totally get what you mean by not needing the SVG ns on attributes now

micha23:09:23

@flyboarder i fixed the issues with the new thing

micha23:09:37

but i think we will need to make it a breaking change

micha23:09:08

slightly breaking

micha23:09:16

i will push to master in a minute

micha23:09:33

with my proposal

flyboarder23:09:58

What is different? Sorry I'm on mobile right now

micha23:09:58

i think we really can't make the default jquery thing work well

micha23:09:13

so i removed the --jquery and --goog options

micha23:09:22

because you are going to have to do one or the other anyway

micha23:09:35

but what if you don't want either, etc?

micha23:09:42

or some third one

micha23:09:57

i left in the --refers option

micha23:09:07

that you can use like boot hoplon -r hoplon.jquery ...

micha23:09:42

i also moved some stuff out of hoplon.core, like the default do! and on! methods

micha23:09:02

because presumably you will have different ones in different attribute providers

micha23:09:19

like the ones that were in hoplon.core don't work with jquery

flyboarder23:09:17

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

micha23:09:40

the jquery event handlers expect a jquery event object

micha23:09:53

addEventHandler or whatever doesn't provide that

micha23:09:03

in jquery world you need to do $(e).on("eventname", function(eventObject) ...