> If you have the time, I would be really interested to know more
> details about 0.6 changes (especially related to the data model), and
> what improvements it will make it possible for end users or developers.
Basically, we're doing a complete rework of the internal type mapping
system in structr-core and structr-rest.
Type mapping is needed because there are different representations of a
property, f.e. JSON types on the input side, Java types in the
middleware, and database types for storage in Neo4j. For example, take a
JSON: String with ISO 8601 formatting ("2012-10-27T15:41:45+0200")
Java: java.util.Date (Java Object)
Neo4j: long (1351345305)
or boolean as another example:
JSON: true/false/null, "true"/"false"/"", 0/1, "0"/"1", "on"/"off" ...
Java: java.lang.Boolean or boolean
The necessary converting is done automatically in the structr framework,
but up to now, the property definitions in structr were just enums (or
Strings), which are typeless. The type of the property was defined
explicitly by registering a converter (f.e. a
org.structr.core.converter.DateConverter to convert between the
different representations of a date). But to be frank, that's awkward
and not stringent as it could and should be.
After the rework (btw, you can see the ongoing work in the
feature/typed_property_keys branch), there are typed properties in
structr, which will give us f.e. the possibility of early type checking
(in the REST resources), compile-time type-safety in Java, and implicit
Some other changes are related to the data model of structr UI. We found
that the current data model (as of 0.5.3) is incomplete. In detail, it
has the flaw that it's impossible to express that a certain node (y) is
grandchild of a node (a), but not grandchild of another node (b), if
there's a parent node (p) between y and a,b in the hierarchy.
a b <div id="a">
\ / <p>
p always results in y
(with "y" containted in the <p> within the "a" div, but not in the <p>
within the "b" div, was not possible to represent in 0.5.3. The reason
for that is that we currently store only the pageId and the local
(means: relative to the the parent node) position index of a child node
as relationship properties, so the information of (p) being child of (a)
but not (b) gets lost on the way down to (y).
There's no final implementation of the modified data model yet, as we're
experimenting with different approaches. But when it is finished, we
hope to have a complete and flawless page data model, which would allow
us to stabilize the UI and finally go forward to add features. If you
are interested in details, I can share some slides I made to illustrate
Hope to have shed some light on this.
Best regards et ï¿½ bientï¿½t
Axel Morgner ï¿½ a...@morgner.de ï¿½ @amorgner <https://twitter.com/amorgner>
c/o Morgner UG ï¿½ Hanauer Landstr. 291a ï¿½ 60314 Frankfurt ï¿½ Germany
phone: +49 151 40522060 ï¿½ skype: axel.morgner
structr - Open Source CMS and Web Framework based on Neo4j:
structr Mailing List and Forum:
Graph Database Usergroup "graphdb-frankfurt", sponsored by Neo4j:
Das Sport-Sharing-Netzwerk des Deutschen Olympischen Sportbundes (DOSB):