What would Developers like to see in Livelink 10 ?

With the new version beginning to appear in presentations and betas in the wider Livelink communities, I've begun thinking about what kind of things I would like to see in the next release. At present, the majortity of my time is focussed on development with Livelink, primarily with OScript and Web Services, so the focus of this blog article is about what could Open Text do to help developers with Livelink 10.

Documentation within the OScript

A lot of the Livelink OScript code is poorly, or in some cases oddly, commented within the OSpace such as the following from the ExecuteWithLogin method from WebLL:LLRequestHandler :

// Bummer. Couldn't log in, so redirect to the login page.
if ( .ExternallyAuthenticatedUser( r ) )

In lots of cases, the Documentation feature is not populated with any useful information, if at all, for other developers looking to work with, or reuse, the functionality within that module in their own module. This can slow down the development of new functionality and mean that developers can be forced to reinvent the wheel or miss some really useful bits in other modules as a result.

Documentation

While the Builder OnLine help is a good resource for the base functionality, methods and properties of the various Livelink development components such as LAPI and OScript, it could do with a few enhancements such as the following :

• Inclusion of more example code within the existing code
• Update the create new Workflow Task documentation
• Provide some more detailed example code, building on sample module
• Additional modules - such as Records Management, Explorer - should add their own examples showcasing the functionality that they add

OTDN (Open Text's version of MSDN) could be a very good resource for this, but currently seems quite sparsely populated and used both by external people, such as myself and Open Text staff, this is slowing down the growth of what could be a wonderful asset for the Livelink Development community. Other sites such as my own Livelink site , Tek-Tips and Yahoo! groups provide some coverage in this area.

From my experience, and talking to others, I've identified a few reasons why people don't contribute to OTDN :

• In some cases, people are happy to publish code but their employer or IPR restricts what they are permitted to publish externally.
• The majority of MSDN content is created by MS staff, so there is a perception that Open Text staff should be the main contributor, if only initially.
• For many people the higher salarys offered to those with Livelink skills as opposed to say .Net, Java or PHP mean that the less people that know the more money can be charged by those that do, basic supply and demand.
• For some there is a perception that they are not "guru's" so they should leave the posting to other more well know people.

Code Refactoring, coding standards and coding types

In some cases the code needs to be updated and overhauled or removed, while this is part of the lifecycle of any software application, there are a few areas within Livelink which lead to confusion for developers old and new.

• Each new major release offers a change to refactor existing code to take advantage of new features in the core product, such as the inclusion in 971 of eLink and WebDAV, or common technologies such as AJAX and Skye, but given development contstraints and timescales not all the code will be reworked.
• The mix of OO and Functional program, for example within the Agent processing in functional code we instantiate the individual Agents in an OO fashion.
• The mix within functions of using .f<something>, parameters being passed to the method and globals.
• A lack of common coding standards, for example the ID of a node is called OBJID, ID or NODEID in various Request Handlers.

Adding in "advanced" Developer Training/Support

The OScript training course and the Certification track provide a solid foundation for developers to develop using OScript, but there are many things that given the scope and timescales of the course it can't cover. In some cases these are small bitty things that can be worked out, for example adding an Audit event, or more complex components such as Sessions, Caching, Subsystems and the like. The new courses specific to Web Services and Workflow Customisation are welcome additions to the schedule along with the LAPI course.

Also the plethora of modules means that Customer A can be significantly different to Customer B in terms of what additional modules offer, such as the inclusion of Livelink Explorer provides a lot more new functionality that a developer would need to be aware of or have the chance to take advantage of.

It would be good if Open Text could offer a few advanced developer focussed sessions, either as formal courses, 365 Webinars, Content World or Content Day seminars or perhaps even specialised Developer Days similar to that offered by Microsoft Tech Days.

Some firms such as Wisteria already offer a Developer focused support/mentoring option, and Open Text also offer a similar service via their Support / Global Services arm.

Support for debugging in the Web 2.0 Livelink/Content Server world

In earlier versions of Livelink, a browse page was effectively built using the following code :

for each row
    process and then print out the row
end

If there was an invalid value causing the page to crash we could add a breakpoint and step through the code to identify the cause. With the move towards Web 2.0 type controls and the use of JSON, AJAX and the like this kind of debugging has moved out of Builder and into the Javascript layer, where tools like Firebug are required. While these technologies have plenty of coverage and tutorials on the internet, and the removal of comments and replacement of meaningful variable names such as defaultColumnNames with shorter versions such as x1 to reduce the size of the file, and thus the response time of the request, but can slow down developers and support staff working though issues involving them. It would be useful to have some information on how Livelink utilises them, taking the above example something along the lines of the following :

JSON String returned from LL RH
JS function buildPage called
    String broken into an Array by JS function processJSON
    SubType icons added to Array by JS function getSubTypeIcons
    Header row for output table generated based on JSON data
    Each row added to table
    table added to DIV using innerHTML

Overrides for Properties files

You can already Override, Orphan or Patch OScript code within a module, as taught on the OScript training course, there are modules such as CustomizationsRT which provide a simple way to override Weblingo pages. Changes to the Weblingo / OScript code can also change the path to items in the Support directory, for example we could amend the weblingo that outputs a reference to the core Livelink CSS file, livelink.css so that it points to another file such as livelink2.css.

The one common thing developers / administrators want to do is to replace items in the Properties files, for example change "My Home" to "Our Portal" for example. At present you have to directly edit the Properties file in the module's ospace directory. This changing of content of files in core Livelink folders is considered bad practice and changes can be lost during a patch cycle or upgrade. It would be good if you could simply override any property file entry in a later loading properties file, trying this at present loses all other properties entries with the same root - the part of the properties label before the full stop.