Oh, on a side note: getFinalPageName() moved to WikiEngine. That's where it calls the various PageNameResolvers.
Would it be better to move the wikifyLink and cleanLink code into the resolver code, perhaps make these additional resolvers? I'd have to do a bunch of changes to caller code: about 25 references, not too bad. Also, we could add a "CacheResolver" that simply keeps a cache of all of the strings that have been requested, and the WikiPaths they resolve to. Just a thought. Andrew On Tue, Oct 13, 2009 at 7:57 PM, Andrew Jaquith <[email protected]> wrote: > So, I want to understand this, and I think I'm close. > > If page "HyperlinkToo" exists, JSPWikiMarkupParser will render > "hyperlink too" as: > > "HyperlinkToo" > > ...but if "HyperlinkToo" does not exist, it will render as: > > "Hyperlink too" > > Is that right? It is, in essence, producing different canonical page > names depending on whether the page exists. That is strange. > > It also makes creating (say) a singleton caching WikiPath factory > difficult because you'd need to know whether the page exists (and > hence hold a reference to the ContentManager) before you could figure > out what to canonicalize the path to. > > I expect this is all stuff you considered before -- but want to make > sure I understand before I correct any more unit tests. > > Andrew > > > On Tue, Oct 13, 2009 at 4:33 PM, Janne Jalkanen > <[email protected]> wrote: >>>> A few more clarifying questions: >>>> >>>> - Are page names normalized when stored? I.e., when persisted we >>>> always use the MashedTogetherName? >>> >>> No, we use the result of MarkupParser.cleanLink() [which turns [foo bar] >>> into [Foo bar]. It essentially just capitalizes it and removes illegal >>> characters.] >> >> To clarify: upon store, page names are normalized with cleanLink() (which >> retains spaces). >> >> Upon render, we first check for the new-style-normalized page name >> (cleanLink()), then the old-style normalized page name (wikifyLink()). >> >> /Janne >> >
