<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to javafx</title><link>https://sourceforge.net/p/ximl/wiki/javafx/</link><description>Recent changes to javafx</description><atom:link href="https://sourceforge.net/p/ximl/wiki/javafx/feed" rel="self"/><language>en</language><lastBuildDate>Sun, 09 Dec 2012 06:32:05 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/ximl/wiki/javafx/feed" rel="self" type="application/rss+xml"/><item><title>WikiPage javafx modified by aappddeevv</title><link>https://sourceforge.net/p/ximl/wiki/javafx/</link><description>&lt;pre&gt;--- v7
+++ v8
@@ -10,7 +10,7 @@
 
 Skin
 
-Skin is just like the builder concept. Its quite the duplicate. Skin class names are normally set via CSS but they can also be set programmatically. Since a Skin is like a Builder, and a Builder is a MarkupExtension, XIML supports defining skins in the XIML markup file since its just another property on a control.
+Skin is just like the builder concept. Its quite the duplicate. Skin class names are normally set via CSS but they can also be set programmatically. Since a Skin is like a Builder, and a Builder is a MarkupExtension, XIML supports defining skins in the XIML markup file since its just another property on a control. Its not clear how useful this is yet because you still need to bind various properties or handlers to those on the control class itself.
 
 Event Handling
 
&lt;/pre&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">aappddeevv</dc:creator><pubDate>Sun, 09 Dec 2012 06:32:05 -0000</pubDate><guid>https://sourceforge.net6b3d6f771a61905d818a711f974b586ebed00a30</guid></item><item><title>WikiPage javafx modified by aappddeevv</title><link>https://sourceforge.net/p/ximl/wiki/javafx/</link><description>&lt;pre&gt;--- v6
+++ v7
@@ -7,6 +7,10 @@
 Builders
 
 You do not need to use any builders in the XIML markup. You can instantiate objects with static factory methods or arguments as you would expect. I don't see any need for builders in JavaFX and thinks its tremendous class clutter. I started producing support for builder instantiation patterns but its not working yet in case you do indeed want to use a builder as a direct object in the markup. One problem I was having is that the builders themselves cannot be created using new either so its almost like a double layer to contend with.
+
+Skin
+
+Skin is just like the builder concept. Its quite the duplicate. Skin class names are normally set via CSS but they can also be set programmatically. Since a Skin is like a Builder, and a Builder is a MarkupExtension, XIML supports defining skins in the XIML markup file since its just another property on a control.
 
 Event Handling
 
&lt;/pre&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">aappddeevv</dc:creator><pubDate>Sun, 09 Dec 2012 06:31:18 -0000</pubDate><guid>https://sourceforge.net60946b6be420109349837b7aded63f260fb0ffb7</guid></item><item><title>WikiPage javafx modified by aappddeevv</title><link>https://sourceforge.net/p/ximl/wiki/javafx/</link><description>&lt;pre&gt;--- v5
+++ v6
@@ -21,3 +21,7 @@
 Root Instance
 
 XIML has a concept of a root instance so you can "initialize" the object that is calling the XIML loader. This allows a whole host of scenarios that are quite nice. Either XIML can create a root node and return it to you from the markup file or you can use it for initialization and your object can subclass a Node class. This means its easier to make your objects seamlessly look like built-in JavaFX Node classes.
+
+Code Generation
+
+I have not had time to work on this. But you can code generate out the object graph into java code and use aspects to have a tree partial class setup.
&lt;/pre&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">aappddeevv</dc:creator><pubDate>Sat, 08 Dec 2012 16:08:52 -0000</pubDate><guid>https://sourceforge.neta9c1709e1ae51d783b75ff955fa619298c67eab3</guid></item><item><title>WikiPage javafx modified by aappddeevv</title><link>https://sourceforge.net/p/ximl/wiki/javafx/</link><description>&lt;pre&gt;--- v4
+++ v5
@@ -13,3 +13,11 @@
 You can provide an event handler for your bind target (which could be separate bind target or the root object of the object graph). Just specify the method name for the OnAction (or whatever) method. The hookup is created in a type converter that converts between a string and an EventHandler. The call is performed through reflection when the action occurs. The method name is checked against the bind target (which is often the root object).
 
 Right now the action will be looked up on the bind target, but its fairly trivial to allow the target of the method call to be set to another object with conversion of the argument along the way. I'll get that code out shortly.
+
+Tree Navigation
+
+There is a tree helper class that allows you to properly navigate down a tree. It has to check default property annotations and the like to do this properly because javafx controls do not consistently story their children in the children list.
+
+Root Instance
+
+XIML has a concept of a root instance so you can "initialize" the object that is calling the XIML loader. This allows a whole host of scenarios that are quite nice. Either XIML can create a root node and return it to you from the markup file or you can use it for initialization and your object can subclass a Node class. This means its easier to make your objects seamlessly look like built-in JavaFX Node classes.
&lt;/pre&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">aappddeevv</dc:creator><pubDate>Sat, 08 Dec 2012 16:08:17 -0000</pubDate><guid>https://sourceforge.net80b2d090e28f1792e08bc6cee4e7f95abda892a0</guid></item><item><title>WikiPage javafx modified by aappddeevv</title><link>https://sourceforge.net/p/ximl/wiki/javafx/</link><description>&lt;pre&gt;--- v3
+++ v4
@@ -1,4 +1,14 @@
-There is a javafx vocabulary which is the now becoming the primary vocabulary for XIML  because I am using javafx right now for a project.
+There is a javafx vocabulary which is the now becoming the primary vocabulary for XIML  because I am using currently using javafx for a project.
+
+Binding
+
+The start of a general vocabulary binding mechanism similar to WPF is in place. Underneath, it supports JavaFX properties or POJO properties as source objects and JavaFX properties as targets only. It saves you time and energy. I found the JavaFX binding models very complex compared to jgoodies. I believe that you could reduce the class clutter significantly with redesign but that's another conversation.
+
+Builders
+
+You do not need to use any builders in the XIML markup. You can instantiate objects with static factory methods or arguments as you would expect. I don't see any need for builders in JavaFX and thinks its tremendous class clutter. I started producing support for builder instantiation patterns but its not working yet in case you do indeed want to use a builder as a direct object in the markup. One problem I was having is that the builders themselves cannot be created using new either so its almost like a double layer to contend with.
+
+Event Handling
 
 You can provide an event handler for your bind target (which could be separate bind target or the root object of the object graph). Just specify the method name for the OnAction (or whatever) method. The hookup is created in a type converter that converts between a string and an EventHandler. The call is performed through reflection when the action occurs. The method name is checked against the bind target (which is often the root object).
 
&lt;/pre&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">aappddeevv</dc:creator><pubDate>Sat, 08 Dec 2012 14:53:13 -0000</pubDate><guid>https://sourceforge.net4a5ed15aec651e20ce853c7ae653830bbdac3fb7</guid></item><item><title>WikiPage javafx modified by aappddeevv</title><link>https://sourceforge.net/p/ximl/wiki/javafx/</link><description>&lt;pre&gt;--- v2
+++ v3
@@ -1,3 +1,5 @@
 There is a javafx vocabulary which is the now becoming the primary vocabulary for XIML  because I am using javafx right now for a project.
 
 You can provide an event handler for your bind target (which could be separate bind target or the root object of the object graph). Just specify the method name for the OnAction (or whatever) method. The hookup is created in a type converter that converts between a string and an EventHandler. The call is performed through reflection when the action occurs. The method name is checked against the bind target (which is often the root object).
+
+Right now the action will be looked up on the bind target, but its fairly trivial to allow the target of the method call to be set to another object with conversion of the argument along the way. I'll get that code out shortly.
&lt;/pre&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">aappddeevv</dc:creator><pubDate>Sun, 25 Nov 2012 17:50:57 -0000</pubDate><guid>https://sourceforge.net14e82019c2a6342ba52e3a484748a72f5eb6f022</guid></item><item><title>WikiPage javafx modified by aappddeevv</title><link>https://sourceforge.net/p/ximl/wiki/javafx/</link><description>&lt;pre&gt;--- v1
+++ v2
@@ -1,3 +1,3 @@
 There is a javafx vocabulary which is the now becoming the primary vocabulary for XIML  because I am using javafx right now for a project.
 
-You can provide an event handler for your bind target (which could be separate bind target or the root object of the object graph). Just specify the method name for the OnAction (or whatever) method. The hookup is created in a type converter that converts between a string and an EventHandler. The call is performed through reflection when the action occurs.
+You can provide an event handler for your bind target (which could be separate bind target or the root object of the object graph). Just specify the method name for the OnAction (or whatever) method. The hookup is created in a type converter that converts between a string and an EventHandler. The call is performed through reflection when the action occurs. The method name is checked against the bind target (which is often the root object).
&lt;/pre&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">aappddeevv</dc:creator><pubDate>Sun, 25 Nov 2012 17:25:42 -0000</pubDate><guid>https://sourceforge.net307d55cbf971ee7de3d0f2b4f7e45d905f13ef58</guid></item><item><title>WikiPage javafx modified by aappddeevv</title><link>https://sourceforge.net/p/ximl/wiki/javafx/</link><description>There is a javafx vocabulary which is the now becoming the primary vocabulary for XIML  because I am using javafx right now for a project.

You can provide an event handler for your bind target (which could be separate bind target or the root object of the object graph). Just specify the method name for the OnAction (or whatever) method. The hookup is created in a type converter that converts between a string and an EventHandler. The call is performed through reflection when the action occurs.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">aappddeevv</dc:creator><pubDate>Sun, 25 Nov 2012 17:01:58 -0000</pubDate><guid>https://sourceforge.net6fbabb4e69591612edd882c08c8787ab3ba424eb</guid></item></channel></rss>