Hi, Pushed some initial scaffolding's of XWiki model to android, in to https://github.com/xwiki-contrib/android-client This is the basic idea. The client app developers will be only exposed to a service layer. All packages suffixed with "Svc" have these. package: cmnSvc >> has the LoginFacade. called to log in to server and system.(also update state of XWikiContext in the android and etc) package blogSvc >> will have BlogDocument, CategoryDocument and etc which can be used to create posts and update server. The base class Document will handle all server updations(through a ReSTfulAdapter, to decouple Document and underlying rest model: simple XML/Gson) and etc. Please check whether approach to redesigning com.xpn....objects into org.xwiki.android.xmodel.xobjects is correct. Thanks. Best Regards. Sasinda. On Mon, Jun 18, 2012 at 3:20 PM, sasinda rukshan <[email protected]>wrote:
Hi Thomas,
---------- Forwarded message ---------- From: Thomas Mortagne <[email protected]> Date: Mon, Jun 18, 2012 at 3:08 PM Subject: Re: [xwiki-devs] Fwd: [GSoc] XDroid Platform To: [email protected], XWiki Developers <[email protected]>
On Mon, Jun 18, 2012 at 11:30 AM, sasinda rukshan <[email protected]> wrote:
---------- Forwarded message ---------- From: sasinda rukshan <[email protected]> Date: Mon, Jun 18, 2012 at 2:56 PM Subject: Re: [xwiki-devs] [GSoc] XDroid Platform To: XWiki Developers <[email protected]>
Hi Thomas,
Thanks for the explanations. The methods toXML , toEmbedXML are wrong.It was just an idea that came up without much thinking. I will use a separate model converter.(xwikitTosimpleModelConverter implements ModelConverter like thing). So the model objects don't know about it at all. By what you ment by "user" I think it is the client app developer is it?
Yes I mean the user of the API.
you did not mean end user. I never reveal the xml representations to end users.
I came up with a simpler design. I will post diagram later tomorrow.
Ok, this ASCII art here is not very easy to read ;)
To give a brief on it, XObject : has protected property List<XProperty>
A Map<XProperty> would probably make more sense here since each property as a unique name in an object and you will need to set some specific property very often.
|__XPoperty :<< all objects that can be added as a property of an objects should extend this. Has an attribute list. cancels the | property list of XObject | |_____XString : |__Abstract XDocObject :<< all documents should have an object of this. This is the pages class. Has a object List<XObject> | |____XBlog :<< all documents which are blogs should have a object of this. This determines the class of the object. | but this data is not posted anywhere in <link rel="...../class"> . It is just kept for type checks. That is like | this page should include XBlogPost objects. |__XBlogPost : <<the BlogPostClass object.
In my view I assume every page has an object of some class. And this object holds the objects which you can get under .../pages/BlogPg1/objects/
Well not exactly, you don't always have an object. A document can be just about content. Just a wiki page if you prefer.
[ an added advantage: I think we can make a ViewEngine to generate android View components from the above model. Since the objects in the page carry rendering descriptions.We can make a general model like a browser to brows xwiki using generated the views. But the problem is some features
in
specific spaces like blog do not seem to be totally defined by the XWiki Object model behind them. Also this is just an idea (not suggesting I do for the GSoc).Making it a usable reality is a little challenge. ]
So as you said if a document (I think it equivalent to a page) can have many class types my assumption fails. Why should a document be of multiple classes. I was thinking a page belongs to a class. And the page is an instance of that class. If page can have multiple classes my understanding should be wrong. Isn't it?
I don't understand, what I said is that you can only have one class in a document but you can have several objects.
Thanks Best Regards Sasinda.