[MAGNOLIA-6098] Rendering of areas broken if the page and one of its areas has the same name. Created: 26/Feb/15  Updated: 03/Mar/15  Resolved: 27/Feb/15

Status: Closed
Project: Magnolia
Component/s: configuration
Affects Version/s: None
Fix Version/s: 5.4

Type: Bug Priority: Neutral
Reporter: Michael Mühlebach Assignee: Michael Mühlebach
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MAGNOLIA-6102 Create additional AreaFilterListener ... 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   
Scenario

In the ftp-sample-site we have a page definition named "main".
It contains several areas like "stages", "navigation", "extras" and "main".
We trigger the rendering of just the area main with the following URL: http://localhost:8081/ftl-sample-site/ftl-searchResult~mgnlArea=main~

Expected behaviour

Just the specified area is rendered.

Actual behaviour

The complete page is rendered.



 Comments   
Comment by Jan Haderka [ 26/Feb/15 ]

Junit test?

Comment by Michael Mühlebach [ 27/Feb/15 ]

Added an additional test for the special case.

Comment by Roman Kovařík [ 27/Feb/15 ]

info.magnolia.rendering.listeners.AreaFilteringListener#getTemplateDefinition may return null.
And could you also correct the comment since I wrote it incorrectly?

Comment by Jan Haderka [ 27/Feb/15 ]

tiny typo in the javadoc " * Therefore comparing references is to weak for comparing definitions."

Comment by Mikaël Geljić [ 27/Feb/15 ]

Hey there, I indeed closed this ticket after QA because direct area rendering works again as expected
— but why do I have the feeling this equality check is utterly useless?

I just shrank it to the following code, and it works exactly the same, including tests.

return content != null && targetArea.equals(content.getName())
  1. Is there any case where we still want to render the area when that piece of code is *not* true?
    • e.g. can the area node name be different from its definition name?
  2. Say we want to render a page whose node is itself named "main", area rendering wouldn't work because it would wrongly match on page node
    • e.g. /magnoliaAuthor/main~mgnlArea=main~
    • agreed, that revs things up one level further, but that's the only case where I thought getting the parent page definition id made sense (like we do now).
Comment by Roman Kovařík [ 02/Mar/15 ]
  1. Not every area has its own node!
Comment by Mikaël Geljić [ 03/Mar/15 ]

Thanks Roman, I forgot about this one!
That said, this means it's currently not tested, and readability of that line is a mental challenge — and it was getting worse when I tried adding null checks in there, as per your previous comment.

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