Guide to LLNode characteristics?

I've gone through the Builder class, and I have been doing custom development with OScript for some time--data migrations, agent scripts, event scripts, etc. I've even done some custom modules. However, I was looking for some definitive documentation that defines the particular characteristics of using certain LLNode object features:

volumes and associated volumes (fAssociatedVolume)
proxy subtype (fProxySubtype)
workspace (fIsWorkspaceNode)

For each of these items, I am hoping to find exactly why I would use them. For what purpose do they serve? Do they overcome certain limitations within the tree structure, or providing some non-linear structure to content?

Thanks for any commentary. Perhaps I just can't find such a document, but it's unfortunate that some core information like this data is obscured.

Find more posts tagged with

Comments

eLink User

HiDarrin,

Some of thisinfo may be entrenched in IP but for what it’s worth I will put some examplesthat you may see in action. I don't pretend to know the design goal or intentsomethings I have come to appreciate being in this for several years.

I need to find all the Objects in a personal workspace

Typical queries rangein Oracle from finding the dataid of the workspace and iterating thehierarchy(SQLserver CTE,DTREEANCESTORS,ConnectBy).If you were just interestedin that all you would need is a query to dtree based on ownerid . Somethingsimple to remember like all objects are owned by this ID.Aworkspace's(volume's) parentid is -1 kind of you can't go higher than up.Itpartitions dtree into easily available sub hierarchies.You will see these inaction in many important subtypes like Compound Documents, its revisions,releases all volumes in their own aspect. In fact in our custom dev we have aworkspace where we allow certain new subtypes to be created, being a volume itis easy for us to get there. Each custom subtype we throw in holdsconfiguration info and using these technologies available to us we find it easyto move code form Dev,Test,QA and Prod .The other aspect is you can quicklycontrol your navigation links(Example I don't know if you use Transmittals, butin its configuration One is supposed to navigate to a DistributionVolumes,wherein Distribution Matrices exist and in them would you findDistribution codes,not sure if they are pure subtypes or have volumes in it butwhen I click it I am taken directly to the root of the Distribution Volume).Notsure if this relation remains true for all subtype but if your enterpriseworkspace has a dataid of 2000 its ownerid is the negative of that. Recyclebinhas the its negative dataid, projects follow that.

I do not know whatsome business rules such as you cannot have EnterpriseWorkspace twice or more nor do I know about the fproxySubtype. Perhaps other OT learned people mightgive you hints on why some of it is not as crystal clear as one would wantit to be.

..appu appnair appunair

Well, if I called the wrongnumber, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

On Tue, Jul 28, 2015 at 12:57 PM, eLink Entry: Content Server Development Forum <development@elinkkc.opentext.com> wrote:

Guide to LLNode characteristics? Posted bydtisdale@iqbginc.com (Tisdale, Darrin)On 07/28/2015 01:54 PM

I've gone through the Builder class, and I have been doing custom development with OScript for some time--data migrations, agent scripts, event scripts, etc. I've even done some custom modules. However, I was looking for some definitive documentation that defines the particular characteristics of using certain LLNode object features: volumes and associated volumes (fAssociatedVolume) proxy subtype (fProxySubtype) workspace (fIsWorkspaceNode)For each of these items, I am hoping to find exactly why I would use them. For what purpose do they serve? Do they overcome certain limitations within the tree structure, or providing some non-linear structure to content?Thanks for any commentary. Perhaps I just can't find such a document, but it's unfortunate that some core information like this data is obscured.
[To post a comment, use the normal reply function]
Forum: Content Server Development Forum
Content Server: Knowledge Center

Darrin Tisdale

Thanks for the info. I'll keep up the hunt. You'd think there'd be a wiki with this information in it, at least what is officially public. Wonder who makes some software that could manage such a wiki?!

I've always found the use of negative ID to be bad design, IMHO. Effectively, it's like using a single data field to hold multiple pieces of data, something I have found always comes back to hurt later on. However, there may be wisdom there after all. Who am I to judge?

¯\_(ツ)_/¯

John W. Simon, Jr.

Darrin,

I feel your pain on the documentation, though I must say it is better than it used to be! There is some information in the Documentation script on LLNode. It isn't much but it does give you some examples about on the 3 you mentioned...so a starting point but much of the work is left up to you.

Please post if you have specific questions. There are some amazing developers out there watching and more than willing to help.

Cheers...

Tammy_Jakubowski

Hi Darrin,

I asked a developer who's been around Livelink/Content Server since the beginning. This a paraphrasing of what he said.

The negative NodeID was the easiest way to find where the real node is stored when you're using different volumes.. It's only used with non-Enterprise volumes, as you probably know. The main and probably sole reason that different volumes are/were created and used was to allow different permissions schemes that would not affect the rest of the objects that are in the Enterprise Workspace. So, if you need a different permissions scheme, like you do with Projects, Classifications, Records Management, Workflow Attachments, Document Templates, Physical Objects, Communities of Practice, (to name a few) then create a new volume.

If nothing else, at least the information is now posted here.

Hope this helps.

Tammy Jakubowski

Christopher_Meyer

Hi Tammy,

The main and probably sole reason that different volumes are/were created and used was to allow different permissions schemes that would not affect the rest of the objects that are in the Enterprise Workspace.

Do you have more information on this? For example, I know how project and project volumes work, but I don't understand why it's like this. From what I've seen much of the functionality around roles (e.g., Coordinator, Member, & Guest) could also be applied on a single node. What does an associated volume really give you?

Thanks! Chris

Tammy_Jakubowski

Hi Chris,

The workflow attachments volume is a good example. That volume allows for the permissions of attachments to not be determined by the parent node of the worklow map itself (or by the permissions on the actual map), but by the permissions established in the management of the workflow. You could not manage that from the traditional permissions. This is also why there are volumes for Communities of Practice too. You want a different permissions scheme and role model with CoP than traditional permissions. Projects are role based; traditional folders and docs are permissions based, just like the original UNIX perms.

Regards,

Tammy Jakubowski

tamjak@globalcents.com

Director of Quality Management

cell: 847-452-2059

www.globalcents.com

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Wednesday, September 2, 2015 1:31 PM
To: eLink Recipient <devnull@elinkkc.opentext.com>
Subject: Re Guide to LLNode characteristics?