[MAGNOLIA-317] Idiom for acquiring a HierarchyManager could be simplified. Created: 16/Mar/05  Updated: 23/Jan/13  Resolved: 17/May/06

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 2.1 Final
Fix Version/s: 3.0 RC1

Type: Improvement Priority: Minor
Reporter: David Bullock Assignee: Boris Kraft
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

n/a


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   

This idiom crops up quite a lot in client code:

HierarchyManager hm = new HierarchyManager(request);

try

{ Session t = SessionAccessControl.getSession(request,repository); Node rootNode = t.getRootNode(); hm.init(rootNode); }

catch (Exception e) {}

It would be easier on clients if one had something like:

// plus, xf http://jira.magnolia.info/browse/MAGNOLIA-316

public static HierarchyManager acquire(HttpServletRequest request, String repositoryId)

{ Session t = SessionAccessControl.getSession(request,repository); return acquire(request, t); }

public static HierarchyManager acquire(HttpServletRequest request, Session t)

{ requrn acquire(request, t.getRootNode()); }

public static HierarchyManager acquire(HttpServletRequest request, Node n)

{ return new HierarchyManager(request, n); }

In such a way, the idiom could be simplified to:

HierarchyManager hm = HierarchyManager.acquire(req, "website");

One issue here is what to do with exceptions ... the old idiom swallows them, yielding a partially-initialized HierarchyManager which would NullPointer for some future requests (eg. createContent) but succeed for others (eg. setMetaData). It is probably best to throw exceptions from the factory methods.



 Comments   
Comment by Boris Kraft [ 16/Mar/05 ]

RE: One issue here is what to do with exceptions
We could introduce an empty or null-Object for the HM. See GoF Null-Object Pattern.

Comment by David Bullock [ 16/Mar/05 ]

db> RE: One issue here is what to do with exceptions
bk> We could introduce an empty or null-Object for the HM. See GoF Null-Object Pattern

Sounds reasonable, provided there is some value in having a partially-constructed HierarchyManager. I can't speak to that just yet until I have more experience with the API.

My first thought about it from a general perspective is that a LameHierarchyManager implementation would have to throw a documented IllegalStateException [or a RepositoryException amounting to the same thing] from at least some of its methods. It would also have expose a method to test which state the HierarchyManager is in (the idea of being 'connected' seems appropriate). One wonders whether it could be prevented from entering that state in the first place.

When attempting to acquire a HierarchyManager in the context of a JSP page, one probably wants to know as early as possible whether to return an HTTP:

404, in case of a PathNotFoundException
403, in case of an AccessDeniedException
401, in case of a LoginException
502 (bad gateway), in case of all other RepositoryExceptions

Comment by Philipp Bracher [ 17/May/06 ]

MgnlContext is now used

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