Managing upgrade cycles

[innes]

Hi
We are prototyping integrating dotCMS & KonaKart.

How would I upgrade the KK plugin & dotCms/KK themselves without losing existing setup but also gaining new functionality/bug fixes?  How do we handle the scenario where we need to edit the "view" defined in the plugin to suite our requirements? For example from the evaluations we have done so far, the plugin expects 4 images on the product detail page but we normally only have one.  This results in the missing image icon being displayed. We can edit this locally but the more changes we introduce to the plugin the greater the cost in upgrading to new versions (that I assume will be required for newer versions of Kk). 

The raises an assumption on our part:  will the plugin be maintained going forward or is it purely designed as framework that we then run with?

Regards,
Innes

[trevor]

will the plugin be maintained going forward or is it purely designed as framework that we then run with?

It's designed as a framework that you run with, similar to our Struts / Tiles / JSP store-front application. The cool thing is that all of the (non UI) functionality integrated into dotCMS, comes from the KK APIs which remain very stable. This allows you to modify the current UI and add new functionality but still be able to upgrade to newer versions of KK rather painlessly just by copying in the new jars.

To give you an example of the stability of the APIs, the Open Laszlo demo http://www.konakart.com/konakart_cat_inspector/main.swf has been running since 2008 without modifications and now is connected to the latest 5.2 engine. You can see that it still has the original KonaKart logo !