The XULUX DataProvider API is located at in the core API in the package org.xulux.api.dataprovider. The API is created to present the frontend with a generic way of processing data, without explicitly caring about where the source of the data is, how it should be stored and how it should be handled.
The picture below shows the main parts of the API and will be explained in more detail below
The dictionary is the core that connects gui fields to data. For now it is based on setting values in beans using getters and setters or using a bit more magic than that. The dictionary should end up in a set of interfaces that together make the dataprovider part of the frontend API.
The dictionary class is the main entry for connecting all magic that is related to dictionary processing. In the final version of the dataprovider, the Dictionary class, will be the container for dictionary processing.
The dictionary handler is the xml parser that constructs a valid dictionary out of that xml. You can already write your own handler, but since no other means of customizing the workings of the dictionary system is yet available, it has no use to create your own handler yet.
You can create your own parser that will create dictionary entries.
You can also drive the dictionary programatically, but this scebario should be rare.
The lower part of the graphical overview is the actual DataProvider API. Currently there is no support for customfields and mappings, at least to the extend that they cannot be triggered from xulux.
The mapping groups fields together and gives information about how
to set and get data. Also it takes care of aliases, so you can limit
the exposure of your data or make it different.
The current implementation of a Mapping is BeanMapping, which takes
care of storing and getting data from the specified bean(s).
Through the dictionary.xml you can currently specify how to get and
set the data in case there is no default constructor and no default
getters and setters.
Nyx has a interface that represent fields, which to gui can use to get and set data through. The IField interface already represents partially what the dataprovider API will consist off. Currently there is only one implementation of the IField interface used and that is BeanField, which handles setting and getting data in beans. Since the dataprovider API still needs to be defined, not storage of the actual beans is done. You have to handle that manually in form rules.
Converters are responsible for converting an object to a representable format for the user. Converters also take care of converting the user input back to the object in a bean. This used with objects like Date, Double and Integer.