[MAGNOLIA-316] HierarchyManager can become immutable with respect to most of its fields. Created: 16/Mar/05  Updated: 25/Nov/13  Resolved: 25/Nov/13

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 2.1 Final, 3.0.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: David Bullock Assignee: Sameer Charles
Resolution: Outdated Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

n/a


Issue Links:
relation
is related to MAGNOLIA-1442 Review the HierarchyManager interface 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)
Date of First Response:

 Description   

HierarchyManager exposes the following mutator methods:

  • void setStartPage(Node) [unused!]
  • void init(Node)
  • void init(Node, AccessManager)
  • void setAccessManager(AccessManager)

In all cases where these methods are used, they are used:

a) ONCE only, and
b) on a HierarchyManager instance which is assigned to a local variable in the same method

It would better reflect the manner in which HierarchyManager is used if the fields 'startPage', 'workspace', and 'accessManager' were set only via the constructor, and the mutator methods removed.



 Comments   
Comment by Sameer Charles [ 16/Apr/07 ]

DefaultHierarchyManager can be constructed together with 'startPage', 'workspace', and 'accessManager' but I would vote against to make it
immutable since methods like setAccessManager(AccessManager) could come in handy if you wanna impersonate HierarchyManager

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