[MAGNOLIA-1352] HierarchyManager should be an interface (testing and delegating) Created: 07/Feb/07  Updated: 23/Jan/13  Resolved: 07/Aug/07

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: None
Fix Version/s: 3.1 M2

Type: Improvement Priority: Major
Reporter: Magnolia International Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: File HierarchyManager.java.diff     File Tree.java.diff    
Issue Links:
relation
is related to MAGNOLIA-1322 Differed storage of worklow expressions Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MAGNOLIA-1442 Review the HierarchyManager interface Sub-task Closed Sameer Charles  
MAGNOLIA-1443 Extract interfaces for Content and No... Sub-task Closed Magnolia International  
MAGNOLIA-1444 Review ContentRepository/SessionStore Sub-task Closed Magnolia International  
MAGNOLIA-1445 Refactor the Tree class so that its g... Sub-task Closed Magnolia International  
MAGNOLIA-1454 Refactor SaveHandlerImpl and SaveHandler Sub-task Closed Philipp Bärfuss  
MAGNOLIA-1484 Refactor/remove HierarchyManagerWrapp... Sub-task Closed Magnolia International  
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   

In order to ease testing, and to allow easier change of behaviour like "deferred saving in hierarchy manager" ( see MAGNOLIA-1322), we could maybe make HierarchyManager an interface.



 Comments   
Comment by Magnolia International [ 07/Feb/07 ]

Am currently going in that direction with the interface HierarchyManagerWrapper in the magnolia-module-workflow-deferred-storage branch. This could be generalized for Magnolia 3.1

Comment by Philipp Bracher [ 08/Feb/07 ]

In the we make interfaces for Content and NodeData too

Comment by Oliver Lietz [ 10/Feb/07 ]

While you are working on HierarchyManager, Content and NodeData: can you remove the page/website related terms? I couldn't find any useful documentation for the Magnolia internal stuff and working with sources only, maybe other developers are confused by this nomenclature. Would be nice if this classes are more abstract in meaning of terms and node handling.
Seems like I'm unable to create/save simple custom node types properly. Content always tries to add mix:versionable even it's already defined in my custom node type definition. And how should one handle nodes which shouldn't be versioned? What is the purpose to wrap everything in Content and NodeData? Should I work with session directly instead?

Comment by Oliver Lietz [ 14/Feb/07 ]
  • change wording from page to more generic content/node
  • extract new method Tree#getUniqueLabel(String label) from Tree#createNode(String label, String itemType) to make it available in subclasses of Tree
Comment by Magnolia International [ 02/Apr/07 ]

applied patch for Tree(except I made the new method protected, as per your usecase) and HierarchyManager (except for the rename of the setStartPage method which is deprecated anyway)

Comment by Magnolia International [ 02/Apr/07 ]

The HierarchyManager interface is now in the new info.magnolia.api package. The implementation is still in info.magnolia.cms.core but has been renamed to DefaultHierarchyManager

Comment by Philipp Bracher [ 06/Apr/07 ]

In my opinion it is very important to use in magnolias core more jcr-api than magnolia-api.

  • We should implement a Node, Property, Session implementing the jcr interfaces and wrapping jcr object
  • similar to what we do in Content and NodeData
  • adding mainly the mangolia security to the wrapped node
  • this allows to use any kind of upcoming jcr framework, utilities
  • The classes Content and friends will wrap this MgnlJCRNode and not handle any security
  • The Content, NodeData are used
  • for compatibility
  • convenience (can be improved)
Comment by Magnolia International [ 18/Jun/07 ]

Will move the HierarchyManager interface back to info.magnolia.cms.core for now. Expect new package structure for 3.2, maybe along with some new/removed/renamed methods

Comment by Magnolia International [ 07/Aug/07 ]

done since a while. improving the interface itself is another task.

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