I have been working on a desktop App for the last few months and I have not got many problems with the architecture and isolation of the views.
In my young blog, I have few posts of how to set up and launch the JavaFX App. I also have a MVVM and the conventions of how to compose each layer. In regard to the events, I have also written an Pub-Sub event bus inspired by Timothy Baldridge using core.async. There is a wrapper called clojurefx by Zilti that helps you binding properties of the visual components to atoms. He is refactoring this library in his Bitbucket repo. I am using the one in GitHub. You can also use the add-watch for listening to changes in the state or inferior layers, as you would do with an "addListener". In regard to the cache or client database, I have a lack of knowledge on that. At the moment I have a very cheap bespoke solution using steveskeys, which use a couple of random access files to read and dump the nippy serialized objects from memory to disk and viceversa. If you have a good solution for your client cache/database I would like to hear about it. The idea of that cache, is giving some relief to the server on calls that you have previously done and have an offline capabilities to visualize an aggregated snapshot of your data. But when missing the cache, would just mean, doing few more REST calls to the server. If you want more details about the MVVM desktop app, I can help you with that. I have 2500 lines plus the CSS. Ping me on twitter. http://www.efrainbergillos.com/clojure/clojure-publishers-subscribers-and-mvvm/ <http://www.efrainbergillos.com/clojure/clojure-publishers-subscribers-and-mvvm/> Regards, Efrain 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.
