| 12 | | * Code requirements: |
| 13 | | * Create palette for listing server resources, make it work synchronously with the existing connections palette. |
| 14 | | * Add interface for resource part of the facade, since it currently has only user and group interfaces. This facade functionality will need 2 imlpementations : server-side and client-side. The client side will be used by the palette, the server one will provide resource access to the web services and the web UI. |
| 15 | | * Decompose the server in appropriate modules, at least having separate persistence and core. See the implementation idea for this. Refactoring will be needed. |
| 16 | | * For this revision, it would be better to fake the persistence module - everything will be persisted in the memory. This way, implementation will be easier and module dependency will be minimal. |
| 17 | | * The S2S core module must work with real Sophie2 resources, users and groups must be also resources (users and groups are part of another task, but they must be integrated in the new structure anyway). S2S core should not be directly accessible from the web ui, web services ot from the client. Only the facade will be able to do this. |
| 18 | | * Facade will expose the core functionality to the WS, DC and Web UI. It will have direct access only to the core. |
| 19 | | * S2S core should have the ability to work with custom Sophie2 resources, the facade should provide these methods to the other modules. The web services must be able to serialize the resources in order to pass them to the client. |
| 20 | | * UI : |
| | 11 | * Decompose the server in appropriate modules with well-defined functionality (and do the refactoring needed): |
| | 12 | * The core and the persistence should remain in separate modules. |
| | 13 | * Persistence at this iteration is not a requirement. It can be fake (dumping everything to memory) for ease of implementation. |
| | 14 | * S2S Core module should use the base resource model of Sophie2 (that includes book, users and groups at this iteration). |
| | 15 | * S2S Core should be accessible from the web UI, the web services or the client only through the facade. |
| | 16 | * Facade will expose the core functionality to the WS, DC and Web UI. It will have direct access only to the core. |
| | 17 | * See the Implementation idea for a draft diagram of the modules decomposition. |
| | 18 | * Add resource access support to the facade (it currently only provides access to user and group managers): |
| | 19 | * Implement both the server-side and the client-side of the facade. The former will provide resource access to the web services and the web UI, while the latter will be used by the new palette created. |
| | 20 | * Provide ability for the web services to serialize resources in order to pass them to the client. |
| | 21 | * Create a palette for listing server resources and make it work synchronously with the existing Connections palette (i.e. display the resources of the server we are connected to): |
| | 22 | * It should be in the Servers tab in the left flap. |
| | 23 | * At this iteration it should list all the resources on the server (users, groups, books). No resource list filtering is required. |
| | 24 | * It should support opening a book on a double-click (other actions will be implemented at a next iteration). |
| | 25 | * It should be consistent with the Resources palette. |
