I would like to see raw Neo4J graph created by stuctr. Does strctr-ui provide the Neo4J web admin ? If not how could I embed it in order to view Neo4J nodes and relationships ?
at the moment, the only way to see structr's nodes and rels through the Neo4j webadmin is to duplicate the db directory and use it with a standalone Neo4j server (or simply stop structr and start Neo4j server pointing to the same db directory).
Although, there are three future options to use structr and Neo4j server at the same time:
a) Include Neo4j server as a structr module
b) Include structr as a Neo4j server plugin
c) Use the HA setup to replicate between two repos
All solutions require a certain amount of hacking, but all of them thould be doable. We'll add some of these options to our roadmap, as it is a often-requested feature.
Please note, that all structr modules are currently undergoing a serious refactoring, including a change to the data model of structr UI, so we need to wait for this being finished in order to go for the integration with Neo4j webadmin.
Cheers
Axel
Am 27.10.2012 00:59, schrieb Seb:
> Hi,
> I would like to see raw Neo4J graph created by stuctr. Does strctr-ui provide the Neo4J web admin ?
> If not how could I embed it in order to view Neo4J nodes and relationships ?
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.
Le samedi 27 octobre 2012 10:59:46 UTC+2, Axel Morgner a écrit :
> at the moment, the only way to see structr's nodes and rels through the > Neo4j webadmin is to duplicate the db directory and use it with a > standalone Neo4j server (or simply stop structr and start Neo4j server > pointing to the same db directory).
> Although, there are three future options to use structr and Neo4j server > at the same time:
> a) Include Neo4j server as a structr module
> b) Include structr as a Neo4j server plugin
> c) Use the HA setup to replicate between two repos
> All solutions require a certain amount of hacking, but all of them thould > be doable. We'll add some of these options to our roadmap, as it is a > often-requested feature.
> Please note, that all structr modules are currently undergoing a serious > refactoring, including a change to the data model of structr UI, so we need > to wait for this being finished in order to go for the integration with > Neo4j webadmin.
> Cheers
> Axel
> Am 27.10.2012 00:59, schrieb Seb:
> Hi,
> I would like to see raw Neo4J graph created by stuctr. Does strctr-ui provide the Neo4J web admin ?
> If not how could I embed it in order to view Neo4J nodes and relationships ?
> 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.
Sure.
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 date property:
JSON: String with ISO 8601 formatting ("2012-10-27T15:41:45+0200")
Java: java.util.Date (Java Object)
Neo4j: long (1351345305)
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 converters.
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
| </p>
y </div>
<div id="b">
<p>
y
</p>
</div>
(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 the problem.
> Le samedi 27 octobre 2012 10:59:46 UTC+2, Axel Morgner a �crit :
> Hi Seb,
> at the moment, the only way to see structr's nodes and rels
> through the Neo4j webadmin is to duplicate the db directory and
> use it with a standalone Neo4j server (or simply stop structr and
> start Neo4j server pointing to the same db directory).
> Although, there are three future options to use structr and Neo4j
> server at the same time:
> a) Include Neo4j server as a structr module
> b) Include structr as a Neo4j server plugin
> c) Use the HA setup to replicate between two repos
> All solutions require a certain amount of hacking, but all of them
> thould be doable. We'll add some of these options to our roadmap,
> as it is a often-requested feature.
> Please note, that all structr modules are currently undergoing a
> serious refactoring, including a change to the data model of
> structr UI, so we need to wait for this being finished in order to
> go for the integration with Neo4j webadmin.
> Cheers
> Axel
> Am 27.10.2012 00:59, schrieb Seb:
>> Hi,
>> I would like to see raw Neo4J graph created by stuctr. Does strctr-ui provide the Neo4J web admin ?
>> If not how could I embed it in order to view Neo4J nodes and relationships ?
> -- > You received this message because you are subscribed to the Google > Groups "structr" group.
> To post to this group, send an email to structr@googlegroups.com.
> To unsubscribe from this group, send email to > structr+unsubscribe@googlegroups.com.
> To view this discussion on the web, visit > https://groups.google.com/d/msg/structr/-/C-4Zi54F2w8J.
> For more options, visit https://groups.google.com/groups/opt_out.
Thanks for your feedback. I have began to play
with feature/typed_property_keys branch.
I would be very interested by your slides.
Since Structr is template less, I would also like to understand how do you
currently (or plan) to deal with rendering of dynamic data elements, for
example rendering a list of users stored in Neo4J.
In classical CMS, I would write a component with a template containing a
loop, put a user collection in this component instance context in order to
render it, and attach it to a HTML DOM element.
I have played with the backoffice and understood how you do Neo4J nodes +
relationaship mapping to HTML elements, but with non HTML node, how do you
manage this in Structr ? Don't you have to use templates or views to
specify how to render these data ?
On Sun, Oct 28, 2012 at 1:28 AM, Axel Morgner <a...@morgner.de> wrote:
> 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.
> Sure.
> 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 date property:
> JSON: String with ISO 8601 formatting ("2012-10-27T15:41:45+0200")
> Java: java.util.Date (Java Object)
> Neo4j: long (1351345305)
> 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 converters.
> 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
> | </p>
> y </div>
> <div id="b">
> <p>
> y
> </p>
> </div>
> (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 the
> problem.
> Hope to have shed some light on this.
> Best regards et à bientôt
> Axel
> Le samedi 27 octobre 2012 10:59:46 UTC+2, Axel Morgner a écrit :
>> Hi Seb,
>> at the moment, the only way to see structr's nodes and rels through the
>> Neo4j webadmin is to duplicate the db directory and use it with a
>> standalone Neo4j server (or simply stop structr and start Neo4j server
>> pointing to the same db directory).
>> Although, there are three future options to use structr and Neo4j server
>> at the same time:
>> a) Include Neo4j server as a structr module
>> b) Include structr as a Neo4j server plugin
>> c) Use the HA setup to replicate between two repos
>> All solutions require a certain amount of hacking, but all of them thould
>> be doable. We'll add some of these options to our roadmap, as it is a
>> often-requested feature.
>> Please note, that all structr modules are currently undergoing a serious
>> refactoring, including a change to the data model of structr UI, so we need
>> to wait for this being finished in order to go for the integration with
>> Neo4j webadmin.
>> Cheers
>> Axel
>> Am 27.10.2012 00:59, schrieb Seb:
>> Hi,
>> I would like to see raw Neo4J graph created by stuctr. Does strctr-ui provide the Neo4J web admin ?
>> If not how could I embed it in order to view Neo4J nodes and relationships ?
>> --
> You received this message because you are subscribed to the Google Groups
> "structr" group.
> To post to this group, send an email to structr@googlegroups.com.
> To unsubscribe from this group, send email to
> structr+unsubscribe@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/structr/-/C-4Zi54F2w8J.
> For more options, visit https://groups.google.com/groups/opt_out.
> --
> You received this message because you are subscribed to the Google Groups
> "structr" group.
> To post to this group, send an email to structr@googlegroups.com.
> To unsubscribe from this group, send email to
> structr+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
We recently finished the refactoring, and feature/typed_property_keys was merged into develop.
Before we can release 0.6, we still need to fix some other things, esp. structr-ui.
Am 28.10.2012 10:19, schrieb S�bastien Deleuze:
> Thanks for your feedback. I have began to play > with feature/typed_property_keys branch.
> I would be very interested by your slides.
> Since Structr is template less, I would also like to understand how do > you currently (or plan) to deal with rendering of dynamic data > elements, for example rendering a list of users stored in Neo4J.
> In classical CMS, I would write a component with a template containing > a loop, put a user collection in this component instance context in > order to render it, and attach it to a HTML DOM element.
> I have played with the backoffice and understood how you do Neo4J > nodes + relationaship mapping to HTML elements, but with non HTML > node, how do you manage this in Structr ? Don't you have to use > templates or views to specify how to render these data ?
This is accomplished by using dynamic components (View, RemoteView and Component classes).
For View and RemoteView, you can simply use a Cypher statement to be executed at runtime (View for queries to the local database, RemoteView connects to a remote Neo4j database). The rendering process then loops through the result list and applies the markup contained in the respective View node.
So if you like, you could call the inner markup of a View/RemoteView node a template. From the markup nodes, you can access the result list objects (f.e. the User nodes) with placeholder statements like ${data.name} (this would call user.getProperty("name") internally f.e.).
Another, more complex way to handle dynamic content in structr are Component nodes. They are kind of dynamic data objects, and their data fields are equal to the content of certain child elements (Content nodes) which are tagged with the data_key property, which equals the field name.
Please note that all this stuff is still pretty much experimental and subject to frequent future changes, and therefore, there's no official documentation available.
> On Sun, Oct 28, 2012 at 1:28 AM, Axel Morgner <a...@morgner.de > <mailto:a...@morgner.de>> wrote:
>> 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.
> Sure.
> 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 date property:
> JSON: String with ISO 8601 formatting ("2012-10-27T15:41:45+0200")
> Java: java.util.Date (Java Object)
> Neo4j: long (1351345305)
> 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 converters.
> 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
> | </p>
> y </div>
> <div id="b">
> <p>
> y
> </p>
> </div>
> (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 the problem.
> Hope to have shed some light on this.
> Best regards et � bient�t
> Axel
>> Le samedi 27 octobre 2012 10:59:46 UTC+2, Axel Morgner a �crit :
>> Hi Seb,
>> at the moment, the only way to see structr's nodes and rels
>> through the Neo4j webadmin is to duplicate the db directory
>> and use it with a standalone Neo4j server (or simply stop
>> structr and start Neo4j server pointing to the same db
>> directory).
>> Although, there are three future options to use structr and
>> Neo4j server at the same time:
>> a) Include Neo4j server as a structr module
>> b) Include structr as a Neo4j server plugin
>> c) Use the HA setup to replicate between two repos
>> All solutions require a certain amount of hacking, but all of
>> them thould be doable. We'll add some of these options to our
>> roadmap, as it is a often-requested feature.
>> Please note, that all structr modules are currently
>> undergoing a serious refactoring, including a change to the
>> data model of structr UI, so we need to wait for this being
>> finished in order to go for the integration with Neo4j webadmin.
>> Cheers
>> Axel
>> Am 27.10.2012 00:59, schrieb Seb:
>>> Hi,
>>> I would like to see raw Neo4J graph created by stuctr. Does strctr-ui provide the Neo4J web admin ?
>>> If not how could I embed it in order to view Neo4J nodes and relationships ?
> We recently finished the refactoring, and feature/typed_property_keys
> was merged into develop.
> Before we can release 0.6, we still need to fix some other things, esp.
> structr-ui.
> Am 28.10.2012 10:19, schrieb Sébastien Deleuze:
> Thanks for your feedback. I have began to play
> with feature/typed_property_keys branch.
> I would be very interested by your slides.
> Since Structr is template less, I would also like to understand how do
> you currently (or plan) to deal with rendering of dynamic data elements,
> for example rendering a list of users stored in Neo4J.
> In classical CMS, I would write a component with a template containing a
> loop, put a user collection in this component instance context in order to
> render it, and attach it to a HTML DOM element.
> I have played with the backoffice and understood how you do Neo4J nodes
> + relationaship mapping to HTML elements, but with non HTML node, how do
> you manage this in Structr ? Don't you have to use templates or views to
> specify how to render these data ?
> This is accomplished by using dynamic components (View, RemoteView and
> Component classes).
> For View and RemoteView, you can simply use a Cypher statement to be
> executed at runtime (View for queries to the local database, RemoteView
> connects to a remote Neo4j database). The rendering process then loops
> through the result list and applies the markup contained in the respective
> View node.
> So if you like, you could call the inner markup of a View/RemoteView node
> a template. From the markup nodes, you can access the result list objects
> (f.e. the User nodes) with placeholder statements like ${data.name} (this
> would call user.getProperty("name") internally f.e.).
> Another, more complex way to handle dynamic content in structr are
> Component nodes. They are kind of dynamic data objects, and their data
> fields are equal to the content of certain child elements (Content nodes)
> which are tagged with the data_key property, which equals the field name.
> Please note that all this stuff is still pretty much experimental and
> subject to frequent future changes, and therefore, there's no official
> documentation available.
> Cheers
> Axel
> Best regards,
> Sébastien Deleuze
> On Sun, Oct 28, 2012 at 1:28 AM, Axel Morgner <a...@morgner.de> wrote:
>> 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.
>> Sure.
>> 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 date property:
>> JSON: String with ISO 8601 formatting ("2012-10-27T15:41:45+0200")
>> Java: java.util.Date (Java Object)
>> Neo4j: long (1351345305)
>> 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 converters.
>> 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
>> | </p>
>> y </div>
>> <div id="b">
>> <p>
>> y
>> </p>
>> </div>
>> (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 the
>> problem.
>> Hope to have shed some light on this.
>> Best regards et à bientôt
>> Axel
>> Le samedi 27 octobre 2012 10:59:46 UTC+2, Axel Morgner a écrit :
>>> Hi Seb,
>>> at the moment, the only way to see structr's nodes and rels through the
>>> Neo4j webadmin is to duplicate the db directory and use it with a
>>> standalone Neo4j server (or simply stop structr and start Neo4j server
>>> pointing to the same db directory).
>>> Although, there are three future options to use structr and Neo4j server
>>> at the same time:
>>> a) Include Neo4j server as a structr module
>>> b) Include structr as a Neo4j server plugin
>>> c) Use the HA setup to replicate between two repos
>>> All solutions require a certain amount of hacking, but all of them
>>> thould be doable. We'll add some of these options to our roadmap, as it is
>>> a often-requested feature.
>>> Please note, that all structr modules are currently undergoing a serious
>>> refactoring, including a change to the data model of structr UI, so we need
>>> to wait for this being finished in order to go for the integration with
>>> Neo4j webadmin.
>>> Cheers
>>> Axel
>>> Am 27.10.2012 00:59, schrieb Seb:
>>> Hi,
>>> I would like to see raw Neo4J graph created by stuctr. Does strctr-ui provide the Neo4J web admin ?
>>> If not how could I embed it in order to view Neo4J nodes and relationships ?
>>> Thanks
>>> --
> You received this message because you are subscribed to the Google Groups
> "structr" group.
> To post to this group, send an email to structr@googlegroups.com.
> To unsubscribe from this group, send email to
> structr+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
