Re: Getting article aid (giving or not givingpubid) via the title

"mikespub" <[email protected]> wrote in message
news:[email protected]
> In article <bjnnq3$dln$1-111RdWWlOxkOkXtL6OYfHgC/[email protected]>, "Jason Judge"
<[email protected]> wrote:
> >>...
> >> The other approach, where a separate table would keep track of the
> >> link between (internal) module items and (external) references,
> >> comes very close to what I had in mind with the kbase discussion :
> >> have a (base + id) on the hand, and a (module + itemtype + itemid)
> >> on the other hand, so that e.g.
> >
> >Yes - that's what I meant. Sorry I wasn't being clear. The external IDs
are
> >likely to be something the user will never see nor be interested in. It
is
> >information that would only be useful when linking items to other sites.
Of
> >course, with URL mapping then it may well be something the user is
> >interested in, as you've shown below. Two birds with one stone...?
> >
> Indeed - and add some magic in autolinks so that kbase123 gets a
> link to kbase 123, which itself gets redirected to articles 7 345, and
> we have a multi-site kbase system with unique (and possibly auto-
> increment) ids, independent of the actual article id on each site. :-)

No need for a double-redirect if the kbase autolink template calls the
appropriate API. If an API function could be passed 'kbase' and '123', and
return 'articles', 'user', 'display' and '7345', then the autolink would
jump straight there in one hop. The API would be part of the xlink jobby.
Inside the API would be a magic function that performs magic translations...

> Guess I need to get working on that xlink thingie...
>
> Mike.