28 Jul
2011
28 Jul
'11
6:07 a.m.
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<jun.han37(a)gmail.com> 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.eclips…
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs