In the RAD Semantic UI Plugin the action-layout of the report is checked for visibility but the input-layout is not. Also in the container neither are checked for visibility. Is that intentional?

It's also not checked in the form

no. Inconsistencies like that are typically oversights whose nature is “I didn’t need it, have never needed it, and forgot others might need it”

Sometimes you might find I’ve duplicated effort as a result, which is unfortunate. For example, the embedded? flag has sort of an amorphous meaning at the moment…sort of “you’re not participating in routing and you might sorta hide some stuff” 😄

I’m slightly embarrassed at these. When I had more free time I was better at keeping it all straight.

ManyFiles uses rand-int to set the key of the input. The comment says that it's so that a failed upload can be retried. Why not use inc?

does it matter?

Not really

basically you change the key, react remounts it. Remounting it clears the selected files from the browser.

hacky but effective

There's probably some 0.000000001% edge case that makes one better than the other

rand could return the same number twice

so inc is technically better

Yeah that's what I was thinking. Very unlikely but still possible

Are rotated tables supposed to have selection, alignment, and column-classes?

don’t remember

Off the top of my head I can't think of anything that would go wrong if they were added

RAD really is an unfinished work. I use it heavily, but it was always intended as a system of patterns. The actual implementation of the plugins gets fleshed out as I need features, but the community is welcome to use what I have so far and is encouraged to contribute. I don’t ever expect this kind of work to ever be finished. Too many things people will want. So, it was always designed to be that way. So, when you find something like that, the answer is “think about it”. I don’t have a grand master plan of every element. In this case, I’d agree with you. There’s nothing wrong with having them. I just didn’t need them for that use-case (yet).

Sorry are these too many questions?

My general thought pattern is: • Provide a context-specific place to put things • Layer those when possible if there is a specialization where it makes sense to be “more specific: So, something like the (recently added) ao/label on at attribute: People want to be able to label things in the data model. But in a form there is a lot of space, so the label might get to be larger or have an info bubble. In a report column heading it might need to be abbreviated for space. And that might depend on the number of columns.

That kind of thing

I appreciate the answers

No no. You’re not annoying me in the least ::)

So, fo/field-label, ro/column-heading…but then I realize I’m defining both of those to be the same thing all the time…so it should have also had ao/label

Then of course there’s the problem of what args to pass them when then are functions (the ?! case). What will be available? For fo/field-label its a form. For ro/column-heading it is a report…for ao/label it is a bit dodgy…what if I’m generating a printed report PDF in the server?

So, you run into that kind of complication 😄

There are other options that have an attribute version, a form version, and a report version. I think it's helpful to have the 3 types to cover both those usecases: the attribute version when your labels really are the same everywhere, and the more specialized versions when the labels are different

yep

because forms/reports and whatever else you invent are aggregators that have the context…that’s why validators are defined on forms, and not so much on attributes.

(though you get ao/valid? it isn’t sufficient)

I can define a form with one field that makes entities that require three. As long as the save middleware can fill in the other two server-side, then that’s a perfectly valid use-case.

So I would not want the form saying I can’t save because I’m missing data I didn’t even put on the form 😄

I have a REST-endpoint generator that looks a bit like a form declaration. Purely server-side, using RAD schema model. It generates the Swagger docs, parses REST inputs and turns them into a proper RAD tree of data, validates it, and can return REST errors to the user.

Uses defentity to describe what model bits are communicated (each is like a form with subforms (subentities)), and then defendpoint spells out things like which entity the body will be, docstrings, etc.

same kinds of patterns emerge where you might define something like a swagger docstring on an attribute, but want to indicate something special about that attribute in a given REST endpoint context.

Also doing similar things for other common patterns, like CSV import, excel export….

That might be an interesting alternative to yada

I already have my complete data model well defined and related. Why have to re-state it again?

The new “facts” are “I want to take a JSON tree and transform it to my EDN tree”. That’s a very tractable problem with attributes and form-like entity declarations.

(defentity InvoiceItem
  {eno/attributes [invoice-item/product invoice-item/amount]})

(defentity Invoice
  {eno/attributes [invoice/number invoice/amount invoice/items]
   eno/subentities {:invoice/items InvoiceItem}
   ...})

(defendpoint SubmitInvoice [env invoice]
  {eo/method :post
   eo/uri "/invoice" 
   eo/body Invoice
   ...}
  invoice ; is a RAD-model tree of data)

Data coercion can be defined for all the attribute data types, with overrides available at each layer, etc.

Very interesting. I like this idea

Why does the normalize-options mutation in the autocomplete field have a separate blank clojure impl from the default clojurescript one?

in autocompletee?

because you’re in a SUI plugin ns. I want clj to compile, but it won’t do anything useful if run in CLJ.

the semantic UI js code won’t run in CLJ…so it’s CLJC to prevent compile errors when your spiderweb of requires accidentally gets that file

and it needed to use the #js reader, which I was being lazy about 😄

Now that I think about it, I think i have data readers on Fulcro for #js as identity…so it probably can just be unconditional

The js namespace fails, so I was probably just typing too fast (e.g. (js/console.log…) won’t compile, but I think the reader for js will).

Oh ok that makes sense

I saw there's a new wrap-exceptions-as-form-errors in the RAD demo. Why doesn't it wrap all the save middleware?