Discussions of the listLinks() method, continued from WikiRPCInterface:

I think we need something like array listLinks( string pageName ) so that we could do things like "please print me this page and all pages that it links to".


MahlenMorris: listLinks() would be very handy, especially since different Wiki technologies use different syntaxes for links.

I've been thinking about how to handle the "this page and all pages that it links to" issue. I was thinking of a web interface where you pick a starting page, and then it displays all the linked-to pages, user selects some of them, page shows their children, and so on, gradually building up a set of pages until the user is done, and the page results from that. Certainly there are places in Ward's Wiki where i wish i could do that. This may be more complicated to use than it's worth, though.

JanneJalkanen: listLinks() is now a part of API, as of 1.6.12. I'm saving putPage() for 1.7.x branch. :-)

MahlenMorris: On the listLinks() method:

  • I think differentiating between a generic external link URL and a image link would be good, since I may not be aware exactly what types of links you consider allowable images. Then I could possibly pull the inlined image down for offline inclusion as well. So maybe an additional type for images that this Wiki allows to be inlined.
  • If the intent of this API is in some way to make it useful even beyond JSPWiki (which I think would be a very good intent), then one thing it would be useful to have here is some way of finding this link in the processed HTML page. Currently for my printing page, for example, I have some very JSPWiki specific code that looks for links and, if this a link is for a page that is in the aggregated page, i replace the link with a reference to an anchor within the aggregate page. Thus, if you had both the WikiUsers and JanneJalkanen page in the aggregate, the link to JanneJalkanen in the WikiUsers page now moves you to the JanneJalkanen part of the aggregate, rather than the JanneJalkanen page on the web.

So some way of finding the link in a more generic way would be good. I'm thinking that just providing the HREF string that I should expect to see from a getPageHTML() call would do the trick; then I could search the HTML for the link, and replace it with my link. So for example, the record for this link would be MahlenMorris, 0, Wiki.jsp?page=MahlenMorris.

  • If a page is linked to twice in a page, is it listed twice in the returned array? I'm not sure if I want it to be or not, I just want the spec to define this behavior. Listing it twice is good, it lets you know precisely what links are available. The caller can always fold duplicates together on it's own.
  • I'm getting the nagging feeling in the back of my head that I'd also want to know the Wiki Server URL that this goes to (if it's a Wiki page). Yes, I do, because in the offline version the non-local pages need to point back the real Wiki server, and the href above doesn't contain that. But I think that info more properly belongs in a getSystemInfo() call of some sort.
  • I think a string might be a better type indicator than an int. Less interpretation.

JanneJalkanen: Good points. I'll make a note of them and mull this one over a bit more.

25-Feb-2002: The current (26022002) CVS version has now these added. The "type" parameter is now a string - returning either "local" or "external". There is also a "href" -parameter, but be warned that it's not working as expected in case of pages that don't exist.

Local references (using footnotes) should work okay, but you might have to edit the HTML to make sure they're unique. Hm. Should these be listed too?

MahlenMorris: Unfortunately I can't get the JSPWiki code to compile on my server (a Windows 98 machine), and yes, I use Ant and all that daily at work (suffice to say that during the process of trying to compile JSPWiki, I ordered Windows XP). But from looking at the code, I'd say that yes, footnotes should be listed too, and have their own type.

Since I have to find the links and mangle them to make the printing work, any difference in the way that the link should be treated would be very helpful. And again, since the URL's might look quite different from other Wiki's supporting this API, all the hints I can get help. You do realize that you're designing a cross-WikiEngine API, right? And you realize how cool that is? I'd be thrilled if the Hula code could be used with more than one WikiEngine.

Hum? Odd that you can't compile - I've managed to compile JSPWiki repeatedly on my Win98 laptop. It could be that I'm using cygwin.

Anyway, yes, "I'm vaguely aware of what I'm doing" - to paraphrase a crazy cop from way back :-).

Lets see what would be the proper way to handle different link types:

The problem with footnotes and other links within a document is that the best way to do it would be to just simply make them unique across the Wiki (i.e. use something like <A NAME="WikiRPCInterfaceListLinks-footnote1">. This way you don't really have to care about them at all and not even list them, since in every case you'll see the correct link.

Hm. From HTML it's obvious if something has been inlined (<IMG> -tag is a good giveaway =), but from the wiki text itself?

Different Wikis tend to handle images in different ways, and sometimes generate them dynamically as the HTML is created.

Perhaps just a type of "inline" would be sufficient?

I think the current method of using "external" as the type identifier is quite okay?

The HTML poses a problem. JSPWiki uses by default relative URIs, simply to ease things such as mirroring. However, it's trivial to make JSPWiki use absolute URIs, by setting the jspwiki.baseURL -property. This will of course change the way the internal links are created. The HREF is okay in this case.

However, a problem emerges with non-existant pages: Most Wikis generate a slightly different URL for these cases. Is it enough to just give the different form URL (such as "Edit.jsp?page=XX" in case of JSPWiki) as the href or should it be noted in the type as well?


I tried it on Cygwin, but then realized I'd never gotten BASH to not run out of environment space. It was getting late and I had other features to work on.


Yeah, mainly I want the types to be different, so i can then know to handle them differently. The bad thing would be for the client to have to parse the URL itself to figure out what it's pointing to.

  • Dealing with footnotes that way would work better, yes.
  • Type of "inline" would work.
  • External works fine, yes.
  • I'm not yet thinking that you need to (or should) change the way internal links are done. I think all my code needs is:
  1. A way to find a link.
  2. A way to have it point to the real server if this is a link whose referent I'm not showing (e.g., a page not picked in my example).
Look at the private methods in my PrintWiki class. You'll see some strong dependancies on JSPWiki's link style that need to go. That's all I'm trying to address.


MahlenMorris: While testing Hoop, i've realized that part of the listLinks() spec isn't clear on one point. What do links to pages that are undefined (e.g., APageThatDoesNotExist) look like in the list? Currently on JSPWiki they look like links to the pages anyway, even though when they are actually rendered to HTML they are links to the edit.jsp page.

In fact, that href doesn't seem quite correct. For example, the XML-RPC is telling me that the href is http://www.ecyrd.com/JSPWiki/Wiki.jsp?page=APageThatDoesNotExist, yet the actual URL in the rendered page is http://www.ecyrd.com/JSPWiki/Edit.jsp?page=APageThatDoesNotExist. Which means that anything searching for the href won't find it. Smells like a bug to me, but I'm not sure what the proper definition is.

JanneJalkanen: I think you're correct. The code doesn't check if a page exists, which is definitely a bug. The HREF attribute should always have the correct contents. However, the spec does not define a page type for nonexistant pages, which is a bug in spec.

No InterWiki reference defined in properties for Wiki called "PhpWiki"!: So how to fix the specs for links to not-existing local pages? For now PhpWiki produces those links: http://server/wiki/index.php?pagename=APageThatDoesNotExist&action=edit or just APageThatDoesNotExist?action=edit. I'm using the hypergraph/hyperwiki applet which should leave out external and non-existing pages. So my proposal would be to add another type=empty (or type=not-existing) for those so that apps can easier leave them out. Grepping for Edit.jsp or action=edit is problematic. --20041218 ru

Is it possible to link to a footnote on a different Page?

-- 04.02.04 rsc

Back to WikiRPCInterface

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-17) was last changed on 10-Feb-2009 18:44 by Janne Jalkanen