Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of andrew.r.jaquith@gmail.com
 designates 209.85.221.115 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=XOdkhqHWlKC96ilHT0rmMdNke1EVHVBzyWcZFQrvlEJGzh2onJRMeLebc1Bktb2VDK
         sg1EH82WUMC1LELSRrZWa1zX3N8f640S1bd+u2y99ktvyN9N32hndBNza2/Smp04G6uj
         wEMpSFJiyGbkMPIWow/KnSHi0RMzXC15Ao0cw=
MIME-Version: 1.0
Date: Wed, 20 May 2009 17:11:06 -0700
Message-ID: <b90102160905201711l7344b1c2k8a20672e8bff218b@mail.gmail.com>
Subject: WikiContext switcheroos in Tag classes
From: Andrew Jaquith <andrew.r.jaquith@gmail.com>
To: jspwiki-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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