Controls with Values [was Possible additions to JavaFX to facilitate forms and validations]

[Mario Torre]

Il giorno 07/dic/2011, alle ore 00:28, Jim Graham ha scritto:
> OK, time for a graphics nerd to put his foot in his mouth and try to sound less than dim-witted in a Controls discussion... <crosseyed smiley>
> 
> It feels like the proposals here are heading in the direction of FX owning the data.  That's great for applications that never do anything other than display the data on a single FX-capable screen, but I can imagine more complicated applications for whom screen display is only one of their goals/modes of use.
> 
> Consider an application that is meant to view a database.  When displaying it on the screen the data needs to be managed by both the database and the FX nodes, but the FX nodes don't really own the data there, that is just one way to manage that part of the interaction. Meanwhile there may be back end modes of this application that run as network services to manage updates to this database through web or net services.  It may have a command line interface for batch processing. It may have an HTML5 back end for displaying on devices that don't yet support FX.  It may want to support displaying the database on multiple screens or in multiple views on the same screen.
> 
> I don't think the proposals for Controls to "be" properties will necessarily preclude any of that, but would it be more natural for Controls to talk to a property that is owned by the application?  In other words, TextFoo is a Control that takes a Text property, it is not itself a text property.  And when you do data binding, you would be binding the raw properties that the application manages, not the Control nodes.  And when you have multiple views on the same data open then you don't have to have a cloud of self-important nodes that all believe they own the data that needs to be coordinated so they all make sure they own the same version of the data as each other...
> 
> Or am I off base here?
> 
> 			...jim


No, I think you're perfectly right.

In my experience, strict decoupling of Data and View is very important, and the more we make the API capable of easily (and I put accent on *easily*) handle this decoupling, the more you avoid mistakes that pollute renderer.

I've seen plenty of example like this, where Swing was misused to the extreme (don't block the EDT mantra anyone?).

After all, the View should not really care about the data, it only should know how to represent it graphically, so all the binding should go via properties that the application knows how to manage and the view knows how to render, but indeed the view should never own the data.

Cheers,
Mario
---
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

http://www.ladybug-studio.com

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/