[MGNLDATA-131] Optionally use the name field only for new nodes, and avoid back-renaming. Created: 12/Aug/11  Updated: 26/Apr/12  Resolved: 25/Apr/12

Status: Closed
Project: Magnolia Data Module (closed)
Component/s: None
Affects Version/s: 1.6.3
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Danilo Ghirardelli Assignee: Jan Haderka
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File oneWay.patch    
Issue Links:
dependency
depends upon MGNLDATA-130 Error while renaming sub-items. Closed
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Date of First Response:

 Description   

The patch for MGNLDATA-130 opened a few other logical problems: in the code of GenericDataAdminTree, if the node is renamed, the dialog "nameField" property is read and the corresponding property is set with the new node name, or worse, a new "name" property is created with the new node name, even if it was not present in the beginning.
This is not always the desired behaviour, because the name used in the tree may have spaces and special characters removed, but the node data inside the node can have spaces and special characters.

Logically speaking, I may want a field that is strongly coupled with node name, which is the current intention of the code, so whether I edit it in the tree or in a dialog it stays synchronized on both sides. And in this case we should alter the data save handler to write the name field just like the name used in the tree (spaces and special chars removed/escaped), to be perfectly consistent.

On the other side I may simply want a name field that is just used once to give a reasonable name to new nodes, just to avoid the 0, 00, 01, etc which usually have no meaning for the end user. This value should be used either once at creation or each time that value change, but only in the nodeData->name direction and never in the opposite one.

What do you think? I'm asking something too complex? I'd do this adding a "oneWayNameField" boolean in the dialog configuration, making GenericDataAdminTree check also for this before renaming, and making saveHandler check for this when saving the node, and changing the name value accordingly (leaving as is or using the tree name also for the node data value).

Attached a simple patch for GenericDataAdminTree change. If there is a node data "oneWayNameField" set as true, the node name field is not changed when the node is renamed.



 Comments   
Comment by Danilo Ghirardelli [ 29/Aug/11 ]

This issue is expecially annoying because there is no way to "solve" it locally by subclassing the existing GenericDataAdminTree... Unfortunately the "renameNode" method of GenericDataAdminTree calls the super method with the same name: if I extend the class I can't call in any way the "renameNode" method of AdminTreeMVCHandler, but I can call only the "renameNode" method of GenericDataAdminTree (which is the one I want to replace) or copying the entire renameNode from AdminTreeMVCHandler (which I don't exactly like as solution).
In java there is no super.super...

Comment by Ondrej Chytil [ 17/Apr/12 ]

Solved with MGNLDATA-130.

Comment by Danilo Ghirardelli [ 17/Apr/12 ]

I'm sorry but this issue is related to MGNLDATA-130 but NOT a duplicate of that, and it's not in any way resolved with MGNLDATA-130. Can I ask you to re-read this?

Comment by Ondrej Chytil [ 17/Apr/12 ]

Re-opening, sorry Danilo, wrong issue number in my notes and no double-check.

Comment by Danilo Ghirardelli [ 17/Apr/12 ]

Would you also mind re-assigning it to someone that will eventually take a look?

Comment by Jan Haderka [ 25/Apr/12 ]

The whole reason for existence of the name property and it being kept in sync with node name is to allow some more complex queries where you can't mix calculated props such as jcr:path or jcr:name with node properties. Not keeping value of name property in sync w/ node name would defy this purpose.
If you need to keep original name or some other user friendly name of each data item, you are free to add such properties and handle them as appropriate.

Comment by Danilo Ghirardelli [ 26/Apr/12 ]

Ok, but then there is still something missing in the process. Take for example the online demo, go to the "Company" menu and check the "Big-Flower-Inc" node. If you open that, the name property is set to "Big Flower Inc" (with spaces), and the node name is "Big-Flower-Inc" (with hypens). This means that the node name and the name property are already out of sync.

If you change the node name from the tree, the name property is correctly updated (and with hypens, just like the node name), but if you open the dialog for the element and change the name, i.e. writing spaces instead of hypens, you will see that the node name will be update with hypens, but the name property will be left with spaces. Also happens when creating a new element in the tree, not only in editing. I'd suggest that if the desired behaviour is to have them always in sync, you should change the SaveHandler of the data nodes and force a jcrPath escape when saving the name property. Jackrabbit queries may have different results when the property is saved with or without spaces (or better, with or without jcrPath escaping), depending also on the indexing configuration.

Since this is the current behaviour, I thought that keeping the name property really in sync was just a "nice" feature, and I proposed to make it optional, but at this point I think you should really fix the saveHandler to make them equals.

Generated at Mon Feb 12 05:11:40 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.