[MAGNOLIA-3080] Cleanup conundrum between FreemarkerHelper and FreemarkerConfig Created: 15/Feb/10  Updated: 23/Jan/13  Resolved: 12/Mar/10

Status: Closed
Project: Magnolia
Component/s: core, freemarker
Affects Version/s: None
Fix Version/s: 4.3

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

Issue Links:
causality
is causing MAGNOLIA-3190 Freemarker: incomplete configuration ... Closed
dependency
depends upon MAGNOLIA-2533 FactoryUtil$ObservedObjectFactory sho... Closed
depends upon MAGNOLIA-2553 FactoryUtil: should return a proxy ob... Closed
depends upon MAGNOLIA-3011 ObservedComponentFactory.newInstance(... Closed
is depended upon by MAGNOLIA-1469 Make Freemarker more configurable thr... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty

 Description   

Now that Components returns proxies for observed objects, and that ObservedComponentFactory is able to return a default implementation for non-existing nodes (at least for concrete classes), we can finally cleanup the mess between those 2 components.



 Comments   
Comment by Magnolia International [ 15/Feb/10 ]

next step: fix dependency between MagnoliaObjectWrapper and FreemarkerConfig

Comment by Magnolia International [ 16/Feb/10 ]

If anything, we could now merge these two classes (thus FreemarkerHelper would become observed)

  • it would probably eliminate the need to subclass freemarker.template.Configuration and the need for the ConfigDelegating* inner classes
  • it might create unnecessary clutter in its interface
Comment by Magnolia International [ 12/Mar/10 ]

Fine for now - much better than it was. We still need a slightly awkward set of wrappers for freemarker.Configuration but it's now documented and seems cleaner.

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