ok, I have yet to try the other one yet so thanks for the update

not that I know anything, but wouldn't that be "when-let?"

@vigilancetech with-let returns the bound element. In the example that would be canvas-elem.

hmm... know where I refer them from?

They are on hoplon.core iirc.

I think I tired that, and hoplon.hoplon, and google 😕

hm i think with-let is actually from javelin.core

ah, ok, I'll try that micha

yup, its there. Canvas-elem is automatically in the namespace in a *.hl file apparently.

but no love on getting it to render: 67Uncaught Error: Invalid child of type function HTMLCanvasElement() { [native code] } with values (#<Cell: :top>).

im still half-way reading thru the discussion, but let me add some thoughts to > what about when Lein-hoplon comes around? Do we merge that too? by @flyboarder there is the example of https://github.com/weavejester/environ which supports both a boot task and a lein plugin the boot task was separate before under https://github.com/danielsz/boot-environ our situation might be different, but i think it is a good and small example which might help to understand the situation

@onetom they key thing that clarified for me is: the boot-hoplon/lein-hoplon tasks/plugins will always be backward compatible

and if they ever aren't, there's a bug and we need to push a new version

acknowledging this gets us out of all the maven-related reasons i could think of to need separate deps

@dm3 im still using boot-hoplon to generate the index.html & index.html.js but im entertaining the idea of just doing that manually, so it's explicit and there is no magic hoplon_app_pages namespace is created (which i still cant remember how is it called exactly) but otherwise im just referring [hoplon.core :as h] and [hoplon.ui :as hui]with a few frequently used :refers and otherwise use explicite namespace alias prefixes when referencing symbols. i have a src/template.cljs just as a reference where i can copy-paste the boilerplate from:

(ns template
  (:refer-clojure :exclude [+ - * /])
  (:require
    ; Assign NS aliases and refer most common symbols
    [javelin.core :as j :refer [cell]
     :refer-macros [cell= defc defc= cell-let with-let]]
    [hoplon.core :as h :refer [defelem when-tpl if-tpl case-tpl for-tpl]]
    [hoplon.ui :as hui :refer [elem]]
    [hoplon.ui.attrs :refer [+ - * / c r pt em px d]]
    [hoplon.material :as mui :refer [container row paper]
     :refer-macros [form-with]]
    [hoplon.material.colors :as c]))

@alandipert you mean backward compatible amongst major versions, right? so when we renamed holpon.core/meta to hoplon.core/html-meta we should have incremented hoplon's major version number, but the released hoplon jar would contain an unchanged boot-hoplon task?

the hoplon jar would contain the task that is guaranteed to work with that specific version ofhoplon

the task internals is an implementation detail

the thing that is impostant is the options to the task

and the api for the task

that is what will be backwards compatible

in other words, if you have a project that uses hoplon version X and you use boot-hoplon from hoplon version X, and you update hoplon to version Y your project will still build with no changes

you will call the task the same way, with the same options, etc

and it will produce the same application

hoplon version Y may have added features or bugfixes only

Imo merging boot-hoplon into hoplon is a good idea to avoid incompatibility issues. What really troubles me is having to use it. Just having it laying there is just some .clj files that will go into a jar if one uses such a thing for deploying, if it helps someone I don't see the problem.

Okay, I don't think you always want to maintain backwards compatibility. You might want to rename a flag, alter the behavior of a flag to fix a bug which no everyone sees as a bug, and stuff like that. What would you do I that case? Increment the major number for the sake of boot hoplon task and release a jar with an unchanged Hoplon implementation?

I think that's what the semantic versioning process recommends but it also suggests that something major might have changed in the Hoplon runtime

Which I know is a consequence of ppl treating version numbers primarily as marketing tools, but still...

the major number indicates that your build could break by upgrading

you may not use that specific feature, and your thing may not break

but it tells you that a feature that you may be using has changed in an incompatible way

so you look at the changelog before updating the version

Here is an other scenario: Boot 2.7 comes out which makes some options obsolete. What would you do in that case?

boot 2.7 will be backwards compatible with 2.6

and all the 2.X versions

That's a good point... So how about boot 3.0?

we'll need a different task for that

with a different name

or bump the major version of hoplon

or we could make the task compatible with both versions of boot

any of those 3 options would work

okay. agree.

hi

i've been looking around on how to use repl to debug hoplon stuff but didn't get very far

boot.user=> (ns hoplon.app-pages._index_DOT_html)

@chbm so there are two types of .hl files: namespaces and pages.

namespaces are like clojurescript ones, and you use those in the same way.

pages generate pages, and it's not supposed to be used from other namespaces or pages.

A page has a (page "index.html) declaration on the top of the file. A namespace has a (ns my-cool-namespace.core) declaration.

right got it

a .hl page starting with (ns ) just gets passed through

so it doesn't get mangled

why does it even have to be a .hl page anyway ?

@chbm it generates a html file automatically.

@chbm: it is more for convenience than a requirement

You can just use hoplon like any other lib, but then you must refer things manually

how can Castra’s ring middleware work with an exception reporting type middleware? It doesn’t propagate errors.

:thumbsup: txk

The only way I can see to insert exception reporting into a Castra backend is to split the castra middleware in two and inserting my exception reporting in between: https://gist.github.com/AdamFrey/f489f8d7f6a3a63b64ee29e5dc6ca8a3 This is pretty fragile to any changes in Castra, though 😞