I took a better look at the Maven plugin, and realized that it's just the plugin we inherited from the original donation, from before Siegfried's donation. So no wonder it's so different (it doesn't even depend on freemarker-generator-base). So what to do about this duality? The Maven plugin is an example of "data-driver" from "template-driven VS data driven output generation", which I brought up in last mail too. There's one output file per JSON data file, and many JSON-s share the same template. So if the freemarker-generator-base will support both approaches, we are one big step closer to have a consistent product with two interfaces (CLI and Maven).
On Sat, Jul 4, 2020 at 1:10 AM Daniel Dekany <daniel.dek...@gmail.com> wrote: > It should be in https://freemarker.apache.org/generator/. You will need > to commit/push into > https://github.com/apache/freemarker-site/tree/asf-site for that. (See > https://freemarker.apache.org/committer-howto.html#updating-homepage) > > We need to generate the web pages somehow though. I saw you try to do that > with Maven "site", but personally, I can't imagine that it can be tweaked > to generate reasonable output. Not sure how others see this. Maven "site" > is basically the Maven model dumped into HTML pages, and "reports" like > even the log of the Rat run etc. Dozens of menus and sub-pages for details > users mostly don't care about. The actual content users do care about is > stuffed under "About", and from there it's not properly navigable or > searchable, as apparently it's assumed to be a single page. I know back > then you didn't want to use the tool that's used both for the main web site > and for the FreeMarker documentation, but I think that's the most > economical solution currently (and then we also have common styling, and > common place to fix whatever technical issues), so please reconsider that. > (I can help setting that up, of course.) > > Now, some more difficult-to-address problematic things. My problem is that > these just weren't concluded. Discussion just died. To be concluded can > even mean that other PMC members say we should step over these, even if I > disagree. But these should be understood, and considered. So, these are: > > - Design/architectural doubts that are probably not realistic to > address much later: > - Currently, data sources are just URL-s (locations), and templates > are meant to call tool API-s to parse them. As I said back then, one > consequence is that then, you can't put parsed data into the data-model > shared by all templates (i.e., via -m/--data-model). Because, you have > no > convenient/concise way to load the actual (parsed) data, instead you > have > to "program it" in FTL, because the assumption was that you only want > to do > that in templates anyway. Furthermore, as I saw it just now, > --data-model > actually supports some ad-hoc way of parsing the data pointed by a > data-source-like URL, as JSON, YAML, maybe some more. Here's an example > of > that: `-m config=env:///DB_CONFIG#mimetype=application/json`. So there > is a > need actually. But compared to what you can do in templeats, it's > totally > different, and of course very restrictive. I was also looking for a less > "programmatic" way of loading data because even doing it in templates is > not very friendly as it is. (For ultimate flexibility you might need > program logic for sure, but certainly not just to grab a worksheet from > an > Excel file.) We also should have a POC for loading from a less file > centric > data source, like from a DB with a SQL query, to see if the concept > works. > - Not sure what's with template-driven VS data driven output > generation. Data driven is when you generate one output file per some > data > unit (like per JSON file, or per DB record), and all is transformed by a > common template. How would that look currently in freemarker-cli? > - The Maven plugin provides very different functionality than the CLI. > The original concept was that they are just two interfaces to the same > product. That was also brought up, and I don't think it was addressed much, > like, why you disagree, if you do, or what's going on. Anyway, regarding > what we have now. The naming implies that, as both are "FreeMarker > Generator", just one is "CLI", and the other is "Maven". But as far as I > see, they are two different "products" really, focusing on different use > cases. So, if it stays like this, then some of them have to be renamed at > least. Or I don't know what others think we can do. (Then it's still > somewhat weird to release them together.) > > (I have also run through the CLI documentation, and found a lot of less > fundamental things to address, but I don't want to overload the thread.) > > Also, if the project is released mostly as it is now, what will we promise > regarding backward compatibility? What do we communicate about the > matureness of the project? > > On Wed, Jul 1, 2020 at 8:29 AM Siegfried Goeschl < > siegfried.goes...@gmail.com> wrote: > >> Hi folks, >> >> I'm pretty much finished with the stuff I would like to have for the >> first public release but there is a still a lot of work ahead >> >> * FREEMARKER-148 [freemarker-cli] Make usage of "DataSources" more >> "Freemarker" like >> * FREEMARKER-150 [freemarker-cli] Setup "freemarker-generator" web site >> * Setup the release process (Daniel, I guess I need some help here) >> * An iteration of reviews and discussions >> >> Some thought along the line >> >> * I would like to finish FREEMARKER-148 this week >> * Daniel, any suggestion where to host the public website? >> >> Thanks in advance, >> >> Siegfried Goeschl >> >> > > -- > Best regards, > Daniel Dekany > -- Best regards, Daniel Dekany
