Hi Jun, On Tue, Jun 28, 2011 at 7:15 PM, Jun Han <[email protected]> wrote:
> Hi, Eduard and Fabio, > > I looked into the page related to data model > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel > > As one single page may have children pages and parent page, do we need > to support the page hierarchy or just use one flat layer to display all > the pages? > No, parent-child relationship is currently used XWIki only for the breadcrums view and maybe a logical grouping on top of the space-page relation. For XEclipse, space-page is the main focus. Parent-child would be nice, but I don`t see it as a priority. > Another question is about how to add customized class, e.g., MyClass to > a page. > I created a customized class, called MyClass1 as a numerical type. > I tried to add a customized object for it, but it will not show up in > the class list. > Therefore, I do not know how to test the fetch function of customized > classes. > To create a class in XWiki, you go to (or create) an XWiki page and use Edit>Class. You add some fields of basic types (String, Boolean, etc...) and then save the page. Now the page you just edited has become a class. It is still a page, but it can be used to define the structure for new objects. It will show up in the class list when you want to create a new object in a page. Now, back to REST, http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI#HClassresourcessays that you can query classes and their instances on each wiki. The only problem I see here, is that you can't (or at least I don`t see the API, Fabio should confirm) create new classes using REST. If this is true, then you`ve just stumbled upon a first limitation of the REST API that needs fixing. Normally, an XWiki page, in it's internal XML representation, contains a <class> tag that defines the class it represents. Have a look with http://localhost:8080/xwiki/bin/view/Main/TestClass?viewer=xml (use view source on the page since it does not show up nicely in the browser). The REST API separated this information (see classes resource) and only provides GET methods implementation. PUT methods need to be implemented as well. It should not be that hard. For now, you should focus only on retrieving and later you can come back to creating. Hope this answers your questions. -Eduard > > 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.core/src/main/java/org/xwiki/eclipse/core/DataManager.java > > > > 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 > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
