freemarker-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <>
Subject Re: [FM3] Opinions about the package structure?
Date Fri, 03 Mar 2017 05:54:43 GMT
Thursday, March 2, 2017, 6:41:35 PM, Woonsan Ko wrote:

> On Wed, Mar 1, 2017 at 2:09 PM, Daniel Dekany <> wrote:
>> You can see the current FM3 package structure here:
>> Some explanation follows.
>> As it was discussed earlier, FM2 freemarker.core and FM2
>> freemarker.template were united under org.apache.freemarker.core, and
>> then to decrease the size of the resulting package, I have moved out
>> the aspects that don't depend on core internals into their own
>> subpackages (model, templateresolver, outputformat, etc.). So we have
>> ended up with a org.apache.freemarker.core that is actually
>> substantially smaller than FM2 freemarker.core was, also it has
>> smaller and more focused public API than FM2 freemarker.template has.
>> The name directly after org.apache.freemarker denotes the module. So
>> you can see 3 modules from the current package structure: core, dom,
>> and servlet (which will be freemarker-core.jar, freemarker-dom.jar,
>> etc., after we have converted to multi module project, but we haven't
>> yet). There will be more actually, like "test" for common JUnit test
>> utilities (not a published API), and core-java8 for Java 8 support,
>> and who know what else.
>> Any opinions/insights?
> Looks good to me! Thanks!

I wonder if freemarker-dom should be separate, or part of
freemarker-core under o.a.f.core.model.impl.dom. If freemarker-dom is
separate, then if the user wants to use it, they will have to plug it
into the DefaultObjectWrapper manually. Something like:

  new Configuration.Builder(Configuration.VERSION_3_0_0)
                  new DefaultObjectWrapper.Builder(Configuration.VERSION_3_0_0)

or with Properties syntax:

  objectWrapper = DefaultObjectWrapper( \
     3.0.0, \
     typeHandlers=[ org.apache.freemarker.dom.DomTypeHandler ])

That's how users could add special treatment for their
application/domain specific types too (and if we switch to MOP-s, then
just replace objectWrapper with mopImplementationProvider or whatever
it will be called). So we are consistent with the idea that
freemarker-core only contains (and is aware of!) things that are
related to the core (minimal) functionality. But then, what are the
practical implications of the users? They get a freemarker-core.jar
that's a few kilobytes leaner, but in exchange they have to go through
the above extra configuring if they want to use the DOM wrapping. I'm
not sure if it worths it... mostly because I don't now how many
percentage of the users are using DOM wrapping. Certainly it's a
minority, a few percentages maybe, but it's just a wild guess.

 Daniel Dekany

View raw message