Dear All, According to the previous discussions and the current implementation of xeclipse's local storage, I propose the following steps to develop the new local storage for xeclipse: 1. flat structure of cache or local storage local_storage |--wikis ->wiki summary |--spaces ->space summary |--pageSummaries ->page summary |--objectSummaries ->object summary |--pages -> actual page |--objects -> actual object 2. cache mechanism 2.1 every time, when user retrieves remote information of wiki/space/page, store the summary information in the corresponding folders if it is cached yet. 2.2 every time, a page or an object is opened, cached it to pages/ or objects/ folder 2.3 maintain an index of last visited objects/pages 3. cache format I plan to use json to replace the current xml serialization, because json is more efficient in marshalling and unmarshalling. The libary of gson will be used to perform the job. 4. index I am not sure how to implement index for this flat structure. To me, hashMap might be enough; key is the xeclipse id and value is the actual object/page/space/etc. I have looked at several popular cache libraries (e.g., jboss cache, hibernate, EcipseLink, etc.), but it seems to me that they are over-killed in this case. Any advice would be highly appreciated. Best regards Jun Han On 06/27/2011 06:36 AM, Eduard Moraru wrote:
Hi Jun,
On Sun, Jun 26, 2011 at 2:00 AM, Jun Han<[email protected]> wrote:
Dear All,
I have some questions about the LocalDataStorage implementation and Page resources display.
1. The current LocalDataStorage implementation uses xmlrpc model and the cache structure looks like the following: index |-space |-page
As the xmlrpc model is being replaced by org.xwiki.eclipse.model package, do we need to modify the local storage as well,
Yes, LocalDataStorage needs to be refactored to use org.xwiki.eclipse.model objects.
e.g., adding a folder to store various wikis?
We definitely need to take into account multiple wikis. Either we add a new folder in the existing hierarchy or we have a flat index where the wiki, space and page are part of the file name. Currently, the index is structured hierarchically but the actual pages/objects/etc. have a flat structure.
I see no point in having (1) different locations and (2) different structure for index and data. These 2 should be merged into a single hierarchical structure inside the 'local_data' folder.
But, since you need to advance quicker on the REST implementation, I propose that, for now, you just extend the current structure to include wikis.
I am not very clear about how local storage works. My rough understanding is like this: (1) When user accesses a page, local cache stores it. (2) Whenever user makes a change in the editor, store it in the local cache (3) when user performs a submission, synchronize the content
Yes, you have all the details in https://github.com/xwiki/xwiki-eclipse/blob/master/plugins/org.xwiki.eclipse...
Basically, the get methods also store in the local cache (if connected) or retrieve from local cache (if offline). Store methods save locally and synchronize with the remote wiki (if conencted) or just save locally if offline and later on, when the connection is available, synchronize with the remote wiki.
2. I have asked how to display page information before, the suggestion from Eduard is the following: ------ WebHome (PageSummary) -------- Attachments ---------- dog.png ---------- spreadsheet.xls -------- XWiki.XWikiComments ---------- 0 : Administrator ('author' property value) ---------- 1 : Guest ---------- 2 : Administrator -------- XWiki.MyClass ---------- 0 : etc. ---------- 1 : etc.
However, I am not sure what else needs to be included? e.g, annotations, versions, history, translations? Once confirmed, I will start working on the page content.
I`d like to add that annotations should be displayed just like normal XWiki objects, same as comments. Also, history(=versions) and translations should be kept in a menu.
The only reason why I suggested that we display Attachments in a special way is because, internally, they are not handled as XWiki objects and that forces us as well to handle them specially in XEclipse. The rest, are just XWiki objects.
Thanks, Eduard
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