SQL / Model

Table:	obj_link
Entity:	ObjectLink
Class:	LSObjectLink

objectLinkId	pkey
sourceId		(number, t_id)
sourceType	(str(50))
targetId		(number, t_id)
target		(string)
targetType	(str(50))
linkType		(str(50))
label			(string)

The "sourceType" and "targetType" fields contain the entity name of the respective "sourceId" or "targetId" fields for fast construction of EOKeyGlobalID (we could also use the LSTypeManager to retrieve that info).

OGoObjectLinkManager

allLinks: (allLinksOfType:)
allLinksFrom:
allLinksTo:
allLinksFrom:type:
allLinksTo:type:
createLink:(obj link)
deleteLinksTo:type:
deleteLinksFrom:type:
deleteLink:(obj link)
deleteLinkGID:

OGoObjectLink

sourceGID
targetGID
label
linkType

The link-type is somewhat similiar to an attribute name. Indeed we could have used custom (link) attributes but prefered to use a separate table since linking is a higher level concept which will be used (... queried ...) a lot.
Notably those are bidirectional links, so we cannot only determine the targets an object links to, but also find out what other objects point to the object in focus (as long as we are talking about internal objects ;-).
In the moment we only support internal objects as link sources, we may want to extend that.

UI

Work in progress ...
The RelatedLinksUI bundle is going to be created in WebUI/Common.

Related link creation can now be configured using the OGoObjectLinkTypeMap dictionary default. The keys of the dictionary are the "link types" which will be visible in the link creation popup and the values are the names of OGoContentPage components used to edit a link.

The link creator components will get passed in two keys: "sourceGlobalID" and "linkType" which should be sufficient to create the link in question.

JobsUI

The task module makes some "hackish" use of the link feature for a customer project. The files in question are:

./JobUI/LSWJobs.m
./JobUI/LSWJobAction.m
./JobUI/LSWJobViewer.m
./JobUI/LSWJobEditor.m