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: > Hi Jun, > > Looking better and better :) > > Here are some extra pointers based on your video: > > 1) Instead of 'Edit' or 'Reply To Comment' buttons in the comment editor, > use the standard Save command for an editor and mark the editor window as > dirty when it needs saving. Warn the user of an unsaved/modified editor when > trying to close it, etc. > 1.1) On the same note, I notice that the RCP that you are running does not > have the button toolbar. Maybe we should have some common sense buttons like > save/save As, undo, cut/copy/paste and maybe some other too. 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. > 2) When adding/removing an attachment/comment/page/etc., the general rule > should be to refresh as little as possible. So you should refresh just the > Attachments/Comments section of the current page and not all the current > page's sections (or even worst, the whole navigator). Even better, you could > (based on the internal notifications) just add(or remove) the new elements > to the UI instead of refreshing everything. All of this minimizes the > trafic, reduces waiting time, does not confuse the user and generally helps > performance :) Remember that this is a general good practice, but if you > have time issues, you could have the first versions just refreshing small > sections instead of doing individual manipulations. > 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. > 3) Just like you did for comments or annotations by displaying the author > (first property), you can do the same for general objects, when grouped > under their class name. You can just show "[objectNumber] > firstPropertyValue". The XWiki object editor treats things a bit more > customized [1], preferring the first property matching the pattern "*name*" > or "*title*", if not, the first String property and, if that fails too, the > first non-TextArea property. (note: the current implementation is a bit > buggy and takes the last String or non-TextArea property instead. See [2] > for the correct version.) > > On the other hand, all this "nice" information (first property value) can > cause a heavy load on the server since it involves retrieving every single > object and getting it's property value. In the object editor, all this info > is easily obtained by a database query, but in REST we have to do a lot of > queries to get the same data. So if we have 1000 comments on a page or 1000 > objects of a specific class, if we try to list them, we will make 1001 > requests instead of just 1. Even if this is asynchronous and the user can do > something else while the objects are retrieved, the benefit might not be > worth it. > > The debate here is whether to display the first property value for > everything like comments, annotations and generic objects (for a better user > experience in low-page-load conditions) or for nothing at all (because of > the performance overkill). > 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. > 4) You might want 'Download Attachment' and 'Update Attachment' to be the > first actions for an attachment and 'Delete' to be the last. Otherwise, you > risk pressing delete unwillingly. It is a general best practice to put > destructive actions towards the end of the actions list and main/most used > actions towards the top. > > 5) Minor note: Highlighted Text property of XWikiComments class is not used > AFAIK. It's ok to leave it there in case we start using it, but just so you > know, I don`t know any place where it is actually used. Maybe it's a step > towards merging annotations with comments, but that's another topic of > discussion :) > > Thanks, > Eduard > > ----------- > References: > [1] > https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-web/src/main/webapp/templates/editobject.vm#L57 > [2] https://github.com/xwiki/xwiki-platform/pull/15/files > > On Thu, Jul 14, 2011 at 10:04 AM, Vincent Massol<[email protected]> wrote: > >> Hi Jun, >> >> On Jul 14, 2011, at 6:14 AM, Jun Han wrote: >> >>> Dear all, >>> >>> I put another short demo for the work I have done. >>> The URL is http://youtu.be/L9UCoa4N8hE >> Wow this is really cool! Well done! >> >> I'm now eager to start using XEclipse again :) >> >> Is there a version I could test (for my mac)? >> >> Thanks >> -Vincent >> >>> The major work includes: >>> 1. grouping various page objects together, e.g., attachment, comment, >>> class, object (annotation and customized class objects) and tags >>> 2. comment resource >>> get comment list and property, create a new comment, reply to an >>> existing comment, (currently, deleting a comment is not supported in >>> REST API yet) >>> 3. attachment resource >>> get attachments and their property, upload a new attachment, update >>> an existing attachment, and remove attachments >>> >>> I am now working on creation and edition of tag, object property and >>> page via REST API. >>> >>> Best regards >>> >>> Jun Han >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
