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 : 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 :

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.

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.

Website Designed by Adservio Consulting      Bookmark and Share Valid HTML 4.01 Strict    Valid CSS!    Level A conformance icon, W3C-WAI Web Content Accessibility Guidelines 1.0