| 53 | | ^(Describe your design here.)^ |
| | 53 | == Redesign Resources == |
| | 54 | * We need to redesign the Account pro object. As the model is now based on base model ResourceR4 module we need |
| | 55 | AccountR4 and AccountH to present accounts. |
| | 56 | * For persisting sjrb format will be used |
| | 57 | * Due to some bugs in !FileEntryManager persistence may fail. |
| | 58 | |
| | 59 | == Redesign AccountManager == |
| | 60 | The !AccountManager class may be dropped and all the functionality which it provides may be in the !ConnectionsPalette. |
| | 61 | |
| | 62 | == Create the UI == |
| | 63 | * Icons for connected/disconnected will be added. |
| | 64 | * To be able to add items in the !ListPalette a custom !ListCellRenderer should be implemented. |
| | 65 | * Icons for add/remove/edit server buttons will be created. |
| | 66 | |
| | 67 | == Server Logging == |
| | 68 | * In order server to be logged from custom source but not from the logging facade class some changes on the logging are needed. |
| | 69 | * We need to change the !LogEntry source. It wont be a stack trace element but a string which will be by default toString of the Starck trace element. Old functionality will be saved, but also extended for our needs. |
| | 70 | == Mighty Class loader == |
| | 71 | * A mighty class loader is needed in order the !ClassPersister to load classes throughout the modules. |
| | 72 | * The easy way to solve this is to implement a Mighty class loader which is felix dependent. |
| | 73 | * It will go through the modules and gets their activators (it is possible if we have access to the felix impl classes). After we have the activators we will have their class loaders and can delegate to them. |
| | 74 | * The only specific think here is that every module which declares a class which should be loaded through !ClassPersister must have a !BundleActivator. It may be a dummy one if no extensions/extensions-points are needed. |
| | 75 | * This mighty class loader will be registered as system property by the launcher of true editions. and can be used by the persister. |
| | 76 | == Persistence for keys == |
| | 77 | * Some auto actions need use keys from the resourceR4 model classes. When they are used for example just like |
| | 78 | {{{ |
| | 79 | changer.setRaw(ResourceR4.KEY_KIND); |
| | 80 | }}} |
| | 81 | it is ok. The key is not becoming a part of the auto action class's body. But when a method of the key is called, for exampple |
| | 82 | {{{ |
| | 83 | changer.setRaw(StyledElement.KEY_BORDER_INSETS.getLocked(), input); |
| | 84 | }}} |
| | 85 | the key will be part of the class's body and will have to be persisted. |
| | 86 | * key persister will be implemented which uses the resource info providers. |
| | 87 | * It will persist only keys form the model (declared in the ResourceR4 classes or the interfaces they are implementing) |
| | 88 | * !MetaKeys will not be persisted. The must be used outside of the auto actions, or find out a way to persist them in other task. |
| | 89 | * !UndefindedKeys are special kind of keys that are persisted in different way, they are used by the remote resource model and internally by the !ResourceModelChanger. They will still be persisted in the old way and '''must not be used in the auto action implementations''' |
| | 90 | |
