Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
This is an plugin for Eclipse IDE, that can be used
with the other freemarker plugins.
The FM help plugin. Read the README.txt!
Logged In: YES
I have the received the missing attachment if somebody is
interested... now I "attach" it.
Logged In: YES
Hm. This is cool. We could make this available from the plugin
download page. Of course, it'd be best if the plugin download
contain the docs as well - altough that'd make it a cca. 850K
What would *really* be cool is if the contributor of the plugin
would contribute code for automatically generating the
toc.xml file. That way we could keep the plugin in sync with
Yeah, I have discuess about this with the guy. The site.xml
and the XDocBook XML together need to be used to generate
the toc.xml. Thus, I guess that toc.xml should be generated as
the part of the ant "dist" task, so the FreeMarker release has
to contain only those few Eclipse specific files (as toc.xml),
since the docs HTML-s are already there), and then a simple
copy-ing into the Eclipse plugins directory, and you have the
help. Like the REAME.txt of the patch sais it, anyway.
BTW the guy said he may wants to do this toc.xml generator
stuff. (I haven't heard about him since then.)
Logged In: YES
I am back from my vacation. Finally I have a clue about the
building of the documentation.
I am hoping this week we can have the generation of the toc.xml.
Patch to the Freemarker source tree.
Hi guys. I uploaded a patch to the Freemarker source tree,
that now generates the table of contents for the Eclipse plugin.
Please check it out.
Seems that everybody is bussy, but we didn't forget about the
patch... thank you for it. I hope somebody (I?) will check it
out in a few days.
This is always a problematic thing to say, since you don't get
paymet for your work here, but (IMO) we can't integrate the
patch in its current state. It needs some refactoring, because
its too much a copy-pase-and-hack now, which degrades the
understandability and thus the ease of maintenance on long
term. In the site module, it should use the site.xml directly as
input file (and not as a project file). In the docgen module you
should use freemarker Ant task, an not a modified version of
the docgen trasnform task.
As of the output, I think it would be better if the site ToC is
not displayed in the toc-tree, only a "WWW site" link that
points to the site index.html. (If it would prevent the indexing
of all site HTML files, then the "WWW site" node should be a
folder). So the point is that on the top level there should be
only two nored: "WWW Site" and "Manual". Why? The Manual
folder is very confusing above the list of "Manual shortcuts",
since the you doesn't use the 2 level hiearachy of the site toc
(and the ToC tree would by too deep if you do...), but show
only the 2nd level entries falttened. Anyway, the flattened site
ToC in itself is confusing, and the site HTML-s already have a
good hierarchical toc side-bar.
Also, it would be better to say user to copy the "docs" dir
itself into the help pulgin dir (rather than copying its
*content* into the "html" dir), so that subdir is should not be
"html" but "docs".
Refactored version of the patch to the source tree. Please read Refactor-note.txt.