[MAGNOLIA-2741] Different behavior of uuidLink Control in STK and 'classic' templating Created: 21/May/09 Updated: 12/Oct/09 Resolved: 12/Oct/09 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | core |
| Affects Version/s: | 4.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Giancarlo Berner | Assignee: | Philipp Bärfuss |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Mg 4.1, Tomcat 6, Windows XP, Firefox |
||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Template: |
|
||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||||||
| Date of First Response: | |||||||||||||||||
| Description |
|
There is a strange behavior with the uuidLink control and I am not sure if I am missing something here. If I use dialog /modules/standard-templating-kit/dialogs/paragraphs/links/stkInternalLink within the STK and I select a link, it stores the UUID of the link, which is actually what I expect. However, if I copy the dialog into the regular templating folder and use it with one of my own paragraphs, the dialog stores the PATH of the selected link. This leaves me with the impression that the dialog's SAVE might act different than the SAVE within the STK or there is something else I am missing (perhaps a property to select to store PATH or UUID). |
| Comments |
| Comment by Philipp Bärfuss [ 25/May/09 ] |
|
There should not be any difference. At least I am not aware of any. This is a normal dialogs. |
| Comment by Philipp Bärfuss [ 25/May/09 ] |
|
Seams not to be an issues. Please comment if I am wrong. |
| Comment by Giancarlo Berner [ 25/May/09 ] |
|
We first noticed this at a training using the 4.1 .war file you provided me. Then I redone the whole template/paragraph and got the same issue. The trainees had 4.01 and got the same issues. I attached
|
| Comment by Giancarlo Berner [ 25/May/09 ] |
|
The Template Definition |
| Comment by Giancarlo Berner [ 25/May/09 ] |
|
The template script as simple JSP file. |
| Comment by Giancarlo Berner [ 25/May/09 ] |
|
A snapshot taken with the Tools/JCR Browser, showing the created web page and the Paragraph node, both on the same level. |
| Comment by Philipp Bärfuss [ 29/May/09 ] |
|
Reopen as requested. |
| Comment by Giancarlo Berner [ 08/Jul/09 ] |
|
A few days ago I downloaded the EE 4.1 and installed it. I did some testing on cms:editbar and noticed, that it creates the paragraph node (contentNodeName attribute) on the same hierarchy level as the Web page. Interesting is that when I MOVE the paragraph node as a child page of the Web page, then everything works fine. New paragraphs are added correctly and the content is displayed as expected. Obviously this bug is still in the latest 4.1 build. It blocks development of paragraph lists. |
| Comment by Giancarlo Berner [ 08/Jul/09 ] |
|
BTW: The NEW bar stores the paragraph list node (contentNodeCollection) at the right position. So only the cms:editbar seems to have this problem. |