[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: PNG File JCRBrowserSnapshot.png     PNG File TemplateDefinition.png     File exerciseGuide.jsp    
Issue Links:
Cloners
is cloned by MAGNOLIA-2885 editBar: if a non-existing singleton ... Closed
relation
is related to MAGNOLIA-2811 contentNodeName parameter of editBar ... Closed
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 then reproduced the complete template/paragraph and got the same behavior (paragraph node is on the root).

I attached

  • Template Definition
  • Template JSP
  • Snapshot of JCR Browser
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.

Generated at Mon Feb 12 03:39:39 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.