This is mostly for Janne, but I'd appreciate insights from anybody else who has an opinion on this...
I've been digging back into the JSP-tier stuff, and found something that's a little odd. It's a bug, but like most bugs, it's also an opportunity. :) Here's the situation. The re-jiggered AttachmentsTab.jsp that I'm working on, in my local branch, is injected into the normal view template. The view template which has a wiki:PageName tag at the top, which should render the name of the page. What is rendered depends on the current WikiContext, i.e., the contents of the inherited field m_wikiContext. This is all normal stuff, and is how we've always done it. Now, here's the issue. The AttachmentsIterator tag seems to do some mucking around with the current wiki context, and appears to re-assigns the value of it as it loops. In theory this "should" be ok, because it (or its parent IteratorTag?) is supposed to reset it to the original context. I don't completely understand how this works. There seems to be two ways that it's done: via direct manipulation of field m_wikiContext, and possibly also via manipulation of a request-scoped attribute that stores the WikiContext also (ATTR_CONTEXT). What I do know is that when the AttachmentsIterator tag is present, the wiki:PageName at the top of the page is rendering an attachment name, instead of the page name. If I remove the AttachmentsIterator element and its children, the page name is rendered correctly. A couple of observations: - It's quite hard to understand how and when the various WikiTagBase subclasses change the value of field m_wikiContext. Would it be better to hide this field (make it private), and provided accessor/mutator methods to subclasses? This would make state manipulation more transparent. It would also break non-JSPWiki WikiTagBase subclasses (although to be fair I don't think there are likely to be that many). - Same observation about ATTR_CONTEXT. It's very hard to figure out how/why this request attribute is manipulated. - For manipulating the current wikiContext, would a push/pop set of methods be better? For example, when entering an iterator tag, push the context onto a stack. When done, pop to restore the original state. Among other things, this would make problems like this much easier to debug. Thoughts? I'd rather talk this through before writing (and committing) code. Andrew
