Clojurians Log v2

> it’s used in 2 places in report.cljc…I would think you’d want (fn [report-class] EQL), ah but it’s in a macro, and might be hard to get the body class…since we’re in the midst of defining it Wouldn't it make more sense to have ro/columns-EQL option in the reports to override the attribute ro/column-EQL on a specific report?

otherwise with the fn there's a circular dependency since the report requires the attributes and the model will refer to the class of the report

I actually had a quick look at this yesterday, its just this line that is blocking the (assoc Attr ro/column-EQL ...) solution: https://github.com/fulcrologic/fulcro-rad/blob/main/src/main/com/fulcrologic/rad/report.cljc#L617 Even without the circular dependency thing eric is mentioning; I struggle to see the value of that direction (I do see the value for the other report-options, just not what it solves here)

So, I think the right option is what Eric is suggesting…it is what I do everywhere else: Allow a default in the attr, and a report-specific override

The trick with this specific option is that because the macro builds the component query, it has to be able to resolve the value at compile time.

I’ll patch it shortly…working on something else at the moment

Released in 1.6.15. This follows the pattern of all other options like it: The column-EQL attribute option is kind of a “global default” for all reports, and each report can optionally override with the plural ro/columns-EQL.

I could look into providing a fix if its indeed a bug in fulro, but im first trying to understand if thats indeed the case or if im missing something.

you should not be using a row query inclusion. Add a ro/column-eql to the attribute instead

and also a ro/column-formatter

both on the attribute

query inclusions are for data unrelated to the specific columns. For example :ui/wiggly? to do some custom UI thing on your report UI

Yes, thats actually what I did to work around it. But doesnt it make sense to want the option to define this on the report level as well? I dont necessarily always want the same sub-query for every report.

That’s why ro/column-eql (and most options in RAD) support a function

ok, nice. l'll look into that. thanks

actually, that one doesn’t appear to support a function (which I guess I’ve never needed, but that is the pattern for what you are saying). That said, you can also just assoc an alternate option on the attr when using it on a report… (assoc course/administrator ro/column-EQL …)

but I would accept a patch to support a fn variant on column-EQL

it’s used in 2 places in report.cljc…I would think you’d want (fn [report-class] EQL), ah but it’s in a macro, and might be hard to get the body class…since we’re in the midst of defining it

which is why I probably left it as it is

> That said, you can also just assoc an alternate option on the attr when using it on a report… > > (assoc course/administrator ro/column-EQL …) I tried this, but it didnt want to compile; I presummed due to checks within the macro, but didnt check. Maybe thats what you're getting at later in your message, not clear to me.

I would prefer a solution along those lines I think, not sure what a fn arg option would bring me; I "just" want to define what nested data is relevant for this report from a particular attribute onward. Defining it purely on the report seems cleanest to me. When/if I find the time I'll look into whats keeping me from doing (assoc course/administrator ro/column-EQL …)and see if i can find a ok structure to support it.