obj_link based object linking
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