This project has retired. For details please refer to its Attic page.
Todo List
Apache Software Foundation > Apache Forrest
 
Font size:      

Todo List

high

  • [code] Please see our Jira issue tracker for tasks to be done. Note that the Todo list below is old. We need someone to move those tasks over to the issue tracker. → open
  • [code] Rework the menu generation system to make it more flexible. See thread Fixing menus → open
  • [code] Define an 'object model' for Forrest sites, in the form of a Cocoon pipeline, that defines - The directory structure of a site - Site metadata (what currently lives in skinconf.xml + gump.xml stuff) - Perhaps site.xml metadata for pages? This info can then be made public to the sitemap (via XMLFileModule attributes) and the stylesheets (through document(cocoon:/...) calls or inlined with source XML). → open
  • [code] Finalise the project-definition DTDs, like status.xml and module.xml; try to come up with a common format with others on community.at.apache.org. → NKB

medium

  • [code] Finish the RSS feed for status.xml. Aggregate status.xml and project.xml to have all needed project data. → NKB
  • [docs] Add stylesheets to render the enhanced status.xml file contents. → open
  • [code] In skinconf.xml, change 'disable-search' to 'enable-search'. → JT
  • [code] Enhance the initial forrest toolbar for Mozilla. See email discussion draft forrest toolbar for Mozilla. → NKB
  • [code] Fix things so docs can be edited in src/*, and have the changes appear immediately in the webapp. Involves creating/using an InputModule for passing 'forrest.skin' and other properties to the sitemap, so we can avoid the @skin@ hack, and a bit of forrest.build.xml hacking. There are some @tokens@ in a forrest-site CSS file that also need some sort of in-place modification. Perhaps a @token@-to-value Transformer could be the same ${variable}-to-value Transformer mentioned in the RT [3]. → open
  • [code] Act on 'Entities in XML docs' RT. I can implement Stefano's suggested solution quite easily, but is such limited functionality worth the cost of introducing a proprietary ${variable} syntax? Maybe.. Best short-term alternative seems to be using the XNI XInclude processor for pre-validation inclusion. → open
  • [docs] A lot of the info on the website is outdated. → open
  • [docs] Using metadata from site.xml, it would at least be possible to indicate how old the doc is, and perhaps indicate its relevance from a small controlled vocabulary. → open
  • [design] Develop a mechanism for supporting legacy URLs. See email discussion - redirects with static sites → open
  • [code] Fix up and integrate the Forrest Maven plugin. → open

low

  • [code] Ensure that PHP-like stuff can be embedded easily in Forrest files and document it. → open
  • [code] Continue the development of the Libre facility - replacement for */book.xml → open
  • [docs] Start a community doc where we list tools such as "code". → open
  • [code] Migrate to a decent schema language, primarily so that we can use namespaces in XML docs, allowing things like XInclude, in-line metadata, in-line SVG, Jelly snippets, or anything else users can make a Transformer for. → open
  • [code] Streamline the process of adding support for new schemas. Ideally we'd have an auto-download system, e.g. 'forrest-update docbook' would fetch and install the Docbook DTDs, create catalog entries, sitemap mods etc. → open
  • [code] Make a CSS Generator and a stylesheet to serialize it to text. → NKB
  • [docs] Add a document about authoring in XML for beginners.. → open