We Keep Coding

JavaFX 8: Separation of model/domain from view

I am just learning JavaFX 8. It seems if you want to display something in a control, say a TableColumn, you need that something to be an instance of ObservableValue, for example, a SimpleStringProperty.
So, in the commonly used Person object, I might have a SimpleStringProperty for "firstName", and then I would be able to use that as the value of TableColumn, like this:
TableColumn<Person, String> firstNameCol =
new TableColumn<Person, String>("First Name");
firstNameCol.setCellValueFactory(
new PropertyValueFactory<Person, String>("firstName"));
But, Person is what I would call a "domain" class -- something that my model would freely refer to and use. I don't want my domain and model layers to be aware of / dependent on the fact that the application is displayed using JavaFX.
Am I right in thinking that the model/domain should be kept pure in that regard? If so, what is the best way to accomplish that using JavaFX? E.g., should I write adapter classes somehow for my domain objects to present them with ObservableValues?

It is certainly wise to keep your domain model pure, and not tie it to any specific framework as you may need to use those objects in other contexts (database storage, exposing them in a REST API, doing batch processing, etc.).
Changing your domain model to use JavaFX properties would add a lot of extra baggage to those classes that you need to avoid in other scenario's.
JavaFX however does have a standard way of dealing with this situation so you can connect your domain model to its controls easily, and it works in a way you already suggested, using adapters from its javafx.beans.property.adapter package.
Using these adapters however won't make your controls respond to values changing in your domain objects like they would with SimpleStringProperty for example.
It will depend on your requirements if that is a problem, if it is however you may consider modifying your domain model objects to add PropertyChangeListener support. This is a relatively light weight change (vs. full JavaFX Properties) and would not make you depend on JavaFX (only on java.beans which is less problematic).
See this answer for a thorough explanation of how to use domain model classes in JavaFX directly: JavaBean wrapping with JavaFX Properties

Why do you want to avoid using any JavaFX class at all?
JavaFX Properties (found in the javafx.beans.property package) are just an extension to the regular JavaBeans properties.
They are part of the JavaFX Properties and Bindings framework, which doesn't depend on the JavaFX Toolkit to have its functionality implemented, nor does it require your application to leverage the JavaFX UI classes in order to build its graphical user interface.
It can therefore be used as a standalone facility anywhere in your code, without having to worry about the model/domain being coupled to this particular implementation of the view.
You should consider the JavaFX Properties and Bindings framework a general utility that is inherently indipendent of the implementation of the view due to its nature, just like is any other general-purpose library (e.g. Guava). You could, for example, switch to a Swing application at any time, while still keep using it.
But if you still prefer to not leverage its functionality when possible, then there's a case when you can actually do so:
if what's being presented isn't going to change (e.g. the state corresponding to the table model in your domain class is immutable), and standard property getters are present, then, as per the PropertyValueFactory documentation:
There is fall-through support for attempting to call get<property>() or is<property>(). If a method matching this pattern exists, the value returned from this method is wrapped in a ReadOnlyObjectWrapper and returned to the TableCell. However, in this situation, this means that the TableCell will not be able to observe the ObservableValue for changes.
Avoid adapters; they are meant to be used with legacy code only that cannot be altered in any way.
Related Posts
JavaBean wrapping with JavaFX Properties
JavaFX Properties Design
Does the use of ObservableList in JavaFX go against Model-View-Controller separation?

The next version (8.6.0 in active dev) of JRebirth will allow to generate these FXJO (javaFX Java Object) from POJO (Plain Old Java Object) by using annotation processor.
Or by directly parsing an ecore file.
It can give you the opportunity to not alter your Business Model with UI related stuff like Properties.

Off-the-shelf UI component for table-to-table field mapping?

I wanted to check with the community if there is any existing off-the-shelf component or library that handles table-to-table field mappings, specifically, defining meta-data for the data fields.
Example (from Salesforce's UI):
Simply put, my inputs would be a list of source fields and target fields, and the UI component should allow the user to map one to the other, or have a source field not map to any target field at all.
Since I've seen this UI component so many times in various corporate systems, now that I need it I wanted to see if it was out there in one form or another before we start building. I'd be particularly interested in C# or Web (JS) oriented solutions, but would take anything for reference.
Thanks!

Static classes, methods, and fields in GWT client

A colleague who coded the client side of a GWT application has essentially made all widgets and their methods and fields static. I am trying to evaluate it's impact.
Based on my reading so far, this has the result of making the javascript objects global for each user's compiled nocache.js file. In terms of drawbacks, this is potentially inefficient in that objects are not created dynamically and freed on demand. Also, it's a major hassle to maintain this code.
Are there any other risks in coding the client this way?

You cannot use your widget in two places in your app: they will keep the last entered data in the lastly used form.
This must be time consuming at startup (page load), since all widgets of the app are created : there is no control on the instant the widget is created
The recommended way is to have a ClientFactory (http://www.gwtproject.org/doc/latest/DevGuideMvpActivitiesAndPlaces.html#ClientFactory) :
Widget lifetime is controlled through this object that decides whether to create a new instance for each widget request or use the same one

Confused: Role of Beans in JSF2 in comparison to classical MVC Controllers

i have a question that is more design and architecture related. I am coming from a classical MVC based background and have to get my hands dirty on JSF2. I read the IBM articles on JSF2 (http://www.ibm.com/developerworks/library/j-jsf1/) and think i understand the overall concept.
I started to get in touch with JSF2 trough ROO. I have the feeling that ROO (maybe this is true for any JSF2-Type App, or maybe not) is making very strange/unclear use of beans. It is in general really not clear to me what the actual role of a Bean is! For example, if i have a view with a form that is for editing a single user-entry, i would initialize the user in a, lets call it UserBean (maybe store in in a member variable) and access this variable trough getters. If i now want to overview all users, i would again render the view in in the UserBean hold a collection of users and again access this collection trough getters. The previous description is actually the way i would do things with jsf. This means i would user the UserBean more as a statefull-service as a controller.
In a typical controller situation i would create for every type of action (list user, edit user, view user, etc) a separate controller, with specific initialized data and this way i would separated the context of the logic by controllers.
I often make use of context specific services, e.g. if i handle user's often an spread over the application, i create a user-service that handles user specific logic that is maybe to complex to be put into the itself. If i now for example look into roo generated Beans, i would find methods that programatically render forms, input fields, labels, that again store list's of users, boolean fields that indicate if data had already been loaded, single user members and a lot of methods that more look like to be put into a UserService (or whatever). I am wondering if this is the way JSF2 is intended to be used, in words: pushing everything that is related to one context into on bean, not making use of service and writing "super-controller-beans" that handle everything.
I don't really know if you get the question right, but what would maybe help me is, a hint to
a very exemplary and commendable example application that makes use of beans the way they where intended to be used in combination with jsf2 features and usecases that for example implement basic CRUD usecases around a given type of entity. (One big confusing point is, that in my case ROO always makes use of AJAX and javascript stuff like Modal-Dialogs to implement CRUD logic. I wonder if with JSF there is a more classical way to to this?[With 'classical' i mean for example URL-Based views and separated views for listing, editing and viewing entities])
a resource that enlightens typical "thats-the-way-the-good-guys-do-it" JSF-Patterns (maybe this is J2EE Patterns?).
Thanks you so much!
Please feel free the push me to concretize specific points if i am not clear!

The link for JSF2 you have posted points to JSF1.2 article. In case you want to start of with JSF2 or JSF I suggest following links.
JSF 2.0 Tutorial # mkYong.com
BalusC JSF blog
Stackoverflow wiki for jsf
I'll suggest start with plain vanilla JSF rather than ROO with JSF to get a hang of JSF.
To answer your question
First link provides you with simple jsf examples, in JSF you can have both ajax based and classical way of submitting form. In JSF 1.x versions ajax was not part and parcel of JSF it was implemented by third party component library mainly RichFaces and PrimeFaces to name few. In JSF2 there is inbuilt support for ajax, this does not apply third party components are no longer required, they still provide some extended features. I'll suggest go through this link to find differences between JSF 1.x and JSF 2.
Patterns I am not aware of as such as specific to JSF apart code can be categorized in model - view - controller. Typical case Person represents model, PersonMangedBean plays role of controller which plays central role of getting data from view(jsp/facelets) and after processing data in bean itself or service beans handles navigation to classic views may be listPersons.xhtml.
JSF managed beans are not "super-controller-beans" handling every thing in that bean. I try to categorize things the way you mentioned i.e. have a service layer where we have all business logic may be EJB or Spring managed bean and it decouples at-least business logic away from view technology JSF whereby it(service) can be reused somewhere else as a library if designed properly.
Tip: JSF is component based framework not an action based and it has lifecycle of its own, do get a grip of that life-cycle will save lots of time and proper understanding of the framework. This link though for JSF 1.x holds good for JSF2 too, for basic understanding of life-cycle.
Hope this helps.

Vaadin portlet dynamic language change

I have an Vaadin portlet wich supports "Multilanguage" that means if an user selects for e.g DE in the liferay portal he will get the German translation of some portlets and if he select another language the portlet will be translated to the selected language. there is a problem, the user can translate the portlet only one time , if he selects another language, the portlet keeps the translated strings of the previous language , and the portlet keeps the old language till the portlets init method is reloaded. is there a way to dynamicaly change the language of the portlets components without losing the curret users state(modifications) ?

There is a pattern for Vaadin component translation that may apply here:
Create a utility method to translate Vaadin Component's caption and description properties. Use ThreadLocal-pattern to make that look like a static method or use dependency injection to make it easier call it from everywhere.
In the translating method store the original translation key (string id) to Component.setData()
On dynamic language change call the method to re-translate the component using the Component.getData property. You can easily iterate through the whole visible UI using the ComponentContainer interface starting from the Window.
For storing multiple translation keys into data-property (for the caption and description separately) create your own class or use Map.
Note also that if you have data coming from the database, this pattern does not help and you have to solve that some other way.