If you're looking for functional reactive programming in Clojure (rather
than going web-based), there's a great library for Clojure bindings to
RxJava: https://github.com/ReactiveX/RxClojure

Jason Lewis

vox      410.428.0253
twitter  @canweriotnow
blog     http://decomplecting.org
else     http://about.me/jason.lewis

On Tue, Jan 13, 2015 at 10:15 AM, Colin Yates <colin.ya...@gmail.com> wrote:

> 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.
>

-- 
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.

Reply via email to