Changes between Version 28 and Version 29 of GROUP_APP_SERVER_RESOURCE_ACCESS_R0
- Timestamp:
- 06/16/09 15:31:41 (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GROUP_APP_SERVER_RESOURCE_ACCESS_R0
v28 v29 72 72 73 73 === Facade === 74 Currently, the facade interfaces - Facade, UserManager, GroupManager are located in org.sophie2.base.connectivity. They have 2 corresponding implementations - one for the server core, and one for the web services connector. 74 75 For server resource access, the facade needs to implement an additional method - getResourceManager() that will return an instance of the ResourceManager class. This is a new class that will be created and will support basic manipulation of resources. It should have the following methods (at this iteration): 75 * getResourceList(). It will return list of all book resources on the server (without users and groups). Actually returns ResourceRefs, which hold enough information for resource names, resource IDs on the server, etc.76 * getResource(String entityId) - will get a resource by a given entityId.76 * getResourceList(). It will return list of all book resources on the server (without users and groups). Actually returns absolute ResourceRefs, which hold enough information for resource names, resource location, etc. 77 * getResource(String absoluteLocation) - will get a resource by a given absolute location. 77 78 There will be concrete implementations of these methods in both the client and the server. [[BR]] 78 79 … … 82 83 A class ServerResourcesPalette will be created in org.sophie2.main.func.servers. It will track the currently selected element in ConnectionsPalette (using the findNearestElement method) and if there is a connection established, it will use it to obtain a list of server resources. The only action it will support at this iteration is double-click on a book item. This will get and open the selected book, using the current app logic. 83 84 84 * Client implementation of Facade: getResourceList() will be implemented analogically to the login() method - the list of resourceRefs will be sent in XML format and read analogically. For the new references to be reconstructed we only need the location and entityId. For getResource(), the client facade needs to download the persisted file and use the loader to open it. After that, it will be returned as a result.85 * Client implementation of Facade: getResourceList() will be implemented analogically to the login() method - the list of resourceRefs will be sent in XML format and read analogically. For the new references to be reconstructed we only need the absolute location. For getResource(), the client facade needs to download the persisted file and use the loader to open it. After that, it will be returned as a result. 85 86 86 87 === Server === 87 The BookService class does not make sense anymore (a Book is a Resource), but it could be useful for resource management. BookService will be renamed to ResourceService (its tests , too). It also needs some changes:88 * deleteBook can accept EntityID instead of a resource as an argument.88 The BookService class does not make sense anymore (a Book is a Resource), but it could be useful for resource management. BookService will be renamed to ResourceService (its tests and methods, too). It also needs some changes: 89 * deleteBook can accept absolute location instead of a resource as an argument. It should also be renamed to deleteResource. 89 90 * getAllResources must return List of ResourceRefs instead of a list of Resources. 90 * The same applies for searchBook. 91 * A getResource(entityId) method is needed; 92 The BookDao must also be refacored as ResourceDao. It should also have the getResource(String entityId) and getResourceList() methods. [[BR]] 91 * The same applies for searchBook. It must also be renamed to searchResource. 92 * A getResource(absoluteLocation) method is needed. It must use the ResourceRef#getAbsoluteReference(String absoluteLocation) method in order to provide enough information for referencing resource on a server. This reference does not give us information about the EntityId of the reosurce, so for performance issues it would be best to use resource location as key in the fake persister (implemented in [wiki:GROUP_BASE_SECURITY_R0]). 93 * All the methods here must accept absoluteLocation as arguments, not entityIds. 94 The BookDao must also be refacored as ResourceDao (as well as methods and tests related to it). It should also have the getResource(String absoluteLocation) and getResourceList() methods. [[BR]] 93 95 The Web Services need also ResourceWebService. It will be a very-proto-revision and currently will persist a particular resource, making it available for download. Then, the file will be written as a response using output stream. Also, will use the XMLManagementService to pass the list of ResourceRefs for getResourceList() method. 94 96 95 97 * Server implementation of the Facade: just call the core methods and return their results. Tests seem trivial, since this facade has no logic for now. 98 99 * If there is time left, move all the *service logic to the corresponding *manager class. The main idea here is to have a simpler server core - it will only be a facade implementation. This is not a requirement of the analysis, so it is not obligatory for this revision. But it will ease the core structure and therefore the module decomposition. 96 100 97 101 Base tests for this task are:[[BR]]