AnsweredAssumed Answered

UI - Business logic decoupling for SPARK core classes

Question asked by mirceac on Aug 15, 2011
Latest reply on Aug 26, 2011 by mirceac



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.