UI - Business logic decoupling for SPARK core classes


While working on SPARK-1403 ticket, I faced various difficulties when I tried to provide extension mechanism to be able to extend Spark core classes

like: ContactItem/ContactGroup/StatusBar etc through plugins

In most all cases, the biggest problem was that Class constructors are used for building UI and also for filling UI elements with data. I think that we should create separate methods for building UI and separate methods for gathering data, filling UI elements with data etc

Ideally, we should also invent some sort of life-cycle mechanism where building UI, gathering data, filling UI with data, event handling are very precise tasks, and each task to have a very precise execution place. We should build interfaces/abstract classes that model this life-cycle, interfaces/abstract classes that can be implemented/extended by Spark and through plugin as well.

This is a much bigger task, but we can start doing the following:

  1. Create separate methods for building UI

  2. Expose UI elements to be available in sub-classes by making them protected

3.Try to organize data gathering, or general data manipulations actions in dedicated/separated methods

4.Class constructors to be as simple as possible, and only call precise initialization methods

I have a patch attached to ticket SPARK-1403: Enhance ability to extend core classes like ContactItem, ContactGroup, etc through plugin

that does some of what is described aboved, and also introduces a mechanism to register plugin instances in place of original Spark instances for various of core classes. I tried to provide as little as possible changes in spark code, and the original behavior of classes is not changed.

Based on above, the patch can be improved, but this is a start - and feedback is welcomed.



Any improvement in this area is highly welcome. The contact group is really hard to fix or work with. Two senior students were basically failing to get some bugs ironed out.

I am a little scared about the impact of this change to Spark stability. How big is the chance that side effects kill off features?

I have a patch attached to SPARK-1403 opened ticket, also some explanations and a sample plugin attached

The patch goal is to make as little as possible changes in Spark code, but in the same time to offer high flexibility on extending core classes through plugin.

The patch does not change the functionality of the touched classes, it just offers the posibility to register extended classes through plugin, and separates a bit business logic code from the UI/layout code.

I also tested the patch pretty much in the last couple months and there is no side efects that I have noticed.

The job of UI/business logic separation is pretty complex indeed, and we have to be very carefull not to alter Spark stability, but to improve it… So I think that making “baby steps” is the best approach here

Please have a look over my comments and patch - posted on SPARK-1403 ticket

Well, It would think that it is a good idea to do a 2.7.0 alpha with your changes. We will move Smack to the trunk plus additional changes to fix file transfer ans jabberd authentication.

I have also asked Daryl (akherz) to update the build environment to Java 7.

Let’s put your changes in and go for a Beta by the end of the month or early September…

Agree, Thanks - I will put my changes early next week. I will do that step by step, to have a clear view of the changes…