Intro

Part I

Part II

Part III

Part IV

Part V (4.1)

Part VI (6.0)

Summary

When BroadVision moved to version 4.0, they radically altered the way that BroadVision sites were developed. Instead of wrestling with a fixed set of standard 'objects' and having to write hundreds of lines of C++ to extend the framework, the product is now powered by server-side JavaScript and a much more accessible set of 'components'.

This means that instead of arcane database accessors, list objects and loop tags, you can now write something that is readable:

	<table>
	<%
	// get a handle on the content database:
	var db = new BVI_ContentManager();
	// columns to fetch:
	var cols = new Array( "OID", "TITLE", "PRICE" );
	// specify SQL WHERE clause:
	var result = db.contentByCondition( "AUTHOR = '" + author + "'",
			"Bookstore", "PRODUCT", cols );
	if ( result != null ) {
		// got some results, sort them:
		result = result.sortByAttribute( "TITLE", 'a' );
		for ( i = 0; i < result.length; ++i ) {
			var row = result.get( i );
	%>
		<tr>
			<td><%= row.get( "TITLE" ); %></td>
			<td>&#163;<%= row.get( "PRICE" ); %></td>
		</tr>
	<%
		}
	}
	%>
	</table>

This is good news for many, many reasons but most importantly because:

• you no longer need C++ gurus to build BroadVision web sites - JavaScript programmers are easier to find and cost less (no offence!),
• you no longer have to deal with an edit/compile/restart BV/debug cycle - your development cycle is much shorter.

In Part II, I complained about how awkward session management was and, in particular, that you could not store arbitrary data on the server-side during a session. This situation has improved in several ways. First of all, there is a 'Session' variable that can be used to access information about your session state directly, rather than writing C++ objects to wrap the primitive API. You can store strings as dynamic session properties:

	Session.finalPage = "basket.jsp";

On a later page, we can retrieve this and construct a link to that script:

	<a href=<%= dquote( makeScriptURL( Session.finalPage ) ) %>>Continue</a>

You can also store BroadVision components as session properties, although you cannot store arbitrary JavaScript objects. Since you can store BVI_ValueList and BVI_Properties components, this is not really a problem. I also complained that there were no high-level concepts embodied in built-in objects, such as user profiles. Version 4.x rectifies this problem by providing a BVI_Visitor component, through which you can access everything you need regarding a web site user. In fact, many of the 'obvious' high-level concepts now have physical representations within BroadVision's much-expanded component API. It is much more object-based than version 3.0 (it can't be object-oriented due to JavaScript's restrictions on inheritance but it tries its best). One of my other big complaints about early versions of BroadVision was that the C++ objects were used to generate HTML. This meant that if the object didn't generate exactly what you needed, you had to start writing C++! A couple of specific examples I gave were lack of <TEXTAREA> support and the inconsistencies in the support for <SELECT>. This sort of problem has been resolved by the very sensible approach of separating the logic from the presentation: HTML is used as expected and all the logic is dealt with in JavaScript, using BroadVision's components as necessary. If you want a textarea input field, you write HTML to produce one - the JavaScript contains the logic to handle the field's value, regardless of how it is input.

The bottom line is that BroadVision development is now faster and more cost-effective; sites can have far greater functionality because the framework is much easier to customize; BroadVision skills are easier to find (or learn) so market support for the product is vastly increased, leading to greater uptake of the product and therefore much better support from BroadVision themselves.

This deserves a special mention. In version 3.0, the navigation framework was restricted to just channels, programs and content. Version 4.1 allows channels to contain subchannels and separates the navigation structure from the content structure much more effectively. Version 3.0 required extensive use of programmed rules to target content to visitors - these were time-consuming and error-prone to create and slow to execute. Version 4.1 replaces almost all need for rules with a streamlined "broadcast attribute" system that allows administrators to specify 'visibility attributes' on programs and for visitors to allow the system to automatically determine which visitors get to see which parts of the navigation structure (and, hence, which content).

With the release of version 5.5 in 2000 Q3, BroadVision revamped KWA and renamed it InfoExchange. In addition to all the navigation infrastructure, they added collaborative tools, discussion groups, issue management / escalation. As an out-of-the-box application, it provides a lot of functionality for building Intranets and Extranets.

It's not quite all good news. C++ 'objects' have been replaced with C++ 'components' in version 4.0. If you really need to extend the application framework at a fundamental level, you still have to write C++. The object structure is somewhat more pleasant, partly because much of the 'glue' code that links your C++ to BroadVision's JavaScript can be automatically generated. At least with the rich JavaScript API, you don't actually have to write components very often.

With version 5.0, BroadVision added the ability to write new components in Java - up to a point. If you wanted to extend (or even use) existing components in your new component, you were still stuck with C++.

Version 6.0 promises a full Java API as well as support for a J2EE compliant application server to be plugged in alongside BroadVision. More on this in a separate article!