...
Now, one way to possibly get around this problem... which might even allow the WSF solution to work, is to write my own widget for use in the navigation web form. This ability was introduced in v2.1. Unfortunately, I don't think there's any way to do this that doesn't involve root access to the Alfresco server and/or further modifications to the Alfresco codebase. It would be great if I could drop a javascript widget definition into the Data Dictionary and it would be automatically incorporated into the web form, but this doesn't seem to be possible. Every new project we work on points to more insufficiencies in the WCM. I really don't want to have to extend the WCM for each project. Especially for the MITAA project, since then I'd have to keep updating the Alfresco instance of the consulting company they hired to do their website design.
---
In the extreme case, the navigation files would not even be per-folder, but per-file. That leads to:
Way #3: Everything is a Rendition
Every single page in the site would be the rendition of a web form, and that the xml form instance data for each such page will contain the navigation information for that page. So the navigation information is completely distributed throughout the website. In terms of the experience for content authors, it would be largely seamless, since all navigation metadata about an asset would be local to the asset. The only discipline necessary is that content authors would need to make sure to use a web form to create (navigable) content, even if the content doesn't have any structure to it other than just the HTML or JSP. So there'd be at least one "catch-all" web form like "Navigable Content" with two fields: "Title" and "Content", where Content would be one large TinyMCE block of HTML or JSP.
There are a few complications with navigation. One is that there still needs to be an idea of "default" page per folder. In this case, we'd probably just rely on the web server's idea of what makes a page the default. (For example, look for an item named "index.html" or "default.htm" or "index.jsp", etc.) Next, there's no intrinsic way to include a list of optional external links in this system. This can be solved by having a web form called "External Links For This Folder" which would make a special "external.xml" file containing title and url pairs for these links.
Just as in Way#2, then, the navigation for content under a folder level would therefore consist of: the titles of all the non-default pages in this folder, the titles of the default pages in each subfolder of this folder, as well as the optional external links.
So, this almost seems like the best solution. Unfortunately, I haven't talked about what it's like for the webapp designer. First of all, it essentially doubles the size of the webapp. If you want to be able to include "foobar.jsp" in your navigation, there will be a "foobar.jsp.xml" file in (for example) the same directory which contains all the same information. One way around this is to not actually have the "foobar.jsp" rendition, and just write a webapp filter which processes "foobar.jsp" as a request for the internal content in "foobar.jsp.xml". That may bring on more complications than we'd like, and it looks bizarre.
But the thing which really makes this a possible no-go: the webapp has to do a whole lot of work to build the sitemap. It needs to parse all these xml files... one per navigation entry, and each xml file is large. If the webapp can be written so it stops parsing the xml once it reads the navigation information (and that the navigation information is the first thing in the file) and does not go on to parse the entire content element, maybe that is not a huge deal. Still, it's a lot of file accesses to build up the static sitemap. If this takes too long on the production server, we could be in trouble. There may be ways around this, too: try to jimmy the web form to maintain a single global navigation xml file; alter the deployment step so this file is built at deploy time and published to the server; or something else, maybe.
---
So I'm at an impasse, or at least a dilemma. Right now, I have to decide between One Page Per Folder or the Hybrid Structure or Everything Is A Rendition (since the WSF Solution is basically unworkable). Or I have to come up with another solution entirely (maybe a navigation file per page? but that only brings up more problems!!!). Help!