Re: [xwiki-devs] [GSoC] XEclipse RESTification

Hi Eduard, Thanks a lot for your comment. I will modify the source code accordingly. Some reply to your comments are added below. On 07/14/2011 08:40 AM, Eduard Moraru wrote: The current behavior for comment editor is: 1. user edit comment fields and can save/modify freely, but the save will not submit the comment to server 2. when "new comment" or "reply to " button is clicked, it will gather all the information (saved or unsaved) and submit it to the server, then close the editor even if it contains unsaved information. In the future development, when user click "save" or press "ctrl+s", the information will be saved to local storage. When user click "close", prompt dialog will ask him/her to save it locally or submit to server. I think, we may add button toolbar. But I will postpone it after local storage has been implemented, which is not trivial. I spent a lot of time trying to figure out how to refresh the tree view. However, there is not too much success. When refresh(object) is called, it does not expand the children as expected. I think it might be the reason that refresh(pageSummary) is called instead of refresh(objectCollection). However, two performance issues are that (1) object collection can only be obtained from pageSummary.getChildren() and not available directly from objectCollection's child (e.g., a comment or attachment), (2) from one specific comment, we can only obtain the *"page"* information and not the *"pageSummary"* via REST API. If we only want to only refresh the objectCollection, the current way is to ask server for page summary information, and another way would be to ask local storage, which has not been incorporated yet. This is indeed the case for objects, in order to show the objects identified by its "author' field or other first property. I need to get the object properties first and do a filter based on all the properties. Right now, I filtered out *"comments"* and *"tags"* when displaying objects, as they have dedicated Urls (e.g., ...page/myTestPage/comments, ...page/myTestPage/tags) and thus treated differently. For the comment, make REST call to .../page/myTestpage/comments will give a list of available comments including the "author" and other property fields. Therefore, no need to query object properties further. The current objects category includes *"annotations"* and *"customized class objects"*, which are shown as separate sub-category under "objects". In order to display then, additional calls to object properties have to be performed. But I think, the queries regarding object properties are decreased already, as comments and tags are handled in other Urls. Annotations might cause troubles if there are thousands of them in one page. But I think that is okay for the user who wants to edit the object properties. For 80% users, they may never need to expand the *"objects"*, not to mention its sub-categories.