In House Training - OScript clarificaiton question

Dear All, I am involved in some internal OScript training and I need to find some clear definitions of when to use the following :1. Overrides v Orphaning2. SubsystemsI have an idea myself, but would appreicate input from others to ensure I have it sorted for them.

Find more posts tagged with

Comments

Donna Nalls

Hi Greg,Here are my thoughts, for what they are worth:1) overrdes v. orphaning: depends on the purpose of my customization. If i want to perform some customization and use an existing object as my class object, then certainly, i am going to orphan the original object -- this way, i can take advantage of the object inheritance and save myself some work. Example: if i want to create a custom folder, i would orphan the Folder LLNode and WebNode objects, change the subtype and a few other features, as desired. I have orphaned an existing object and taken advantage of rules of inheritance to create a new folder object.If I want to modify one method within another object, i usually "override" that one method -- by way of an object reference in my custom ospace and a new method to replace the original. You can override an object by orphaning it, as well. So, i guess the answer here is how specifically you are presenting these two options....2) a subsystem is a collection/group of related objects. objects get registered within their subsystem via their __Init method when the LL service is started. The purpose of the subsystems is to quickly access objects when a request is being processed. example: $LLIAPI.LLNodeSubsystem.GetItem($TypeFolder) -- the Folder LLNode object has been registered in the LLNodeSubsystem object, so it is quickly referenced by the GetItem() call. Subsystems are also used when registering Callbacks - for example, if you orphan and enable a GeneralCallback object for purposes of event scripts, the object gets registered in the WFCBGeneralSubsystem...when the workflow events are fired off, the code checks the subsystem for any registered callback objects....etc.I'm sure there are others out there that can phrase all of that more eloquently, but that's my take on it all!Good luck with your training!Donna

Jeff Lang

Greg,Donna is right on. I use orphaning when creating new object types. The inheritance save time and work, but I do not use orphaning for changing the behavior of an existing item. For that I use overrides. The problem with using orphaning for changing and existing feature is that other developers may have the same idea and the changes will conflict.There is not really a good standard for doing overrides. You can try to use the OTOverride module, but that only helps a little. The main problem is conflicts between multiple modules that try to change the behavior of the same object. It usually comes down to which ever module loads last, wins.Subsystems are a misunderstood and under utilized feature of Livelink Oscript. The use of subsystems leads to more extensible and maintainable code. If you wanted to expain a subsystem to a Java programmer you might say that it is comperable to a program defining an interface and other add ons implementing said interface.Subsystems are great for when there are a non-finite number of options available to a feature. When I'm trying to decide whether or not to use a subsystem, I always ask myself "If there are a large number of options that could work for this feature, would someone trying to add another option have to override any of my code to implemment that option?" If the answer is yes, I always create a subsystem. If no, then I implement the finite set of options myself. The use of subsystems is a great way to allow mutiple different modules to register their features in to work with each other.

eLink User

Message from Alex Kowalenko via eLinkGreg,Both Donna and Jeff are right on the mark.1a. Orphans are used to create new objects as a general rule.These new objects will have behaviours that are similar to the parent. Aslong as object registration keys (such as fSubType for nodes) are unique,multiple modules will not clash. Good developers with extensibility in mindwill create objects that can be orphaned in a way to incrementally add newfunctions to an existing structure. For example, new attribute types can becreated by orphaning LLIAPI.LLAttribute objects and specifying a uniquefType (such as 10013 for my Attribute Extensions Module).1b. Overrides are used when behaviours of existing objects need to bealtered AND when there are no built-in call-backs.Good developers will add call-backs at key points in their code to providein-line extensibility. Howard Pell taught me to search for "CB" and"CallBack" objects whenever one was in the mood to change existing code.When I wrote the original version of the OTOverRide module in 2002 I usedthe structured override technique that Iain Dunn was teaching at the time.This module reports on overrides in the thread log header and indicates thatupgrades may be necessary when the base code (OScript method or HTML file)has been modified. An override on the same element by multiple modules is aproblem since the last module does win out. One way to mitigate this problemis to override with a wrapper technique such that the original method iscalled within the overridden method. The latest version of the OTOverRidemodule allows for multiple module overrides as long as wrapper-overrides areused.2. Subsystems are a basic tool to register objects and are necessary forextensibility as Donna and Jeff have explained.-alex------Original Message-----From: eLink Discussion: Development Discussion[mailto:development@elinkkc.opentext.com] Sent: Monday, April 30, 2007 12:38 PMTo: eLink RecipientSubject: More Oscript notesMore Oscript notesPosted by Lang, Jeff on 04/30/2007 01:34 PMGreg,Donna is right on. I use orphaning when creating new object types. Theinheritance save time and work, but I do not use orphaning for changing thebehavior of an existing item. For that I use overrides. The problem withusing orphaning for changing and existing feature is that other developersmay have the same idea and the changes will conflict.There is not really a good standard for doing overrides. You can try to usethe OTOverride module, but that only helps a little. The main problem isconflicts between multiple modules that try to change the behavior of thesame object. It usually comes down to which ever module loads last, wins.Subsystems are a misunderstood and under utilized feature of LivelinkOscript. The use of subsystems leads to more extensible and maintainablecode. If you wanted to expain a subsystem to a Java programmer you might saythat it is comperable to a program defining an interface and other add onsimplementing said interface.Subsystems are great for when there are a non-finite number of optionsavailable to a feature. When I'm trying to decide whether or not to use asubsystem, I always ask myself "If there are a large number of options thatcould work for this feature, would someone trying to add another option haveto override any of my code to implemment that option?" If the answer is yes,I always create a subsystem. If no, then I implement the finite set ofoptions myself. The use of subsystems is a great way to allow mutipledifferent modules to register their features in to work with each other.[To reply to this thread, use your normal E-mail reply function.]============================================================Topic: In House Training - OScript clarificaiton questionhttps://knowledge.opentext.com/knowledge/llisapi.dll/open/12316136Discussion: Development Discussionhttps://knowledge.opentext.com/knowledge/llisapi.dll/open/786303Livelink Server:https://knowledge.opentext.com/knowledge/llisapi.dllTo Unsubscribe from this Discussion, send an e-mail tounsubscribe.development@elinkkc.opentext.com.

Greg_Griffiths_(ggriffiths_-_(deleted))

Dear All, thanks for the input, that was what I thought the answers were going to be, but as I'd got thus far from Builder help and looking at the code its good to have some people with more experience clarifying it as well.