Subclassing objects

I have an object that is an orphan of the Lliapi:Document (I also have a corresponding webnode that is an orphan of WebDoc:Document) I'm having trouble with the View and Download actions, all the other actions work, but when I try to view or Download the document I get an "Invalid Action Specified" error. When I debug it, I see that the action the url is calling is not being returned from the WebNode.WebNodeActionMultiMap for my object type, but is returned for the regular document.(I see this by debugging the call to my webnode's Action() method). Since it's an orphan of document, I don't understand why the action isn't valid for my object. I've set the fProxySubtype to Document's. Any suggestions on why this wouldn't be working?Thanks, Dawn

Find more posts tagged with

Comments

JohnL

I sent an email a couple of days ago describing some problems with a node I created by orphaning LLIAPI.Document. Specifically, I was unable to View or Download my new node. I was able to solve the problems I described in my previous email by doing two things:1) In my new Document WebNode object I modified the Action method, replacing the line for i in { Undefined, .fSubtype }with for i in { Undefined, .fSubtype, $ApplTypeDocument}in the following context://for i in { Undefined, .fSubtype }for i in { Undefined, .fSubtype, $ApplTypeDocument} for webNodeAction in actionMultiMap.Get( i ) actions.RegisterItem( webNodeAction, \ webNodeAction.OSName ) endendThis returns all the actions registered to my subtype as well as the document's subtype. Doing this gave me the Download functionality, but I was still having trouble with the View action. When I looked at the View Cmd that was being called by the regular Document class, I saw that it had a Nodetype specified of $ApplTypeDocument. Orphaning this command and changing to Nodetype to my subtype supplied me with a View command I was able to use with my node. Making these changes left me confused about how object inheritance really works in livelink. Since my class is an orphan of the regular Livelink Document class, (and its ApplTypes include Document), I expected it to inherit the actions of the Document class. The Documentation in the Action() method on the WebNode object explicitly says that subclasses are not to override the method, but I had to override it to get the document actions. I have 3 questions:1) Am I doing something wrong? Do you really lose inheritance of actions when you create a new class with a different subtype? 2) Shouldn't WebNode.Action() be looking up actions based on Appltypes, not the subtype?3) Similarly, shouldn't WebNodeCmd.Nodetype() have a list of Appltypes, not the subtype? Thanks, Dawn

David_Willkomm

Add $WebNode.WebNodeActionMultiMap.Add( , ) to your OSpace's Root.Startup(), e.g. $WebNode.WebNodeActionMultiMap.Add( 411, $MyGlobals.MyDownloadObjRef ). Do not use your nodetype's $Type global here because it my not be defined at this point during startup. You will need to add Action object references to your Globals ($MyGlobals.MyDownloadObjRef in my example) because most Action objects do not define a global reference.Repeat as necessary to pair desired WebNode and Action objects.

JohnL

Hi David, Thanks for the tip. I'm still confused about the inheritance though - does this mean that I should add action object references to standard Document actions (like 'View' and 'Find Similar') to my Globals? Maybe I'm being thick about this, but what happens when someone develops a new action for a Document object (say in an optional module, or in a user's custom development)? Your solution implies that even though my object is a orphan of the Document object, that action wouldn't be valid for my object unless I added one of these references.It seems like there ought to be a way to preserve the fact that this object is a subclass of Document and all actions that are valid on Document are valid on it as well.Thanks, Dawn

David_Willkomm

WebNodeActions are components, not methods, and as such are not inherited. This is intentional. Because OScript is loosely typed, there are no interfaces with which the compiler can enforce interoperability of LLNode/WebNodes and WebNodeActions. Therefore, a conscious decision must be made by someone that the LLNode/WebNode and WebNodeAction in question will interoperate properly.A hypothetical example of an inherited action: company A develops document subclass Uncopyable Document. Company B develops document action Copy Document. Customer C installs A and B?s modules, click?s Copy Document only to have it fail every time.