incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.r.jaqu...@gmail.com>
Subject WikiContext switcheroos in Tag classes
Date Thu, 21 May 2009 00:11:06 GMT
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

Mime
View raw message