[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 |
| Comment by David Bullock [ 16/Mar/05 ] |
|
db> RE: One issue here is what to do with exceptions 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 |
| Comment by Philipp Bracher [ 17/May/06 ] |
|
MgnlContext is now used |