Fork me on GitHub

@micha Did you ever figure out why (ns+ ...) doesn't work in .hl files? As a follow up, is there any implication for just using .cljs instead of .hl files? I currently don't seem to be noticing any difference. Maybe a syntax like (page.. :ns+ ...) might easily be made to work in there (since what? .hl's to want to start with "(page....)")?


call was like this, AFTER setting font size/color/style to be visible (tab-button "SYSTEM HEALTH")


try something like:

(defelem tab-button [attrs elems]
  (image :a :mid :b 1 :bc :white :url black-button-red-line 
    attrs elems))


worked like a charm!


@vigilancetech: by the way, the page macro was designed for use with .hl files, while the ns+ macro extends ns so you can use a regular .cljs file. i don’t think ns+ was intended for use with a .hl file.


I noticed you seemed to be using 'ns+'. Was that because it had better macro importing characteristics?


Is there any disadvantage to using a .cljs file to using a .hl file?


well, you don’t have to configure your tooling to recognize them, for one


so the hoplon compile process is essentially just processing the page constructor? And if you don't use it, you can skip the hoplon boot process all together?


the cljs files also allow you to use ns+ with hoplon, which in turn allows macros and functions to be imported generally, which means i don’t have to go back and refactor everything when i move a function definition to a macro or vice versa.


Yes, I definitely want to use ns+. I did a fair bit with macros on elisp and I'd rather not have to curtail that much now.


the page macro also implicitly :refers all the html element constructors into your .hl file by default. this is convenient when creating a page, at first, but becomes annoying as your app gets larger. for example, after defining a menu element, you might discover later on, after much frustration, that 'menu` is referring to the hoplon constructor for the html menu element instead of the one you created. ns+ requires that you explicitly import these functions like all the others. this also makes it much friendlier for use with hoplon/ui, since the html primitives aren’t used directly.


I'm kind of surprised there's no warning on a collision like that.


Would there be a reason why I can't set a :mouseover event with a ui image element? I'm getting: 'ui.cljs:66 Uncaught Error: Unhandled attribute with value {:mouseover #object[Function "function (){ return,"mouse came in");'


@vigilancetech hoplon/ui elements are not DOM elements but an Elem type with 3 DOM elements:


the parameters passed to an Elem are collected into a hash-map of attributes and a vector of children by the very same function (`hoplon.core/parse-args`) what hoplon uses for this purpose, as you can see it here:


BUT afterwards these attributes are passed thru a stack of middlewares which both validate and interpret these parameters. the assert-noattrs middleware in this stack is what catches any non-handled attributes and throws that error message u see:


in hoplon, the parameters - like :mouseover - to the dom elements are interpreted by the on! multi-method as opposed to hoplon/ui's "Elem middleware stack", that's why you can's just expect any attribute which worked in holpon to work in hoplon/ui. btw, the processing of attributes happen here:


Since we don't have these things documented, I recommend you to read the source code itself. I think the reason for lack of documentation is none of us are very sure how to document and what exactly should be documented. However the source code is so short and quite well written, it's makes writing documentation for it an even bigger challenge, imho...


### Hoplon

wc -l (find ~/ -name '*.clj' -o -name '*.cljs')
     319 ~/
     639 ~/
      46 ~/
      90 ~/
      43 ~/
    1137 total
### boot-hoplon task
wc -l (find ~/ -name '*.clj' -o -name '*.cljs')
     147 ~/
      52 ~/
      38 ~/
     177 ~/
     106 ~/
      18 ~/
     179 ~/
     717 total
### Hoplon UI
wc -l (find ~/ -name '*.clj' -o -name '*.cljs')
     203 ~/
     150 ~/
     276 ~/
      29 ~/
     667 ~/
    1325 total


I hope these metrics are encouraging everyone to peek under the hood for answers. While the response latency is quite good on this channel, just reading the sources might be more efficient. When I say 3000 LoC is short, I mean it's short for what it does. It's not that short when it comes to remembering and understanding all of it, I agree. I myself have read it probably ~4 times in its entirety over the past 2 years and some parts I keep forgetting so I've probably looked those up even 20 times. But since I'm using Cursive, it's super easy to quickly and accurately jump to the definitions...


@onetom although I wholeheartedly agree that RTFM (in this case, the ultimate manual being the sources) is a worthy goal to aspire to, in my case, having read the FAQ where it describes that ultimately 3 <div>s are created by UI elements, plus according to my read of its docu says it should support :mouseover (or possibly what appears to be ":onmouseover"), I am relatively new to clojure(script), the 3000 LoC is pretty rife with advanced, not easily learned features such as prototypes, plus I've had absolutely NO luck so far in getting any "jump to definition" IDE feature running in emacs nor light table (e.g. universal nor exuberant ctags) I'm really struggling to find an answer to what seems to me should be a pretty straight forward question to the right person who IS intimately familiar with the sources (and which I still do not have). Hey, I may be wrong!


i often find that i learn the most those times when i’m forced to read through source code, in some cases because i really want to understand the semantics behind a particular function call, or more often than not, due to nonexistent or incomplete documentation. @onetom has a point.


oh, and btw, the ":click" attribute works


on the other hand, there’s definitely a cost associated with deriving the abstractions out from the code yourself, and this can be particularly costly in a dynamically typed language like clojure. sometimes you’ve got to climb ten functions up the stack to figure out what arguments a given function might take, and this can be quite painful.


and it is rarely convenient at the time i’m trying to do it, often when i just need to get a thing done.


good documentation is definitely on the roadmap for ui


@jumblerg normally I would, and indeed I did try, and I also try to exhaust my other remedies before I bring my questions here. There is nothing I would love more right now than to understand that sources to ui inside and out, but for the moment that's not a luxury I can afford. Its a struggle to use something like UI which I feel is superior to the alternatives (like bootstrap) but less documented and conceptually more abstract, or to bite the bullet and wait for ui to mature then have to basically write a significant part of it all over again.


yep, i totally get it.


hell, i wrote the thing, and i still have to go looking sometimes. 🙂


And I would love to help with that documentation once I get some of this behind me. I'll go thru the ui sources and document the hell out of them WHILE I learn them!


that would be terrific


Hey, I know how that works. I still have code today that I have no IDEA how I managed to dream that up while I was in the "zone"


I'm just on a tight deadline for the next project or two, then hopefully I'll be able to "backfill" a bit and contribute to the ui docs


detailed docstrings on the public functions would be really helpful. on the other hand, the api is still evolving a bit, and keeping documentation in sync is a lot of work.


I definitely feel like this little hoplon community is on to something big and feel privileged to hopefully be in on the ground floor pushing it over the top. I've basically waited for something like this to come along when it comes to the jumbled up mess that is web development. I'm doubly lucky that I might have a chance to make a few bucks while I learn/refine it.


yep. so are you also using ui for a real thing in spite of my warnings not to?


yes, guilty 😕


but I'm committed to rewriting it to keep up with the API if necessary, rather than rewriting from bootstrap to ui


ha! it’s pretty cool that there’s such interest though. i think we’re on to something here.


And I'm trying to factor the hell out of it to isolate those API changes.


great, because i’m probably going to break your stuff this evening.


lol, ok. Thanks for the warning


Can you make a branch at this point for "stable" and one for "development"?


(I know, stable is relatively speaking)


i’m actually doing some work to generalize the image, video component apis right now to deal with your “cat problem”.


lol, "cat problem," I had to think about that one for a min. Yes, good. I worked around it, but more uniform there would be better


and yeah, wrt the hoplon community, i feel the same way. the stuff i’ve done on the ui layer is really just a logical progression on top of the core hoplon abstractions that micha rolled.


Its super important IMO. I can even envision at some point in the future for browsers to natively support something like cljs and for the js programmers having to compile the latter to the former, e.g. for js to be the 2nd class citizen here (like it really should be).


i’ll do my best to help out and answer your questions as i’m able. it’s rewarding to see people starting to use ui already, despite the fact it is still under development.


i also think this is where lisp really shines.


I'm ramping up quickly. My elisp stuff was done about 20 years ago so my old brain is a little rusty. Been doing mostly law that whole time and its funny how that mode of thinking feels like the antithesis of software development (like mostly being reactionary instead of creative, with a lot of arbitrary rules, with exceptions being the BIGGEST rule of all).


in almost every other programming language and environment, when it comes to ui work, they have these “code in front” and “code behind” idoms they have to follow, toggling between declarative sgml and the rest of the source. since lisp is declarative already, we don’t have to do this.


I've always noticed anyway, that it takes a lot of time to make the shift. I have a real hard time doing pleadings and then turning right around and writing code without a cooling off period of a few days


definitely looking forward to chatting about the law stuff, as an aside.


and yeah, as you may have noticed, i’m in a bit of a start - stop - start rut with ui myself. i can relate; it is incredibly inefficient.


yeah, me too. I've even started working on a multimedia database (in elisp) inspired by my need to keep track of cases, exhibits, etc....


here is an old video of my technology: You'll have to crank up the audio or wear headphones. Sorry about that. Part 1. Part 2.


I'd love to enhance and webify it some day. It's loosely based on the concept of sets that dynamic rearrange their items based on their juxtaposition of other sets on the screen. It seems to be a pretty natural and intuitive way to do search.


@vigilancetech - mention of law lit up my radar - I’m another legal person here fiddling with Hoplon off and on - I was sort of waiting for UI to stabilize a little bit - but if it works maybe I should jump in - You are right shuffling between code and law can be tough - they are somewhat inconsistent states - if that makes any sense


@tbrooke totally makes sense to me. It not only happens to me but another programmer/litigator buddy of mine spontaneously experienced the same thing. Its weird!