[MAGNOLIA-363] Refactoring AdminTree so that you can customize /reuse the trees Created: 02/May/05  Updated: 17/Mar/09  Resolved: 03/May/05

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

Type: Improvement Priority: Major
Reporter: Philipp Bärfuss Assignee: Philipp Bärfuss
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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   
  • Registering tree handlers
  • Registering more than one handle per repository (name <> repository)
  • supporting workspace
  • template pattern for saving, creating, ... (OnPreSave ..)


 Comments   
Comment by Philipp Bracher [ 03/May/05 ]

Use Store.registerTreeHandler(name, class) to register a Subclass of AdminTree.

AdminTree is following the MVC but is still one class.

Subclasses can take influence through overriding of the operations without knowing to mutch about the tree-control.

The servlet calls the tree handler:

AdminTree treeHandler = Store.getInstance().getTreeHandler(handlerName, request);
String command = treeHandler.getCommand();
String view = treeHandler.execute(command);
String htmlString = treeHandler.renderHtml(view);

The AdminTree is still bound to the JCR repositories

Comment by Philipp Bracher [ 04/May/05 ]

I abstracted a general MVCServlet and MVCHandler. They are also used in the dialog refactoring. This brings some rules inside the admin servlets.

see javadoc for details.

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