[Zope-PTK] Automated Hyperlinking and nested objects

[Ken Manheimer]

On 19 Mar 2001, Kent Polk wrote:

> How much thought has been given to the possibility of implementing
> an automated hyperlinking facility (WikiNames :^O ) to CMF object
> collections???

I've given this some thought.  I *really* want low-impedence link
authoring, and also want the document-namespaces of conventional wiki
*and* lineage (where documents are created from, and thereby offspring
of, other documents) that zope.org ZWiki have innovated.

For StructuredText-style documents, i want to maintain a shortcut for
referring to documents within the same collection by their name, but with
a slight bit more explicit effort on the part of the writer to distingush
such references.  I'm calling these things "CommonNames".  They would have
similar capitalization rules as WikiForNow (like typical wiki, but allows
numbers and "~" tildes), but: 

 - CommonNames would have to be enclosed in square brackets to be
   recognized - "[CommonName]".  No unintended WikiLinks popping up in
   your text left and right.

 - Stuff that doesn't qualify as a CommonName does *not* turn into a link
   if it's enclosed in a square bracket so that you can use square 
   brackets as you normally would for non-CommonName text, [without
   surprises].

 - To turn arbitrary text into links with a shortcut gesture, you have to
   double the square brackets: [[this would be a link]] to a horribly
   named document.

 - As a bonus, since the mechanism for recognizing CommonNames in square
   brackets is so definite, we can apply a bit of discretion and map, eg,
   plurals to singulars - [[CommonNames]] would map to [[CommonName]] if
   CommonName already exists as a page.

   (If no variant exists, the plural will be used, but the creation
   actions for CommonName-style documents will offer editing of the name
   being used, so the creator can normalize to the variant they want to
   use.)

One other aspect to this question is realization of "link objects" in
zope.  These link objects would know how to render themselves (or
something would know how to render them) into many formats - XML, HTML,
StructuredText, Word, whatever manifestations the documents could have.  
Further, they would be able to play nicely with Interlinking Info
OrganizationObjects, for, eg, indirection that could track forwarding of
document locations as they are renamed and moved around the site.

> I mention this because almost every project possibility that I bump
> up against has almost the same set of requested 'requirements'.
> The good news is that I think we are gradually bumping off those
> requirement items with the new core components of Zope/CMF, leaving
> less for a developer to create. Some of the things that are left
> are automated tree-views of document heirarchies arranged according
> to query constraints (meta-data again...) and automated hyperlinking.

I think there will be some important common hierarchies, in addition
to the folder hierarchy - lineage, keyword hierarchies (i need to get
my notes concerning these online - my machine just had a disk crash, i
hope they're still there!), and others.

Kent, i very much appreciate your (and michael's) enthusiasm and
offers to help.  I'll try to scrape together time to at least spell
out where i am.  The very short version of it is my thoughts are still
in the cooking phase, not yet ready to be implemented.

In particular, i need to bring them to ground in the CMF - to piece
together where and how they would fit in.  Being fairly new to and
unversed in the CMF, myself, i have a good bit of work getting
acquainted with it, first - work anyone can do to document and clarify
the framework for others, as they do so for themselves, will be to
*everyone's* benefit.

As i indicated, i'm under heavy commitment for this consulting gig.  I
can see maintaining some scoping-out discussion in the meanwhile, with
the understanding that i'm going to be slow and sketchy in my
availability...

-- 
Ken
klm@digicool.com