Clojurians Log v2

@urbank Well, set-query! in general lets you either change the params (which are just subs on the query) or the entire query, so yes, IQueryParams is part of that subsystem. Sorry the forms support isn’t a bit more baked/documented. I just have not had the time. The basic model is that you’re fronting a real persisted entity (of entity tree) with state management/diff/render/refresh/submission mechanism that is extensible. The completely reusable calendar component could be leveraged as the rendering for an entity’s value through the forms support…where the form field renderer would have you compose in the form-fields “extra data” in your component’s query in addition to the actual date, and the form-field hook-up would (behind the scenes) push the data into the calendar at the proper time, and pull it out on the event. It isn’t any different than what I described above, but it would hide the implementation detail from the user so that the form would still be largely declarative.

If you’re really feeling the need for more sugar, you could always make helpers to compose the query bits together…or heck even make a macro called defform that could detect the use of a calendar field and augment the query, etc. I mean, eventually we may even want something like defform in the library itself once we’ve established the common patterns. My intention is to provide pre-written form renderers as well. You declare the form fields, and if you’re ok with a canned rendering, you could just write (render [this] (render-form this)), and that would output something that has all of the field labels, form fields, validation, submit/cancel using the “default” css.

Most of that is just boilerplate code that anybody could write in an afternoon. Getting the CSS right is the main time sink.

Note about earlier comments on path-meta. I just thought through it some more. It is also needed for the limited refresh optimization in Om Next that allows a partial query to run for a render update…so I think there is no way to remove it without giving up that optimization (which reduces the db->tree overhead in the first place) by limiting the query for re-renders. So, scratch those ramblings about turning it off, unless we do some measurements and find we don’t often win from that optimization…but I doubt it.