Wow, there is a lot to deal with :), so let me throw out some ideas: - have you considered building a web-app instead of a desktop app? If so, have a look at one of the react based languages (om or reagent would be my choice). Alternatively take a look at other http://en.wikipedia.org/wiki/Functional_reactive_programming libraries.
It is a different way of working, but its programming model restricts you in a way that removes many problems (if you see what I mean). Also, I would be reaching for an in-memory database (assuming a server isn't involved) about now, datatomic would be the obvious choice. I don't think what you are trying to do is stupid, I do think you might want to do some thought experiments about different architectures and paradigms (specifically FRP related paradigms). Oh, and have a quick scan through http://swannodette.github.io/, there are a few "mind-changing" posts. On Monday, 12 January 2015 18:53:07 UTC, MS wrote: > > (Cross-posted on StackOverflow) > > I'm trying to design a desktop UI for schematics, layout, drawing stuff. > Just looking for high level advice from actual software designers. > > Assuming an in-memory "database", (clojure map of arbitrary depth for all > user data, and possibly another one for application preferences, etc.), I'm > examining how to do the model-view-controller thing on these, where the > data may be rendered *and modified by* any one or more of: > > 1. A standalone text field that shows a single parameter, such as box > width. > 2. An "inspector" type of view that shows multiple parameters of a > selected object, such as box width, height, color, checkboxes, etc. > 3. A table/spreadsheet type of view that shows multiple parameters of > multiple objects, potentially the whole database > 4. A graphical rendering of the whole thing, such as both schematic and > layout view. > > Modifying any one of these should show up immediately in every other > active view, both text and graphical, not after clicking "ok"... so no > modal boxes allowed. If for some reason the table view, an inspector view, > and a graphical rendering are all in view, dragging the corner of the box > graphically should immediately show up in the text, etc. > > The platform in question is JavaFX, but I'd like a clean separation > between UI and everything else, so I want to avoid `bind`ing in the JFX > sense, as that ties my design data very tightly to JFX Properties, > increases the graininess of the model, and forces me to work outside the > standard clojure functions for dealing with data, and/or deal heavily with > the whole `getValue`/`setValue` world. > > I'm still assuming at least *some* statefulness/mutability, and the use of > built-in Clojure functionality such as the ability to `add-watch` on an > atom/var/ref and let the runtime signal dependent functions. > > Platform-specific interaction will rest tightly with the actual UI, such > as reifying `ActionListener`s, and dealing with `ObservableValue`s etc., > and will attempt to minimize the reliance on things like JavaFX `Property` > for actual application data. I'm not entertaining FRP for this. > > I don't mind too much extending JFX interfaces or making up my own > protocols to use application-specific `defrecord`s, but I'd prefer for the > application data to remain as straight Clojure data, unsullied by the > platform. > > The question is how to set this all up, with closest adherence to the > immutable model and minimal (or well-bounded) dependence on JFX. I see a > few options: > > 1. Fine-grain: Each parameter value/primitive (ie Long, Double, Boolean, > or String) is an atom, and each view which can modify the value "reaches > in" as far as it needs to in the database to change the value. This could > suck as there could potentially be thousands of individual values (for > example points on a hand-drawn curve), and will require lots of > `(deref...)` junk. I believe this is how JFX would want to do this, with > giant arrays of Properties at the leaf nodes, etc., which feels bloated. > With this approach it doesn't seem much better than just coding it up in > Java/C++. > 2. Medium-grain: Each object/record in the database is an atom of a > Clojure map. The entire map is replaced when any one of its values > changes. Fewer total atoms to deal with, and allows for example long > arrays of straight-up numbers for various things. But this gets > complicated when some objects in the database require more nesting than > others. > 3. Coarse-grain: There is just one atom: the database. Any time anything > changes, the entire database is replaced, and every view needs to re-render > its particular portion. This feels a bit like using a hammer to swat a > fly, and a naive implementation would require everything to re-render all > the time. But I still think this is the best trade off, as any primitive > has a clear access path from the root node, whether it is accessed on a > per-primitive level or per-record level. > > I also need the ability for one data template to be instantiated many > times. So for example if the user changes a symbol or shape which is used > in multiple places, a single edit will apply everywhere. I believe this > also requires some type of "pointer"-like behavior. I think I can store a > atom to the model, then instantiate as needed, and it can work in any of > the above grain models. > > Any other approaches? Is trying to do a GUI editor-like tool in a > functional language just stupid? > Thanks > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
