0

currently working on a GUI application using JavaFX 2 as framework. Used in Java allready and know the principles of data binding.

As the functional style programming in scala advocates the use of imutable values (vals), there is a gap.

Is there an other solution than having an mutable fx-property based presentation model for the gui and and immutable model for application logic with an conversion layer?

Greets, Andreas

andreas
  • 1,266
  • 1
  • 13
  • 33
  • Is this a real question? JavaFX is built on property binding and UI is naturally mutable. – Andy Till Apr 02 '13 at 19:24
  • Having seperate domain model and presentation model classes with the "conversion layer" as methods on the presentation model is most likely the best solution. – Knut Arne Vedaa Apr 02 '13 at 21:33
  • The question you asked is maybe too abstract. Could you give an example of how you would use JavaFX? – michael_s Apr 03 '13 at 04:13
  • Yes, my question is real ;) I got a tip to look into "Functional Reactive Programming", but do not do it up to now... looking forward to it. – andreas Apr 04 '13 at 11:00
  • 1
    As you will be investigating [Functional Reactive Programming](http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming) and Scala, you may be interested in [Deprecating Observers](http://infoscience.epfl.ch/record/176887/files/DeprecatingObservers2012.pdf), which is a paper on applying functional reactive concepts in Scala as implemented in the [Scala.React](https://github.com/ingoem/scala-react) library. – jewelsea Apr 06 '13 at 00:04
  • Thanks for your answer. I will take a look at it. – andreas Apr 07 '13 at 13:49

1 Answers1

0

Since your question is a bit vague, please forgive if this is largely based on personal opinion: There are, to my knowledge, no other approaches to the mutable property model. I would however argue that you don't want one:

First of, functional programming, at least from a puristic point of view, attempts to avoid side effects. User interfaces, however, are exclusively about causing side effects. There is a slight philosophical mismatch to begin there.

One of the main benefits of immutable data is that you don't have to deal with control structures to avoid concurrent modification. However, JavaFX's event queue implements a very strict single-threaded approach with an implicit control of read and write access. On the other hand, user interface components fit the idea of mutable objects better than most other fields of programming. The node structure is, after all, an inherent hierarchy of stateful components.

Considering this, I think trying to force a functional and immutable paradigm on JavaFX is not going to work out. Instead, I would recommend building a translation layer based on keypath selections - e.g. binding a Label to display an (immutable) Person's name to the Person, not the name property, and having a resolver handle the access to the name attribute. Basically, this would mean having a combination of Bindings#select and a JavaBeanStringProperty.

sarcan
  • 3,029
  • 17
  • 20