This looks very interesting, I wasn't aware of SCXML at all. Down the rabbit hole we go! 🙂

Yeah, I chose that standard because it was either that or read Harel's papers and all of the literature since the late 80's...I figured if they worked out a good standard over a number of years (the early drafts of SCXML were much earlier that 2015) then they'd probably considered and simplified things greatly. I actually am pretty happy with the standard now that I've implemented most of it. It's really well thought-out. I still need to finish understanding how I'm going to do "invocations" and some kind of "system management" abstraction...I want to have something where machines can spring into existence, live over a very long time (e.g. in server databases), wake/sleep, etc. The standard gives you everything you need to implement that, it turns out. Not sure what of that I'll add to the top-level lib, but I'm excited about all the possibilities.

Some other interesting “prior art” of workflow state management and execution systems: “wake/sleep” of machines reminds of the virtual actor concept, as implemented in https://docs.dapr.io/developing-applications/building-blocks/actors/howto-actors/ and invented in https://www.microsoft.com/en-us/research/project/orleans-virtual-actors/ – I think a common pattern is to execute the state machine within the virtual actor system, which manages the compute resources and sometimes even the persistence. Another production workflow system with sleep/wake is https://github.com/temporalio/temporal – that’s a commercial fork of https://github.com/uber/cadence

This looks very interesting. I am currently looking at Camunda BPM or Zeebe as part of the back-end of my Fulcro app. The idea is to have an engine that orchestrates long-running workflows with Tasks for both humans and other microservices. Camunda and Zeebe use the BPM standard as the DSL to specify workflows. I found the book "https://www.amazon.com/Practical-Process-Automation-Orchestration-Microservices/dp/149206145X/ref=sxts_rp_s1_0?__mk_nl_NL=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=3M1J3T0YPB9C4&cv_ct_cx=practical+process+automation&keywords=practical+process+automation&pd_rd_i=149206145X&pd_rd_r=ee45a740-5453-4f2d-96c6-b94c44d8e15a&pd_rd_w=Cnepk&pd_rd_wg=7A6pb&pf_rd_p=b6d0be91-09b0-4a6b-9472-c11ec7a0fdf4&pf_rd_r=61MTMKAZCDNCS20PR3MK&psc=1&qid=1639686686&sprefix=practical+process+%2Caps%2C179&sr=1-1-1890b328-3a40-4864-baa0-a8eddba1bf6a" quite useful to understand where such an engine fits in an overall architecture. Also, the talks by the author https://www.youtube.com/results?search_query=bernd+ruecker are worth watching. I'm not familiar with statecharts, will try to read up on that to be able to join the conversation.

In the same vein but way simpler: https://github.com/bokmann/stonepath. Lacks a "transition algorithm". I briefly tried to wing it and roll an implementation myself, but I quickly realized that doing this correctly is waaaaaaay hairier than I have time for. Workflow engines are a deep subject. Very excited to follow this track in the Fulcro ecosystem!

I've had about as much luck with BPM systems as with ORMs 😄 The idea that you're ever going to hand your business person a diagraming tool and have them actually use it are pretty rare, and them getting it actually right really requires an analyst, but small companies can't afford that, so devs end up just doing it, and devs prefer to just write code. The pretty picture aspect is nice, but easy enough to generate with modern tools (would be trivial to output PlantUML, for example, and have it just generate an image). Then there's the infra question, and BPM could be a win there, but with cloud stuff letting you spin up Kafka for $100/mo to get durable queues combined with Clojure, it doesn't feel very compelling to use a BPMS. If you're "big enough" I guess it works.

That was my first reaction as well 😅. However, Camunda caught my attention because they explicitly position the BPM definitions as software artifacts written by developers, not business people. This in contrast to the heavyweight BPM solutions of the past, positioned as "no-code" products. The embedded Camunda bpm, which persists to SQL, is quite lightweight. Zeebe is the cloud-native extrapolation of that, implemented as a Kafka-like event-sourcing system with the BPM engine on top of it. In any case, I think it's worthwile to have a look at as there is probably quite some conceptual overlap.

Sam Newman mentions precisely this in his book https://www.amazon.nl/s?k=monolith+to+microservices&__mk_nl_NL=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=38W8YIYCC5YKS&sprefix=monolith+to+m%2Caps%2C181&ref=nb_sb_ss_ts-doa-p_1_13:

Cool, yeah, thanks for the tips.

Not that I'm aware of.

though you could use the lein tools deps integration plugin, and use deps for the deps, and lein for whatever it is you think you need from it.

You just need to copy deps way of specifying dependencies into the way that lein does it, no? There is no special magic. You would need to switch shadow-cljs from using deps to lein, which it does support. None of that should be a big deal IMO?

com.datomic/datomic-free I think is the dep

com.datomic/dev-local also may provide datomic.api

https://docs.datomic.com/cloud/dev-local.html#using

I want to run an application that uses datomic.api and datomic.function using the dev-local library.

https://github.com/fulcrologic/fulcro-rad-datomic/blob/5193cb0ab88bdb1da7c25f44e538531b353f4385/src/main/com/fulcrologic/rad/database_adapters/datomic.clj#L14

If you get it working let me know because I tried to get it working under graalvm but am not good enough with java or clojure to figure it out. I ended up using xtdb instead of datomic.

The app is not mine but @U6VPZS1EK’s - we shall discuss

the dev-local library is for cloud

which is not that ns

See https://github.com/fulcrologic/fulcro-rad-datomic/blob/develop/src/main/com/fulcrologic/rad/database_adapters/datomic_cloud.clj

It is possible, but I have not had the time to write it. Spec uses a lot of macros, so the trick would be to write a version of defattr as a macro that would emit the spec at the same time as the def.

That would be a compile-time transform....malli would be easier. I've spent some time making GR actually be protocol-based so you could use any spec'ing system (Malli or spec or spec2), but I just have not had the time to finish that either. Too many balls 🙂 Another way you could do it is just put the spec under a special key of the attribute, and write a post-processor that installs those into the spec registry...that would actually be easier I think?

https://github.com/clojure/spec.alpha/blob/master/src/main/clojure/clojure/spec/alpha.clj#L329

not sure that any of that makes sense, though...you probably want more of a real spec, like (s/int-in 0 100), and just putting that in an s/def just below the attribute makes pretty good sense. Spec already uses a global registry, so you are not winning anything by putting it IN the defattr

Yeah, you're right, as it stands there's not much gained by putting the global registry definition inside the attribute definition, but it would be pretty cool if we could just use the attribute keywords throughout the application to do things like GR validation and other operations... things like (s/coll-of ::foo/bar ...). I thought maybe since the attribute type is already registered somewhere, it could be used without additional code. Just musing here, but maybe a registered RAD attribute could have a spec definition - an extension to the base attr. type - in its body which would associate the attribute key with the spec... that would allow this sorta thing.. I think...

So, you can add a predicate to the attribute with ao/valid? , so IMO that would be the thing you could use to emit the spec, instead of the type...I mean, I guess you could use the type as a default.

Thanks @U0CKQ19AQ I'll give that a try sometime. https://github.com/fulcrologic/fulcro-rad/blob/caef19a925df41bb8d74079cde2a51d39f7c0874/src/main/com/fulcrologic/rad/attributes_options.cljc#L64 for reference.

I have the same behaviour with both Chrome and Vivaldi.

Can you try it on https://8181-tan-caribou-1k3gfeno.ws-eu23.gitpod.io ? Does the elm. pciekr work there?

Notice that it shows the > Note > The element picker requires a UI plugin ... message even if you have it enabled - but the "Pick Element" is there and works. Is that your case?

@U06A9U5RP ☝️

Ah, I hadn’t realised the message always appears. It is indeed working. Thanks again for your help.

But… In the MVC app (your workshop thing), I get feedback when hovering over components. In my other app (where I’m working through the Fulcro video series), I don’t get any feedback on hover, but if I click on a component the inspector shows the component’s details.

Maybe I’ll copy over some of the code from the MVC app to the other app to see whether I get hover feedback.

Could be some CSS styles getting in the way

see https://github.com/fulcrologic/fulcro/blob/develop/src/main/com/fulcrologic/fulcro/inspect/element_picker.cljc#L104-L115 It is possible the tooltips are there but invisible

If the tooltips are invisible, do you know what I should do to make them visible? (I’ve been trying to work out how to get two Chrome inspector things up at the same time — one for (ordinary HTML) elements and one for Fulcro Inspect — but I can’t see how to do that.)

I’ve removed all the CSS from my project, but still no hover feedback.

Ah!

Uncaught ReferenceError: ReactDOM is not defined
    at over_handler (element_picker.cljc:97)
over_handler @ element_picker.cljc:97

Good catch!

Hah! This is fun… • I’ve created a copy of the com.fulcrologic.fulcro.inspect.element-picker namespace in my repo so that I can play with it. • I’ve looked at recent commits in the Fulcro repo. • I found https://github.com/fulcrologic/fulcro/commit/cd755fd426aa7773de9ee23c1b9344430dcb6b12 • That commit gets rid of the use of ReactDOM

And the fun bit… The author of that commit is holyjak, and (I assume), that is you (@holyjak)!

I guess I can refer to that specific commit in my deps.edn. (Looking up how to do this…)

Forgot to say, applying that commit to my local copy fixes things.

I’ve upgraded to

com.fulcrologic/fulcro {:git/url ""
                        :sha "cd755fd426aa7773de9ee23c1b9344430dcb6b12"}

I was using Fulcro 3.5.9-RC1. Downgrading to 3.5.8 also fixes things.

@U0CKQ19AQ perhaps it would be nice to make a new 3.5.9-RC2 release with the element picker react dom removal?

I didn't follow. Is a PR needed?

Hi @U0CKQ19AQ No, no PR is needed. A bug was introduced in 3.5.9-RC1 — there’s no hover feedback from the Element Picker. It’s fixed in the develop branch by https://github.com/fulcrologic/fulcro/commit/cd755fd426aa7773de9ee23c1b9344430dcb6b12

ah....ok, I can cut a release

3.5.9 released

👍 I confirm that 3.5.9 fixes the bug.

thanks