Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Content Management (Extended ECM)
API, SDK, REST and Web Services
LAPI - Will It Ever Be Changed
x-opconuser3_-_(deleted)
For the last 2 years, I have been forced to code using the LAPI for Java. Although promised changes in v9 (perhaps to OO code and reported Exceptions), all we got was an additional load of poorly-documented, bass-ackwards classes that use mystic LLValues as the all-encompassing Data Object.Tha LAPI Documentation states:"Many of the functions in the other APIs use value objects as input and output parameters. This provides several advantages...This should read: "In order to prevent anyone from understanding what the LAPI is doing (hence limiting development beyond what we will sell you), and since Java utterly lacks sufficient Objects to represent the extremely special Livelink Data, we have developed the LLValue Object.Additionally, since we are too cheap to hire anyone to code the LAPI who might assist in making the LAPI understandable to a Java developer, we essentially guarantee a continuing revenue stream from development support training.We back our commitment to strangle development up by removing all sample code from the shipped documentation."Come on, Open Text, why not accept the criticisms of the LAPI and provide a true OO/Java API so we could actually do some work.I would code a good Java LAPI for you for money.I can't wait to see how you do the J2EE version of Livelink (by having the controller servlet do HTTP calls to the same old Livelink system, I bet!Any other comments!Jon Kofal
Find more posts tagged with
Comments
eLink User
Message from David Slimmon via eLinkHi there,I appreciate the time you took to write and regret that you feel this wayabout developing in LAPI. I know that others have their concerns as well,although most have not expressed them in quite the same way.I think that the biggest area that you highlighted in your message wheresome improvements could be made is in the LAPI documentation itself. Yourcomments have been forwarded to the appropriate people at Open Text and itis my sincere hope that we can make improvements to the Livelink SDK itselfand to all of the pieces that support the SDK (Documentation, TechnicalEducation, Customer Support etc.) and that these improvements will changeyour impression of developing in Livelink.While many would agree that developing with LAPI is not perfect (can anyonename me a developing environment that is perfect?), it is what is availablefor us for the time being. Which means that we have to continue to helpeach other through discussions like these, through the training classes andthrough the Help Desk.Regards,Dave-----Original Message-----For the last 2 years, I have been forced to code using the LAPI for Java.Although promised changes in v9 (perhaps to OO code and reportedExceptions), all we got was an additional load of poorly-documented,bass-ackwards classes that use mystic LLValues as the all-encompassing DataObject.Tha LAPI Documentation states:"Many of the functions in the other APIs use value objects as input andoutput parameters. This provides several advantages...This should read: "In order to prevent anyone from understanding what theLAPI is doing (hence limiting development beyond what we will sell you), andsince Java utterly lacks sufficient Objects to represent the extremelyspecial Livelink Data, we have developed the LLValue Object.Additionally, since we are too cheap to hire anyone to code the LAPI whomight assist in making the LAPI understandable to a Java developer, weessentially guarantee a continuing revenue stream from development supporttraining.We back our commitment to strangle development up by removing all samplecode from the shipped documentation."Come on, Open Text, why not accept the criticisms of the LAPI and provide atrue OO/Java API so we could actually do some work.I would code a good Java LAPI for you for money.I can't wait to see how you do the J2EE version of Livelink (by having thecontroller servlet do HTTP calls to the same old Livelink system, I bet!Any other comments!Jon Kofal[To reply to this thread, use your normal e-mail reply function.]============================================================Discussion: LAPI Discussion
https://knowledge.opentext.com/knowledge/livelink.exe?func=ll&objId=765428&objAction=viewLivelink
Server:
https://knowledge.opentext.com/knowledge/livelink.exe
jamespate
Would be nice if OT released a VB COM wrapper for LAPI. I see one or two developers write their own, but we don't all have the time (or ability!).
eLink User
Message from Sean M Alderman via eLinkI think a huge improvement would be to put javadoc comments into thejava LAPI classes. In addition, I think it would be nice to see somestandardized main() methods in the classes so that we coders can run aquick command line to see what objects look like and do with out havingto do a lot of coding.I've been working on my first java Lapi project for the past month, andI have to agree Jon Kofal's assessment of the "Mystical" LLValueobject. After coding in Oscript for the past year and a half, I realizethat implementing an Assoc in java is probably very difficult. Thatbeing said, we have to deal with what we have, unfortunately seems toinvolve a lot of work on the developer's side to figure things out ashe/she goes. What's my point?...well, does anyone ever notice thatthere only seem to be things posted to the Discussion when someone can'tfigure something out?...Perhaps we ought to start posting more of ourown code as sample classes for accomplishing common tasks with LAPI.On Wed, 2002-01-09 at 11:04, eLink Discussion: LAPI Discussion wrote:> RE LAPI - Will It Ever Be Changed> Posted by eLink on 01/09/2002 11:04 AM> > Message from David Slimmon via eLink> > Hi there,> > I appreciate the time you took to write and regret that you feel this way> about developing in LAPI. I know that others have their concerns as well,> although most have not expressed them in quite the same way.> > I think that the biggest area that you highlighted in your message where> some improvements could be made is in the LAPI documentation itself. Your> comments have been forwarded to the appropriate people at Open Text and it> is my sincere hope that we can make improvements to the Livelink SDK itself> and to all of the pieces that support the SDK (Documentation, Technical> Education, Customer Support etc.) and that these improvements will change> your impression of developing in Livelink.> > While many would agree that developing with LAPI is not perfect (can anyone> name me a developing environment that is perfect?), it is what is available> for us for the time being. Which means that we have to continue to help> each other through discussions like these, through the training classes and> through the Help Desk.> > Regards,> Dave> > > > -----Original Message-----> > For the last 2 years, I have been forced to code using the LAPI for Java.> Although promised changes in v9 (perhaps to OO code and reported> Exceptions), all we got was an additional load of poorly-documented,> bass-ackwards classes that use mystic LLValues as the all-encompassing Data> Object.> > Tha LAPI Documentation states:> > "Many of the functions in the other APIs use value objects as input and> output parameters. This provides several advantages...> > This should read: "In order to prevent anyone from understanding what the> LAPI is doing (hence limiting development beyond what we will sell you), and> since Java utterly lacks sufficient Objects to represent the extremely> special Livelink Data, we have developed the LLValue Object.> > Additionally, since we are too cheap to hire anyone to code the LAPI who> might assist in making the LAPI understandable to a Java developer, we> essentially guarantee a continuing revenue stream from development support> training.> > We back our commitment to strangle development up by removing all sample> code from the shipped documentation."> > Come on, Open Text, why not accept the criticisms of the LAPI and provide a> true OO/Java API so we could actually do some work.> > I would code a good Java LAPI for you for money.> > I can't wait to see how you do the J2EE version of Livelink (by having the> controller servlet do HTTP calls to the same old Livelink system, I bet!> > Any other comments!> > Jon Kofal> > > [To reply to this thread, use your normal e-mail reply function.]> > ============================================================> > Discussion: LAPI Discussion>
https://knowledge.opentext.com/knowledge/livelink.exe?func=ll&objId=765428&o>
; bjAction=view> > Livelink Server:>
https://knowledge.opentext.com/knowledge/livelink.exe>
; > [To reply to this thread, use your normal e-mail reply function.]> > ============================================================> > Topic: LAPI - Will It Ever Be Changed>
https://knowledge.opentext.com/knowledge/livelink.exe?func=ll&objId=2649433&objAction=view>
; > Discussion: LAPI Discussion>
https://knowledge.opentext.com/knowledge/livelink.exe?func=ll&objId=765428&objAction=view>
; > Livelink Server:>
https://knowledge.opentext.com/knowledge/livelink.exe>
; > -- Sean M. AldermanITRACK Systems AnalystPACE/NCI - NASA Glenn Research Center(216) 433-2795Calling a windowed operating system "Windows" is like naming anautomobile "Wheels."
jamespate
Gets my vote!
eLink User
Message from David Slimmon via eLinkHmm...Are we all in agreement?Are people interested in sharing their VB and Java LAPI code for real? Ifso, I'll be more than happy to create a spot on the KC for us to storeeverything, with one small caveat...If you send in some code for the code base, you get to support it forpeople! Sound fair?Let me know what you think because we can make this happen. In fact, we'vetried doing this before, but it kind of fizzled a bit because not everybodywas willing to share. I'd be thrilled to see the idea resurrected for LAPIusers.Cheers,Dave-----Original Message-----Gets my vote!
x-opconuser3_-_(deleted)
Here is a LivelinkBean that I am working on for example.Biggest frustration is that I want Java Objects out of the LAPI (Collections and Specific Objects for data types, NOT LLValues) with toString() methods so I can generate HTML or XML or whatever.Second biggest frustration is LAPI Exceptions thrown but not declared (must wrap ALL calls to LAPI with a try-catch block.Happy that the LAPI is quite speedy, even if I have to wrap all calls with a retry loop as some calls are just ignored.Still working on getting Attributes out of Categories. Anyone else done that?It surely will get better in the next version (10).
John_Shoun
Maybe my expectations are too low, but I don't see what the problem is. I certainly used APIs that are worse.Providing a cross-language API is a challenge and having support for VB, C/C++, and Java is no exception. To build a maintainable product that will work in all environments will require some concessions to the other technologies. It can't all be tailored to Java.I agree that the documentation could be improved, but it is usable. I have given (thrown over the wall) the HTML documentation and the libraries to develop groups who come back with working implementations. Many times these groups don't have any oscript or Livelink internals experience and they still get it working without too many problems.The Java API has proven to be very useful. We have re-useable Livelink classes that can be dropped into everything from stand-alone desktop apps to JSP sites and they run well.Don't take this to mean that I want Open Text to stop working on improvements. What I would like to see is the ability to expose our custom oscript code so that it can be accessed from LAPI.BTW - Sample code is available from support.
jamespate
If Opentext had a code reference area, it would serve most of the need. Then in addition to that an area for postings.I don't think you can insist on having code snippets supported. They would be "for guidance only". Often people just need some help getting started. Once up and running they would presumably develop within their own coding and version control regime anyway.
eLink User
Message from David Slimmon via eLinkYep - that's kind of what I meant...I just didn't want a situation developing where LAPI coders out there wouldpost their samples to the KC and calls would start coming into the Open TextHelp Desk on them ;)I can see it now, "Hi there, I downloaded some sample code from the KCCustomer Code Base and it just deleted all my production data, please help!"Maybe an extreme example obviously, but I think everyone using it would haveto recognize that the postings in there would need to be, as you have said"for guidance only" and to be used on that condition.Other than that, I think it's a terrific idea. I'll set this up soon.Trying to figure out how to handle postings at the moment.Regards,Dave-----Original Message-----Opentext codebasePosted by CasTranAdmin on 01/11/2002 05:16 AMIf Opentext had a code reference area, it would serve most of the need. Thenin addition to that an area for postings.I don't think you can insist on having code snippets supported. They wouldbe "for guidance only". Often people just need some help getting started.Once up and running they would presumably develop within their own codingand version control regime anyway.
Sun_Livelink_Admin_(sunmic01admin_-_(deleted))
I am a Java developer and has been using LAPI for more than a year. I would have to say LAPI was poorly architected and designed for 3 major reasons: 1) It is not object oriented: almost no object concept, no inheritance...2) No exception handing mechanism;3) Poorly documented: no javadoc and no sample code.
x-opconuser3_-_(deleted)
Regarding my criticisms of Livelink in the past, When you look at the hoops I have to jump through to get NATIVE JAVA TYPES (Hashtables) out of the Livelink implementation of a Hashtable (LLValue) (see attachment, method getCategories()), I think the comments stand.Why not just return Java types (Vectors, Hashtables, Strings, Dates, Integers) from the LAPI calls rather than reinventing the wheel and returning the nebulous LLValue?I understand that Livelink is a complex system, but OO abstractions would make it easier to understand, Java types would make it usable, and reading and following the Java Coding Conventions and Javadoc Conventions would make it extendable.Ciao,Jon K
David_Forbes_(dforbes_-_(deleted))
Formark offers LLcom, a COM wrapper for LAPI. It supports both VB and C++ interface, as well as ASP. One of the more compelling productivity features is that LLcom exposes an OO interface.More information is at
http://www.formark.com/liveviews.htmDavid
Len_Palmeri_(kmartadmin_-_(deleted))
A great Idea!!. We eagerly wait for the LAPI code library
David_Talley_(dtalley_-_(deleted))
I have to agree with Jon - I'm just delving into the LAPI code here and have found the the LLValue object to be one of life's great unsolved mysteries. The API is written in such a manner as to where one has to test almost every facet of the API to figure out what it's doing. A few well placed examples would have done wonders to elicit a better understanding of the LLValue object and how it is meant to give us, as developers, an 'advantage'. Now, $800 in my opinion, is not necessarily a great amount to pay for training. However, as a developer I would have expected that the API be written in such a way that if I had Java programming experience I'd be able to at least figure out the basics. I'm a bit disappointed so far and will continue to go through method by method to see what these non-intuitive API's can do.
eLink User
Message from Sean M Alderman via eLinkMy biggest complaint from the java perspective is that nothing throwsexceptions when it doesn't work right. LAPI seems to Anti-Java to me.The only excpetions I've run into come when I stick something from anLLValue into a java primitive and it doesn't work for some reason, andthese are java exceptions not something Lapi generated. I hate that Ihave to check the session object's status almost every time I make alapi call to see what happened. You make a session object, then passthat object to a constructor for a lapi_documents object...later youcall a method of the lapi_documents object and it doesn't throw anexception when it doesn't work.I'd much rather do the code immediately below than what's after it -try{ lapi_docs.AddDocument(....);}catch (LAPIException e){ e.printStackTrace(System.err); Runtime.getRuntime().exit(0);}Than work this -int result = lapi_docs.AddDocument(...)if (result != 0){ StringBuffer errorBuffer = new StringBuffer(); errorBuffer.append("Status Code: " + session.getStatus() + "\n"); errorBuffer.append("API Error: " + session.getApiError() + "\n"); errorBuffer.append("Error Message: " + session.getErrMsg() + "\n"); errorBuffer.append("Status Message: " + session.getStatusMessage() +"\n"); System.out.println(errorBuffer.toString()); Runtime.getRuntime().exit(0);}// Success!!! Now, continue doing something usefulOn Tue, 2002-04-23 at 11:34, eLink Discussion: LAPI Discussion wrote:> Agreement w/Jon K> Posted by dtalley on 04/23/2002 11:30 AM> > I have to agree with Jon - I'm just delving into the LAPI code here and have found the the LLValue object to be one of life's great unsolved mysteries. The API is written in such a manner as to where one has to test almost every facet of the API to figure out what it's doing. A few well placed examples would have done wonders to elicit a better understanding of the LLValue object and how it is meant to give us, as developers, an 'advantage'. Now, $800 in my opinion, is not necessarily a great amount to pay for training. However, as a developer I would have expected that the API be written in such a way that if I had Java programming experience I'd be able to at least figure out the basics. I'm a bit disappointed so far and will continue to go through method by method to see what these non-intuitive API's can do.> > [To reply to this thread, use your normal e-mail reply function.]> > ============================================================> > Topic: LAPI - Will It Ever Be Changed>
https://knowledge.opentext.com/knowledge/livelink.exe?func=ll&objId=2649433&objAction=view>
; > Discussion: LAPI Discussion>
https://knowledge.opentext.com/knowledge/livelink.exe?func=ll&objId=765428&objAction=view>
; > Livelink Server:>
https://knowledge.opentext.com/knowledge/livelink.exe>
; > -- Sean M. AldermanITRACK Systems AnalystPACE/NCI - NASA Glenn Research Center(216) 433-2795Calling a windowed operating system "Windows" is like naming anautomobile "Wheels."
eLink User
Message from Paul Jensen via eLink> I hate that I have to check the session object's status almost every> time I make a lapi call to see what happened.True enough. In my Java LAPI programming, I've tried to abstract the"status-checking" code into another function that throws exceptions,allowing me to program in a little more "Java-like" style.For instance, in a Java class that needs to make LAPI callsI'll define a function called "ensureSuccess()": public int ensureSuccess(int status) throws LAPIException { // wrap calls that return "status" with this fn if (status != 0) { String errMsg = "status: " + llsession.getStatusMessage() + "\napiError: " + llsession.getApiError() + "\nerror: " + llsession.getErrMsg(); throw new LAPIException(errMsg); } return status; }[Assume 'llsession' refers to a LLSession, and there's a Exceptionclass defined named 'LAPIException'. Please note that this code isuntested.]This function returns the passed-in value if the value is success. Ifthe value is failure, however, it takes advantage of the fact the theLLSession stores the "last error information" to construct a usefulerror message string and throw an Exception with it.EnsureSuccess() is used for wrapping LAPI calls throughout the rest ofthe class, like this: try { ensureSuccess(documents.CreateObjectEx (parentNode.getVolumeId(), parentNode.getNodeId(), type, subtype, name, cInfo, oInfo)); // ... some more stuff if it succeeded... } catch (LAPIException e) { // access the message info String errMsg = e.getMessage(); // .. handle the LAPI error appropriately .. } catch (IOException e) { // .. do the right thing for an IO problem .. }I find wrapping LAPI calls in "ensureSuccess()" less cumbersome thanconstantly checking status codes. It also has the advantage ofthrowing a "LAPI"-type Exception, so LAPI problems can be isolatedfrom other sorts of Exceptions in the catch() clauses. It's a simpletechnique, but I've found it useful.Has anyone else come up with an approach like this? At any rate, Ihope this helps.Cheers,Paul
eLink User
Message from Sean M Alderman via eLinkPaul,That's a cool way of doing it! I've done something similar to that butI put a method that returns the entire status string from the sessionobject in a session object wrapper. The wrapper method builds thewrapper string and I test a lapi call like -LAPI_DOCUMENTS docs = new LAPI_DOCUMENTS(sessionWrapper.getSession());int result = docs.CreateObjectEx(......);if (result != 0){ System.out.println(sessionWrapper.getStatus()); // then do what I need to do if it failed like // either break the loop or exit the program.}I think I like your method better. Does your LAPIException do anythingbeyond what it's super does?Thanks for the idea!On Tue, 2002-04-23 at 13:16, eLink Discussion: LAPI Discussion wrote:> Re Re Agreement w/Jon K> Posted by eLink on 04/23/2002 01:16 PM> > Message from Paul Jensen via eLink> > > I hate that I have to check the session object's status almost every> > time I make a lapi call to see what happened.> > True enough. In my Java LAPI programming, I've tried to abstract the> "status-checking" code into another function that throws exceptions,> allowing me to program in a little more "Java-like" style.> > For instance, in a Java class that needs to make LAPI calls> I'll define a function called "ensureSuccess()":> > public int ensureSuccess(int status) > throws LAPIException > {> // wrap calls that return "status" with this fn> if (status != 0) {> String errMsg = > "status: " + llsession.getStatusMessage() > + "\napiError: " + llsession.getApiError()> + "\nerror: " + llsession.getErrMsg();> throw new LAPIException(errMsg);> }> return status;> }> > [Assume 'llsession' refers to a LLSession, and there's a Exception> class defined named 'LAPIException'. Please note that this code is> untested.]> > This function returns the passed-in value if the value is success. If> the value is failure, however, it takes advantage of the fact the the> LLSession stores the "last error information" to construct a useful> error message string and throw an Exception with it.> > EnsureSuccess() is used for wrapping LAPI calls throughout the rest of> the class, like this:> > try { > ensureSuccess(documents.CreateObjectEx> (parentNode.getVolumeId(), parentNode.getNodeId(), > type, subtype, name, cInfo, oInfo));> // ... some more stuff if it succeeded...> } catch (LAPIException e) {> // access the message info> String errMsg = e.getMessage();> // .. handle the LAPI error appropriately ..> } catch (IOException e) {> // .. do the right thing for an IO problem ..> }> > I find wrapping LAPI calls in "ensureSuccess()" less cumbersome than> constantly checking status codes. It also has the advantage of> throwing a "LAPI"-type Exception, so LAPI problems can be isolated> from other sorts of Exceptions in the catch() clauses. It's a simple> technique, but I've found it useful.> > Has anyone else come up with an approach like this? At any rate, I> hope this helps.> > Cheers,> Paul> > [To reply to this thread, use your normal e-mail reply function.]> > ============================================================> > Topic: LAPI - Will It Ever Be Changed>
https://knowledge.opentext.com/knowledge/livelink.exe?func=ll&objId=2649433&objAction=view>
; > Discussion: LAPI Discussion>
https://knowledge.opentext.com/knowledge/livelink.exe?func=ll&objId=765428&objAction=view>
; > Livelink Server:>
https://knowledge.opentext.com/knowledge/livelink.exe>
; > -- Sean M. AldermanITRACK Systems AnalystPACE/NCI - NASA Glenn Research Center(216) 433-2795Calling a windowed operating system "Windows" is like naming anautomobile "Wheels."
eLink User
Message from Paul Jensen via eLinkHi Sean --> That's a cool way of doing it!Thanks! I find it makes procedural LAPI code much easier to read,because I can concentrate on what the LAPI calls are *supposed* to do,without peppering my code with more obtrusive status checks.> Does your LAPIException do anything beyond what> it's super does?Not usually -- it depends on the situation. I just like to haveensureSuccess() throw a derived LAPIException instance, instead of ageneric Exception instance, for those times when I need to catch a LAPIexception and treat it differently.However, it seems that usually in practice any error is fatal, so in thecase of a LAPIException (or any other Exception) I just try to diegracefully.Cheers,Paul
General_Dynamics_C4_Systems
So it's been what - over 8 months - any update?
eLink User
Message from David Slimmon via eLinkHi there John,Do you mean that you've been waiting for the sample code section on the KCfor 8 months or do you mean that you've been waiting for "a true OO/JavaAPI" (as mentioned in the first posting in this thread)?I'm assuming that you mean the latter since the Sample LAPI code section hasbeen published to the KC and is updated regularly with new content submittedfrom Customers, Partners and Open Text employees. There is some new contenton its way shortly. In fact, didn't you already submit one, John? I thinkwe have one from you that's going to be published in the next round. Icould be mistaken.The Sample LAPI Code area was published on 5/07/02 and are posted here forthose who haven't found it yet:
https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=2730495You
can submit samples to lapicode@opentext.com.The area isn't perfect I guess, but it's a start. And I know that it's nota replacement for LAPI by any stretch. But would love it if more peoplewould send their code samples and snippets to lapicode@opentext.com so thatwe can help people along with what is currently available -- especially VBexamples, which we appear to be short on.Regards,David___________________________________________O P E N T E X T C O R P O R A T I O NDavid Slimmon, M.L.I.S.Knowledge Manager
https://knowledge.opentext.comdslimmon@opentext.com-----Original
Message-----and waiting and waiting and waitingPosted by GenDUser11 on 09/27/2002 01:03 PMSo it's been what - over 8 months - any update?
Pfizer_Developers
Really the API needs to have a strongly typed object model, which LLValue is not. Also having an activity API that comes out of four objects is well, non-intuitive to a Java Developer. All the developers here know that it is possible to wrap your current API in something that is more like what Java developers are accustomed to using, most have them have done it on thier own already, and it is what this sentiment is coming from. Yes javadocs and better code samples would help, but these developers have been asking for it for a while now but for some reason it hasn't materialized. I have been looking around for this stuff for days with no avail so I am I just really bad at finding the docs ? Is there a problem with the way the site helps developers? Something seems broken because there are so many people desperate for information here.Here's a few suggestions:Simple "goto pages" for new developers, java.sun.com has done this with thier "first cup of java" tutorial, it also has a whole tutorial around the API, that should be on a "new developer" page simple to find and use.Just try this: goto
https://knowledge.opentext.com/do
you see *anything* about developers there? now search on "tutorial LAPI", guess what you find, the first thing that pops up is a discussion entry for someone who is trying to find a tutorial! All the other entries on the first page are Release notes. try the exact thing on any other software company website (Oracle, BEA, SUN) and a tutorial is right there to help the new developer.This isn't a flame, it construtive critisism. Make a better API document it well, and provide resources to developers and and your product with thrive.Respectfully,Clay
Bill_Morton
I would encourage you to check out the Java Modules Technology Preview release.
https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=3300631&objAction=viewTell
us if you like the javadocs and tutorial that are provided for the Java framework.Thanks,-Bill Morton
Mike_Woodruff_(mwoodruff_-_(deleted))
Was this ever created or was this another thing that was quitely brushed under the rug? Did OT ever create an area that developers can submit LAPI or any other developer code, suggestions, articles etc.?Alot of these code samples are months and years old. I don't see an area that developers can upload anything. It could be that i'm missing it.Michael
Janusz_Frydecki
I suppose you found the answer since you posted this but as information for others.WARNINGThis post requires knowledge of OScript and Builder.WARNINGtake a look to any base API (APIDOC for instance). In each one, if you look at the orphan of APIHandler (which is probably the base you should use), you'll see a feature (Script) named MakeStubs: this is the script that generate classes files.So what you have to do basically is to1- Orphan APIHandler2- Modify .fName to what you want as class name3- Create children. The Object name will become function name4- If you need parameters, modify .fPrototype value5- Define code in Execute6- Don't forget to set .fEnabled to true on functions and classes you want to createI'll try to do a more complete "tutorial" in a little while if time allows me ;)BTW, I would like to "launch" (I suppose somebody else already proposed in but in case) the idea of using a wiki instead of simple forums for code subscription and "tips and tricks". This way, we could get something more structured and more up to date on which both OT personal and 3rd party LL Developers could contribute easily to get the most complete Livelink documentation. No more SDK doc or unending threads, only complete or to complete documents.What do you think of it? Actual SDK documentation could be inserted into it as a beginning and then people could add their own experience to it.
testcsstaff_-_(deleted)
Message from David Slimmon via eLinkHi Michael,1. Yes, the area was created in November 2004:
http://knowledge.opentext.com/devzoneIt
is also accessible via a link on the KC's Enterprise Workspace.2. Customers and Partners can submit sample code, tools, utilities tolapicode@opentext.com. This email address was setup and running on theKC before the term "Wiki" even existed :)I have also read Diane's posting in this thread and think that it offersan interesting approach. However, in the several years thatlapicode@opentext.com has been open and available, we have not receiveda meaningful number of samples from the community. If there arealternative approaches that the Livelink SDK community of developerswould like to discuss for sharing ideas, please email me atdslimmon@opentext.com or drop me a line at 613.599.9335 ext 3332.Regards,Dave-----Original Message-----Was this ever created or was this another thing that was quitely brushedunder the rug? Did OT ever create an area that developers can submitLAPI or any other developer code, suggestions, articles etc.?Alot of these code samples are months and years old. I don't see an areathat developers can upload anything. It could be that i'm missing it.Michael
Janusz_Frydecki
Maybe I'm wrong but I think that maybe it is because the lapicode@opentext.com address doesn't seem to be clearly stated anywhere (or maybe I simply missed it).And from now on, I'll try to sign my messages ;)Louis
Janusz_Frydecki
Mainly, we use exactly the same concept as you. The only difference is that we added some more specialized exceptions to be able to trap specific cases. Also, since we did a full wrapper around LAPI, we almost never have to add this check manually into our code.To use it, you simply wrap your LAPI call within the shared CheckError function and it will raise an exception if one is detected.And since we talk about .NET, I think that the fact that not EVERYBODY uses Java forces OT to use more generic approaches.
testcsstaff_-_(deleted)
Message from David Slimmon via eLinkIt's a fair point...The lapicode@opentext.com *was* clearly stated on the KC way back whenthe mailbox was originally created. But we were a little "underwhelmed"by the amount of email it generated, so it's been pushed down somewhat.If people are in the mood for sharing, and I'm a glass half full kind ofguy who thinks that they are, by all means pass along sample LAPI code,snippets, ideas, utilities etc. to lapicode@opentext.com for our review.Assuming that the code itself isn't particularly malicious orproblematic, we'll post it on the KC for everyone to see, with all theusual "use at your own risk, not supported etc." type disclaimers ofcourse.Cheers,Dave-----Original Message-----Maybe I'm wrong but I think that maybe it is because thelapicode@opentext.com address doesn't seem to be clearly stated anywhere(or maybe I simply missed it).And from now on, I'll try to sign my messages ;)Louis
Janusz_Frydecki
It seems that the idea was already in progress at OT since according to the Newlink Editor, it is already in place.'Best Practices' WikiShare what you know with other customers on Open Text Online Communities It's great when you discover something new about an Open Text product ? some pearl of wisdom that really helps you administer a system, develop custom code or another way to help users be more productive. However, all too often, that valuable knowledge remains lost and buried from the user community at large. Now, you can share those insights through the Best Practices Wiki on Open Text Online Communities. Read More (Community login required.) Wiki link:
http://content.dynamicmessenger.com/opentext/?eCSXg7-jwbM31MDc-lsUh4Anlie&http://communities.opentext.com/communities/llisapi.dll?func=ll&objId=162165&objAction=WikiViewRead
More link
http://content.dynamicmessenger.com/opentext/?eCSXgD-j0bMz1OLdXlsUh4An5ge&http://communities.opentext.com/communities/llisapi.dll/1536628/Wikis.doc?func=doc.fetch&nodeId=1536628&viewType=1Community
Login Required (why not a knowledge login ?!? :-S)
Declan_Wilson
Interesting to read all the same problems that I am experiencing...It seems that the LAPI code is a direct mapping from the propriertary Oscript version of these methods. In no way would I describe it as a Java API.Howinever, 6/7 years later, from the original post ... can I ask have OpenText revised the LAPI code, to something more standard?Is there a community area up and running yet?Is there a shared examples area?
