On more thing... the hard part in an evaluator tool is defining the data-model. On freemarker-online that's a very limited due to security reasons. In a tool that the user runs on his on computer though, it's not a problem to allow defining values in Groovy for example.
Saturday, January 7, 2017, 6:45:10 PM, Daniel Dekany wrote: > Saturday, January 7, 2017, 4:37:12 PM, Denis Bredelet wrote: > > [snip] >>> These are some getting started examples. What are your ideas about the >>> final product? >> >> I am thinking of adding a « main » function in the FreeMarker JAR >> to load a template and a model (as XML or properties, that is why I >> showed the link). Then create a separate JAR with the UI to load the >> template and datamodel from the filesystem or define a datamodel >> interactively, and save the processed template in a file. > > The whole functionality, even if it's only a console app with a main > method, should be in a separate jar, and certainly even in a separate > project (like we have freemarker-site, freemarker-docgen, and then we > could have freemarker-tester or something). Since dependency > management has become common place, it's considered to be a bad > practice to overpack your jar-s. In fact, something that we consider > to do in FM3 is exploding freemarker.jar into submodules (like > freemarker-servet.jar, etc.). Back then it was more practical to make > a big monolithic jar, but times are changing. > > Also, a separate project (again, still under the umbrella of > FreeMarker and Apache) means that you can do releases independently of > the FreeMarker (the engine) project releases. > > Also note that "main" methods in a library are seen as security > problems nowadays. We already have a bunch of them in freemarker.jar, > and I'm just waiting for the right moment to get rid of them. > > So, yeah, I say, separate jar, separate project. > -- Thanks, Daniel Dekany
