Complex configuration

[Pär Dahlberg]

Working with a bit more complex set of properties is a pain right now
I have to say.

In my DiskSpace widget I want the user to be able to monitor a
configurable number of paths and control their order in the widget.
For each path the user should be able to configure a name/description,
a warning threshold, refresh time, icon etc.

Doing this with one level Sequences isn't really working and having a
String Sequence inside another will flatten it on load/save.

I would really like to have built in support for storing Java Beans
with for example XStream. This would then support an unlimited
configuration for each Widget since the developer would create the
class him/herself.

What do you think about this idea?

BTW, I stumbled on issue 35 (http://code.google.com/p/widgetfx/issues/
detail?id=35) when trying to persist the Java Beans as JSON myself :)

[Pär Dahlberg]

BTW, XStream can be found here: http://xstream.codehaus.org/

/Pär

[Michael Bien]

do you want to implement this functionality in java or javafx (since you
mentioned java beans)?

If you stay with java i would recommend JAXB, it is shipped with SE6 and
injects annotated fields directly into java beans.
Marshalling/Unmarshalling is around 5loc each - very simple.

(incremental update is more difficult, this api is best used for full
xml writes/reads - perfect for config IMO)

I always try to stay with JDK apis as long as possible (e.g until there
is a special requirement).

btw. wasn't there special JavaFX script xml language support planed?

(you may get this mail twice.. sorry)

regards,

michael

[mbien]

> If you stay with java i would recommend JAXB, it is shipped with SE6 and
> injects annotated fields directly into java beans.

this sentence makes no sense :/

what I intended do say:
.. it is shipped with SE6 and injects values directly into annotated
fields of java beans and the other way around into xml.

[Zaxxon]

The build Sun gave out at the Adobe MAX conference last week, which is
supposed to be code frozen, just has javafx.data.pull.PullParser for XML
support as far as I can see, so I would expect that’s what we're going to
get in 1.0


Keith

[Stephen Chin]

When we first implemented the persistence support we were somewhat
limited because of the lack of reflection support in the JavaFX
language. They added this in to the most recent drop, so I will see if
I can put together a quick JavaFX XML object serialization library,
which may serve us better long term for persistence of widgets.

Cheers,
--Steve

[Pär Dahlberg]

Sounds good, but with Reflection for JavaFX will there really be need to create a new serialization library?

Michael Bien: I've implemented the config class in Java since I'm doing the config dialog with Matisse and BeansBindings, but of course any class should work... either Java or JavaFX. Wouldn't really make any sense to limit WidgetFX config extensions to just Java :)

/M v h Pär
Welcome to my blog, mostly about programming: http://www.pmdit.se/blog

[Michael Bien]

Pär Dahlberg wrote:
> Sounds good, but with Reflection for JavaFX will there really be need
> to create a new serialization library?
>
> Michael Bien: I've implemented the config class in Java since I'm
> doing the config dialog with Matisse and BeansBindings, but of course
> any class should work... either Java or JavaFX. Wouldn't really make
> any sense to limit WidgetFX config extensions to just Java :)

I know, but look at java bean like this:

public class GLSLElementDescriptor {

@XmlType
@XmlEnum(String.class)
public enum Category { BUILD_IN_FUNC, BUILD_IN_VAR, USER_FUNC, JUMP,
ITERATION, SELECTION, QUALIFIER, TYPE, KEYWORD }

@XmlElement
public final Category category;

@XmlElement(required = true)
public final String tooltip;

@XmlElement(required = true)
public final String doc;

@XmlElement(required = true)
public final String arguments;

@XmlElement(required = true)
public final String type;

/*bean constructor, fields are directly injected*/
public GLSLElementDescriptor() {
category = Category.KEYWORD;
tooltip = null;
doc = null;
arguments = null;
type = null;
}

}

I think you can't do it much simpler or in fewer loc since its already
100% declarative. JavaFX has no annotations which makes mapping to xml a
bit difficult (but of course still possible). What I thought was
actually to use plain java beans to hold the xml data and jaxb behind
the scenes rather than using another third party lib for the task. I am
really no JFX expert but I see no problem to access those beans from
JavaFX script, or is there a hidden show stopper I am not aware of?

I mean how hard would it be for JAXB to inject data directly into JavaFX
bytecode... (in future)

regards,

michael

[Pär Dahlberg]

That's true, it looks like it's very easy. I've not actually used either XStream or JAXB for more than a simple test so I'm not really biased towards either one of them and I do agree that if it's in the platform it gets priority.

For a small/quick Widget development I still think JavaFX classes must be supported. Someone new coming from a script environment and having to deal with both Java and JavaFX in one of the tutorials might put them off. Anyway, I don't know if it's easy or not to inject what's need into the bytecode, but if it's doable then it's great of course :)

Right now we are (hopefully) only a few days away from the JavaFX 1.0 release so I'm looking forward to see what new features can be used. Perhaps it's only a few lines of code extra to add XML support to the current Property persistence when it's released...

/M v h Pär
Welcome to my blog, mostly about programming: http://www.pmdit.se/blog