Chance to get access to node Position

[ElectricMaxxx]

I know that this issue can or should affect phpcr-odm, but menu items would need that.
Almost all documents can live onsorted in the tree, but would like to have access (from admin) to the position (sort_order). Is there any chance to make that? Or should i extend the MenuNode and add own Attribute for that and handle it in an menu provider?

[dantleech]

Have you tried

$documentManager->getNodeForDocument($menuDocument)->getIndex();

https://github.com/phpcr/phpcr/blob/ea19594c709b28e28d27c71c7e832d3942779ed8/src/PHPCR/NodeInterface.php#L709

But sounds like something we should alow to be mapped (?)

[ElectricMaxxx]

I think the cmf menu provider does something to order the menu entries by that property. When i change the value directly in my (MySQL) DB i get the extpected behavior. What does the phpcr spec sais about that property? I would suggest to create a mapping by the phpcr-odm and add an admin field for that, but the last sounds a little bit insane to me as We normally just map attributes as admin fields. Think the id only is an hidden field. But with having that we could invent some nice drag&drop js action for creating a menu by finding parent and position as the child behind that. (As an extension of the treebrowser)
Btw: Nobody would expect that but that menu shuffeling is easier in ORM with nested sets. You just need to re-count through the new list. =

[ElectricMaxxx]

We forgot one thing: there is no setter as pendant to getIndex(), as it is an result some computing. That computing seems to follow the order property.

When reading through http://www.day.com/specs/jcr/2.0/23_Orderable_Child_Nodes.html i would miss some methods or an mechanism for that NODE_TYPE_MANAGEMENT_ORDERABLE_CHILD_NODES_SUPPORTED node type. When we would have that type and that hasOrderableChildNodes()/orderBefore(String srcChildRelPath, String destChildRelPath) methods, we could manage some ordered behavior out of the phpcr-odm for the ordered child nodes. Many tasks on different places ...

But as conclusion: just mapping the order property or adopting Node::getIndex() sounds wrong when reading the spec.

[dantleech]

You need to use $documentManager->reorder($parentDocument, 'itemA', 'itemB') to place the node named itemA before the node named itemB where both have the same given parent document.

But I think having a read-only property on index might be useful in some cases, but I can't think of any use cases now.

[lsmith77]

orderability of children is a node type feature. it is enabled by default, though it can have a severe impact on performance (but only if you go into the thousands of children).

we effectively "expose" it via the fact that PHPCR ODM ChildrenCollections are ordered (actually we should check if the node type didn't disable child ordering). we do not expose the index as an invididual document mapping.

[ElectricMaxxx]

Using the Index was an idea from @dantleech. And it just works for reading use cases.

Yea @lsmith i understand your answer, but it is for reading too. When i understand it, We have got no chance to have an access on writing or editing a node position and that is my use case. The admin of an CMS wants to be able to edit the order of menu entries. atm the Moment the order is just the order of creation. And that fact is not very sarisfying.

When changing the order of nodes it wouldn' t mean Big performance issues, cause that changes would Happen on write.

The question is: what is the right way to manage that order?
Are there other nodes then menu nodes that would need it? Thin yes, cause blocks as childs should have a possibility to order them later, too. So i would prefere a more global solution, then just hacking into the lifecycle of an menu node. =

[lsmith77]

right now we support changes to the order via the TreeBrowserBundle where you can change the order via drag and drop.

[ElectricMaxxx]

@lsmith77 Ahhh great just tried it and it works on the TreeBrowser on the dashBoard. Is there an option available to do that in the treeBrowser created by the form type?

[dbu]

the form type tree browser is meant to select a parent, not to move and edit, i think. though i think you can have a tree where you can edit in overlay and add children there as well, so either its possible to activate moving, or we should fix that. check the options passed to the one on the dashboard and how its different from the tree used as widget.

[ElectricMaxxx]

uhh found that really old issue, but it is still relevant.

I don't really know if the prior tree-browser implementation did it, but this new one does it not: Moving to a specific position. We actually are able to really move only. That means the way @dbu mentioned in the comment before. But it fees very bad, when droping a node between two items and it is created at the end of the list. Especially when having menu entries where it is really relavant.

Problem: The ResoureRestBundle supports PATCH on move operations only, as the resource components supprots move as the only edit operation on resources.

So i would suggest to open resources for editing now - at least for the position (think it is called index of orderable nodes).

[ElectricMaxxx]

Btw found that the index is the index of same name sibblings, even in phpcr.

And as @lsmith77 explained some years ago, the collection holds the order, hopefully getNodes() too. So looping through the collection and counting until match is the position.

[ElectricMaxxx]

To answer that issue: sorting in Tree, which i currently fix, is the solution. Exposing the value of the position would be a task of phpcr-odm