[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: |
|
||||||||
| Issue Links: |
|
||||||||
| Template: |
|
||||||||
| Patch included: |
Yes
|
||||||||
| Acceptance criteria: |
Empty
|
||||||||
| Date of First Response: | |||||||||
| Description |
|
The patch for 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). |
| Comment by Ondrej Chytil [ 17/Apr/12 ] |
|
Solved with |
| Comment by Danilo Ghirardelli [ 17/Apr/12 ] |
|
I'm sorry but this issue is related to |
| 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. |
| 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. |