18 Jun
2012
18 Jun
'12
9:27 a.m.
On Sat, Jun 16, 2012 at 7:01 PM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
Hi,
I checked the source code.(still it would be helpful if u cn explain)
I have a little issue.
Say with the current model
Blog.BlogPostClass
properties|__DBTreeList category {has a list of attributes}
|__TextAreaClass content {has a list of attributes}
|__ MYType myComplexTypeProp {has a list of attributes which
are all simple properties such as StringProperty etc} [ for ex:TagClass
tagprop ]
|__ StringClass mystring {also have a
list of attributes.
The XML schema
<complexType name="Object">
<complexContent>
<extension base="{http://www.xwiki.org}ObjectSummary">
<sequence>
<element name="property"
type="{http://www.xwiki.org}Property" maxOccurs="unbounded"
minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="Property">
<complexContent>
<extension base="{http://www.xwiki.org}LinkCollection">
<sequence>
<element name="attribute"
type="{http://www.xwiki.org}Attribute" maxOccurs="unbounded"
minOccurs="0"/>
<element name="value"
type="{http://www.w3.org/2001/XMLSchema}string"/>
</sequence>
<attribute name="name" use="required"
type="{http://www.w3.org/2001/XMLSchema}string" />
<attribute name="type"
type="{http://www.w3.org/2001/XMLSchema}string" />
</extension>
</complexContent>
</complexType>
<complexType name="Attribute">
<complexContent>
<extension base="{http://www.xwiki.org}LinkCollection">
<attribute name="name" use="required"
type="{http://www.w3.org/2001/XMLSchema}string" />
<attribute name="value"
type="{http://www.w3.org/2001/XMLSchema}string" />
</extension>
</complexContent>
</complexType>
does not seem to be addressing such an occasion where multiple levels of
nesting is happening. (May be I'm horribly wrong here)
Am I correct to think that any type of Object like BlogPostClass obj
will only have properties of simple types such as StringClass,
TextAreaClass and etc. It will not have a complex type for example
XWiki.TagClass in it.(I know it never happens in BlogPostClass, but
don't know if someone needs to do a weird class). ?
Yes, right now the XWiki model does not allow to put an object in
another object.
My findings and comprehension on the model:
I guess StringClass, TextAreaClass etc, carry most of those many
attributes for rendering purpose. I saw StaticListClass has attribute
(separators) for defining the list value delimeters as well.
Can you please post me a diagram taking a single class like DateClass. How
the aggregations and inheritance is done.
Ill send my design. I intend to do all that with just single definition for
each XWiki data type classes.For ex: XString extends XObject.XObject
contains the collection of fields.These can be converted to <attribute>
elements. A Document Object will contain a BlogPost (represent
BlobPostClass) object which contains XObject s as properties. (ideally if
multiple levels of nesting is supported BlogPost should also be a XObject).
The Document Object is an entity.(refer
https://docs.google.com/drawings/d/1hwfQMVgCvYKS6iHU060drcET3Aq3Vles2DQlJOO…
)
When we persist a document object it should serialize the BLogPost class
into its xml representation and save it on the filesystem. SQLite DB will
have a row with the URI for that file. So I am not going to persist
rest-model objects ( neither annotate them for persistence). Storing such
bulk objects may degrade DB performance. In the android dev guides it is
said a curser to a table should not exceed 2 MB of data otherwise the
performance will be low due to paging.
This makes the persistence a little complex. I will manage it. PLS tell if
my approach is wrong.
By the way I will merge my work to the master branch next week. Is it ok to
duplicate your maven work to a mvn branch and undo the commit in master and
merge my work with a fast forward merge, so that it will show a linear
history.
It's all yours, you can manage the branches the way you want as long
as the master is as up to date as possible.
Thanks
Best Regards.
Sasinda Rukshan.
On Sat, Jun 16, 2012 at 11:21 AM, sasinda rukshan
<sasindarukshan(a)gmail.com>wrote;wrote:
--
Thomas Mortagne
Thanks very much for the help on maven build.
*About making a object from Blog.BlogPostClass and toXML()*
A blog object is having properties of type other xobject classes. So to
make the things general can we do a stripped down replication or make
something similer to the java classes in com.xpn.xwiki.objects and its 2
sub packages .classes, .meta .
We can make a document object representing a page and put a
Blog.BlogPostClass object to its list of objects.We can convert them to
simple xml model directly.If we want to post blog object we can post the
Blog object.If the page does not exist we can put the page by getting the
xml from the Document object.
Then the things will be general not only for blog client app. Also we can
have Type checking when we don't directly manipulate simplexml objects.
i.e. XStringClass will define the attributes for it and likewise.
I don't have a good idea on the above packages and classes. Specially why
there are three classes for each XType ex: StringProperty, StringClass,
StringMeta.
It will be helpful if you can give an explanation.
My draft solution is to do some simple thing as,
XObject
|____ XBoolean
XObject
|____XString
XString has methods,
toEmbedXML gives a <property><attribute/>...</property> string/
simpleXML
objects
toXML gives <object><id><ClassName>.......</object> for the same
thing.
Also
XObject
|_____ XBlogPost for(BlogPostClass and other 2 Meta,Property classes)
I don't yet have a clear idea on this. May be I am wrong on this.
Can you give me your idea here as well. How to approach the problem and
what should the design be like?
Thanks.
Best Regards
Sasinda.
On Thu, Jun 7, 2012 at 9:28 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs wrote:
As just did a commit with last version of android
plugin and some
cleanup. Seems to work well.
On Thu, Jun 7, 2012 at 12:19 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
BTW if you have quick questions it's probaly
better to use IRC (I'm
tmortgane on the channel and I'm on GMT+2 tome zone but you can ask
anyone when I'm not around). See
http://dev.xwiki.org/xwiki/bin/view/Community/IRC.
On Thu, Jun 7, 2012 at 12:17 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
> Not need to send this kind of mail privately to me.
>
> On Thu, Jun 7, 2012 at 5:33 AM, sasinda rukshan
> <sasindarukshan(a)gmail.com> wrote:
>> Thanks,
>> The project is building perfectly well in eclipse (and runs well too)
[I
>> configured the build paths for eclipse
opening each module as a
project and
>> giving project dependencies and etc.].
This is because android facet
and
>> maven-android plugin for eclipse
[m2e-android] (not the jayway
androi maven
>> plugin)does not work together well.
>> Maven build does not work with newer jayway android maven plugins
because
of
>> the simplexml library. I checked with
another helloworld app that
does not
>> have simplexml dependancy and have
simplexml dependancy. When we have
the
>> dependancy it does not work. Also when
packaged with the beta version
maven
>> plugin I get runtime error logs notifying
that the exact classes
informed
>> missed in the compile time for newer
maven plugin are missing. But
the app
>> is running ok.
>> I will try with it some more and if I can't can you help me with it a
>> little.
>
> Sure If it's just related to simplexml it's probably not much. I will
> try to take a look today. At worst the version we are using right now
> is working fine so you can continue with it anyway.
>
>>
>> I looked at the Enterprise platform apis just to make my apis similar
when
>> possible.Source code is not at all
relevant to me. But as you say It
will be
>> imperfect if I use its style heavily for
the mobile version as well.
>
> Yes there is several issues here:
> * most APIs in oldcore module are old and bad and we are trying to get
> rif of them so better not getting too much attached to it ;)
> * they are designed to run in an enironment with lots of resources and
> don't care as much as a mobile API should about memory, etc.
>
>>
>>
>> Thank you.
>> Best Regards.
>> Sasinda.
>>
>>
>> On Wed, Jun 6, 2012 at 1:03 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com>
>> wrote:
>>>
>>> On Tue, Jun 5, 2012 at 7:07 PM, sasinda rukshan
>>> <sasindarukshan(a)gmail.com> wrote:
>>> > Hi,
>>> > *1: User Config Saving*
>>> > *
>>> > *
>>> > Xwiki android can now save user login data.
>>> > I refered
>>> > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki.
>>> > Currently assuming the authority
>>> >
>>> > part(platform.xwiki.org<
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki>)
>>> > only
>>> > as a unique wiki identifier. But in the
org.xwiki.android.entity.User I
>>> > have the method
>>> > setXWikiRealm(String url);:
>>> > Here I have intended the meaning realm as the url root path for a
unique
>>> > wiki instance.
>>> > i.e. it should identify a wiki using path upto
>>> > http://host/xwiki/wiki/wikialias/
>>> > But that functionality is not implemented.I just mailed this
asking for
>>> > the
>>> > opinion wether the usage of word realm was right here.
>>> > Also do you have seperate users for wikis for path based wiki
access.Or
>>> > are they the same with the main
wiki *http://<host>/xwiki*.
>>>
>>> Both actually, you can have global users (which are the one on main
>>> wiki) and local users.
>>>
>>> > *2: Entity model*
>>> > *
>>> > *
>>> > About the convention for using C_ prefix for core entity tables. I
>>> > was referring to make the android versions of these entities
>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchemaand
>>> > start
>>> > there db prefixes with C_
>>> > This is because other apps may need to store some specific tables
needed
>>> > for them. Rather than having a
seperate DB schema for them we can
put
>>> > those
>>> > tables here as well prefixing them with <appname>_ .
>>> > I added more entities like User as well to the core entities(table
>>> > C_User).Also will implement a Log Entity(C_Log table) for logging
some
>>> > important application
activities(such as login attempts) But the
Log may
>>> > be
>>> > a little additional weight to the space and performance.I may
implement
>>> > a
>>> > generic DBCleaning service to clean the tables like Log, if I have
time.
>>> > (Perhaps this description will
resolve the confusion about the DB
>>> > conventions. Sorry I was not very clear in that earlier mail. ;-).)
>>> >
>>> > I am sorry to say I am somewhat confused with all those entities in
>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchema.
>>>
>>> The XWiki model is based on generic classes and objects wich is why
>>> you see lots of tables (class properties, object properties , etc.).
>>> There is no table for users for example, its an object of class
>>> XWiki.XWikiUsers.
>>>
>>> >
>>> > Any way to reduce my confusion
>>> > I refered
>>> > 1) XWiki Data
>>> >
Model<http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel>
>>> > :
>>> > can you give me a link to a documentation that explains the
workflow
>>> > of
>>> > how a normal request is converted in to the requested page by the
>>> > bin View action . So I can get a better understanding of how
classes ,
>>> > objects are used.
>>>
>>> Not sure there is one. but basically you get either:
>>> * document content executed
>>> * if a class sheet is defined for one of the document objects
classes,
>>> the class sheet is executed
>>> * if a document sheet is defined for the documment, the document
sheet
>>> is executed
>>>
>>> That's pretty much all, then is a matter of free script and wiki
>>> syntax to actually display the content.
>>>
>>> > 2) package com.xpn.xwiki.api: I don't need to consider this, do I?
>>>
>>> That's limited scripting API so you should not consider this.
>>>
>>> > 3)
>>> > Cache<
http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Module>
>>> > : Need not implement similar
component. Android OS does it nicely
for
>>> > the
>>> > REST responses
>>> > but still don't have a clear picture on this.
>>> > To save a blog doc
>>> > option 1)Seems like I have to convert a document entity to relevent
>>> > xwiki-model-simplexml entities and send to server.
>>> > option 2) We also can edit the relevent simplexml model object
fields
>>> > directly. (Looks a bad option to
me.It does not hide the
complexity of
>>> > lower levels for the client
layer.Anyway my work load is reduced
with
>>> > opt:2 ;-))
>>>
>>> IMO you should not even look at
>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Moduleand
>>> instead look at how caching is usually done in Android. The idea is
>>> not to port the xwiki-platform to Android IMO but to follow Android
>>> standards to provide a library to manipulate XWiki model.
>>>
>>> You can set the annotation you want to the simplexml model but the
>>> classes/methods should remain an exact copy of what's on
>>> xwiki-platform-rest-model. The idea being that we could decide to
>>> change the implementation from simplexml to anything (JAXB, gson,
>>> etc.) without breaking anything.
>>>
>>> >
>>> >
>>> > *3: Development/architectural approach Change*
>>> > *
>>> > *
>>> > I was first thinking for a addon like architecture for the XWiki
android
>>> > app. We have the client.Main app
(with all platfrom libs included)
and
>>> > Blog
>>> > app as a seperate apk.
>>> > But here Blog app will need to have the platform lib also. That
would be
>>> > a
>>> > complete waste of space. But dynamically extending the app is lot
>>> > easier.
>>> > The client.Main app can add the activities defined in other apks
in to
>>> > its
>>> > launcher interface using android PackageManager class.
>>> >
>>> >
http://stackoverflow.com/questions/9236803/android-build-an-application-tha…
>>> > But with this approach rises
additional complexities. For example
naming
>>> > conflicts in the Components
library module when two apps have the
same
>>> > library with same activities
defined. Sync issues etc etc....
>>> > So we will go with single .apk approach.
>>> > When going with single .apk we dont need a content provider to
share
>>> > config/ preferences data. So
sharing module is now not needed. The
>>> > client
>>> > applications now can directly access the Configuration.java class
to
>>> > get/put configuration entries.
>>> > Also since I am having a User entity a configuration like
>>> > defaultUser(currently the admin user , hard coded in login.xml
layout
>>> > file)
>>> > will only be needed for the first use of the app. Otherwise users
need
>>> > not
>>> > configure a default user as the application now suggests the user
names
>>> > and
>>> > automatically fill the rest.
>>>
>>> Keep in mind that the main goal of this project is to provide tools
>>> for any application to access an XWiki instance and manipulate its
>>> datas easily an improving those libraries should always be the first
>>> goal. Your blog application is here as a good demo and because it's
>>> hard to design a library without using it.
>>>
>>> I really don't understand why you talk about naming conflict. Of
>>> course a library should never provide a complete final activity but
>>> only interface components (View), fragments or base activities to
>>> extend. Putting those elements in an activity is each application
job.
>>> An activity is by definition unique
so it has nothing to do in a
>>> library. The complete activities in
>>>
>>>
https://github.com/xwiki-contrib/android-client/tree/master/xwiki-android-c…
>>> should have never been there,
it's actually a mistake.
>>>
>>> >
>>> > *4: Plan for this week*
>>>
>>> As a priority you should really merge your branch as soon as you have
>>> something building fine. So that it goes through Jenkins and deploy
>>> snapshot build of what you do. Jenkins will tells you in live when
>>> your project does not build anymore or if there is any test failing
>>> and it allows anyone to very easily test the current test of the
>>> client just by installing the apks on
>>> http://maven.xwiki.org/snapshots/org/xwiki/android/. You need to
have
>>> something working and in good shape
to succeed the GSOC so fixing
when
>>> you break something in your build
should be your priority over adding
>>> more features.
>>>
>>> Also as I commented in your commit you should be more careful on what
>>> you commit. There is many binaries and Eclipse stuff in your branch.
>>>
>>> > *
>>> > *
>>> > Make a launch pad .We can launch XWiki Navigator, blog etc from
this.
>>> > The
>>> > launch pad is shown when we launch XWiki main client.
>>> > Consider adding the WYSIWYG to my blog. It will be useless without
the
>>> > ability to convert text
formatting to xwiki syntax.So I may just
>>> > integrate
>>> > it and ignore the uselessness for now.
>>>
>>> Not exactly, you could actually reuse WYSIWYG service to send html
and
>>> let it convert it to wiki syntax.
Note that you are not limited to
>>> what you can find in the current Android library. This is just what
>>> Chamika had the time to do. There is others REST (or not REST) server
>>> interfaces you can use in your client or even add more if its generic
>>> enough and make sense for something else than just Android client.
>>>
>>> > We currently don't have any config to save( Other than default
user)
>>> > config. I will add some demo
config data and have a developer
tools app
>>> > added to the above mentioned
XWiki launch pad that can view/edit
the
>>> > config
>>> > file.
>>> >
>>> > That will complete milestone 1. But it is not the Sharing
>>> > module(intended
>>> > to share data with other .apks).That is the configuration
component does
>>> > not have a ContentProvider to
share config data with other apks.
Also I
>>> > will define a seperate class to
have preferences which will be
edited by
>>> > users. Config files are for
configuration stuff and will be edited
by
>>> > developers. Users have
preferences files(natively supported by
android)
>>> > to
>>> > change app preferences. For example users will add the default
login
>>> > username as a preference.(This
will invalidate the use of default
User
>>> > entry in the config file which
is used until the user edits his
>>> > preferences)
>>>
>>> I'm fine with not sharing datas between applications but it does not
>>> prevent the libraries to provide tools to manage those datas in a
per
>>> application basis.
>>>
>>> >
>>> > Beg your pardon if the mail is too lengthy.;-)
>>>
>>> No problem, never too much information for this ;)
>>>
>>> > Thank you.
>>> > Best Regards.
>>> >
>>> > Sasinda Rukshan.
>>> >
>>> >
>>> > Best Regards.
>>> >
>>> >
>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne
>>> > <thomas.mortagne(a)xwiki.com>wrote;wrote:
>>> >
>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan
>>> >> <sasindarukshan(a)gmail.com> wrote:
>>> >> > Hi,
>>> >> > I am studying ORM Lite these days.
>>> >> > Please It would be comforting if you can confirm whether it is
worth
>>> >> > the
>>> >> > overhead to use ORM Lite.
>>> >> >
>>> >>
>>> >>
http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projec…
>>> >> > http://ormlite.com/
>>> >> > ORM Lite features:
>>> >> > Automatically Creates standard DAOs for an annotated entity.
>>> >> > Coding will be lot easier.
>>> >>
>>> >> Remember it's a framework for a mobile platform so it has to
remain
>>> >> light and have good
performances. I can see that Android version
of
>>> >> ormlite is very small but I
never used it so I don't know if it's
good
>>> >> or not. At least it seems
petty active which is a good point so I
>>> >> don't have anything against it.
>>> >>
>>> >> >
>>> >> > Can you suggest how to name the entities.
>>> >> > I am going to go with,
>>> >> > <entity> org.xwiki.xdroid.data.User -->
<table> C_USER
>>> >>
>>> >> Note that there is already a package name prefix and group id
defined
>>> >> for the framework and
it's org.xwiki.android as you can see on
>>> >> https://github.com/xwiki-contrib/android-client. Why do you want
to
>>> >> change it ? It's more
consistent with
>>> >> org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I
would
>>> >> prefer to keep it that way
unless you can give arguments. The
goal is
>>> >> not to redo something
completely but complete and improve the
existing
>>> >> framework.
>>> >>
>>> >> Also as far as I can see there is already several things called
>>> >> "xdroid" on Google play among which an application
developer
>>> >> (https://play.google.com/store/apps/developer?id=x-droid) and an
>>> >> application (
>>> >>
>>> >>
https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdro…
>>> >> ).
>>> >>
>>> >> >
>>> >> > Thanks,
>>> >> > Best Regards
>>> >> >
>>> >> > Sasinda.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan
>>> >> > <sasindarukshan(a)gmail.com>wrote;wrote:
>>> >> >
>>> >> >> Hi,
>>> >> >>
>>> >> >> I am commiting my work to my fork
>>> >> >> https://github.com/sasinda/android-client.
>>> >> >> I ll request to pull it to xwiki-contrib later.
>>> >> >>
>>> >> >> I was running in a wrong path these days. Wanted to save
login
>>> >> >> history
>>> >> and
>>> >> >> suggest login. I was going to do it using an xml file
(login
>>> >> attempts.xml).
>>> >> >> Now it seems database is better.
>>> >> >> Any way before I go wrong again I will say what I am going
to
do.
>>> >> >> I am going to
enforce following conventions.These are not yet
>>> >> >> needed,
>>> >> >> considered the small scale.But when the system grows it
would
be
>>> >> >> nice to
>>> >> >> have them to avoid confusions.
>>> >> >> *Database prefixes for:*
>>> >> >> *Platform tables (can begin with appropriate prefix)*
>>> >> >> AD_ //application dictionary : don't know when it will
be
needed ;-)
>>> >> >> C_ //core
functionality
>>> >> >> *Client Applications.*
>>> >> >> X<App name prefix> ex: XBLOG_ for Blog app// All
client add
in
>>> >> modules
>>> >> >> must begin with table prefix X(for xwiki and ordering) +
App
name.
>>> >> This is
>>> >> >> for my blog.
>>> >> >>
>>> >> >> I will create
>>> >> >> C_User for user data.
>>> >> >> C_LoginAttempt for saving login attempts.
>>> >> >>
>>> >> >> From C_LoginAttempt I can filter uniqe login combinations
and
give
>>> >> >> suggestions in the
login UI component. Also save the history.
>>> >> >>
>>> >> >> All saved data for blog app will be linked to a perticular
login :
>>> >> >> User,
>>> >> >> XWiki server.
>>> >> >> But only a single user will be most probably using his
personal
>>> >> >> device.
>>> >> So
>>> >> >> above will be relevant only when he has multiple wikis.
>>> >> >>
>>> >> >> Best Regards,
>>> >> >> Sasinda Rukshan.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe <
>>> >> chamikaw(a)gmail.com>wroteote:
>>> >> >>
>>> >> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <
>>> >> jerome(a)winesquare.net
>>> >> >>> >wrote:
>>> >> >>>
>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
>>> >> >>> > <thomas.mortagne(a)xwiki.com> wrote:
>>> >> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda
rukshan
>>> >> >>> > > <sasindarukshan(a)gmail.com> wrote:
>>> >> >>> > >> Hi all,
>>> >> >>> > >> I am starting this thread for my XWiki
Android Platform
>>> >> >>> > >> Project.
>>> >> >>> > >>
>>> >> >>> > >> Please check whether following are OK.
>>> >> >>> > >> [1] INFO
>>> >> >>> > >> I tried to start my new modules with the
>>> >> >>> de.akquinet.android.archetypes:
>>> >> >>> > >> android-quickstart:1.0.8. (added eclipse
plugins m2e,
>>> >> >>> > >> m2e-android[a.k.a *Android
>>> >> >>> > >> Configurator* ]). But this seems buggy in
eclipse.
>>> >> >>> > >> Any way the earlier project has not
followed the above
>>> >> >>> > >> archtype
>>> >> >>> either.
>>> >> >>> > So
>>> >> >>> > >> I am going to write pom.xml manually for
my each module.
>>> >> >>> > >>
>>> >> >>> > >> [2] ADVICE NEEDED
>>> >> >>> > >> xwiki-rest-model module contains 2
submodules
>>> >> >>> > >> |-- xwiki-rest-model-gson ( gson should
be corrected to
>>> >> >>> > >> json)
>>> >> >>> > >
>>> >> >>> > > No the g is not a mistake, it's a model
to be used with
the
>>> >> >>> > > gson
>>> >> >>> > > library
(http://code.google.com/p/google-gson/). See
>>> >> >>> > >
>>> >> >>> >
>>> >> >>>
>>> >>
>>> >>
http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#…
>>> >> >>> > .
>>> >> >>> > >
>>> >> >>> > >> |-- xwiki-rest-model-simplexml
>>> >> >>> > >> I think the xwiki-rest-model-gson is
redundant. The
classes
>>> >> >>> > >>
in xwiki-rest-model-simplexml is added with simple xml
>>> >> annotations,
>>> >> >>> > >> otherwise both modules have same classes.
There is no
problem
>>> >> >>> > >>
with
>>> >> >>> the
>>> >> >>> > >> added annotations for using the same
model objects for
Json
>>> >> >>> > >>
REST
>>> >> web
>>> >> >>> > >> services. And I intend to add my JPA
(ORMLite library for
>>> >> >>> persistence)
>>> >> >>> > >> annotations on top of it.
>>> >> >>> > >> Shall I re-factor them to a single module
xwiki-rest-model.
>>> >> >>> > >
>>> >> >>> > > No keep them separated, the idea is that both
are useful
tool
>>> >> >>> > > to
be
>>> >> >>> > > used by someone else that might be moved to
xwiki-platform at
>>> >> >>> > > some
>>> >> >>> > > point along with the current xwiki-rest-model
(to be
renamed to
>>> >> >>> > >
xwiki-rest-model-jaxb).
>>> >> >>> > >
>>> >> >>> > > Chamika initially started with gson and since
XWiki REST
JSON
>>> >> >>> > >
representation had some limitation he moved to XML
>>> >> >>> > > representation.
>>> >> >>> > > Maybe at some point Android will have native
support for
jaxb
>>> >> >>> > >
which
>>> >> >>> > > would obviously be the easier for us
(embedding jaxb is
not an
>>> >> option
>>> >> >>> > > in mobile world where size it still pretty
important
especially
>>> >> >>> > > on
>>> >> >>> > > phones). Maybe it's already the case on
most recent
versions
>>> >> >>> > > like
>>> >> 4.0
>>> >> >>> > > I don't know.
>>> >> >>> >
>>> >> >>> > There's also Jackson that could be tried for
JSON
>>> >> >>> > deserialization, if
>>> >> >>> > said limitations are actually GSON limitations.
>>> >> >>> >
>>> >> >>> GSON wasn't the limitation.
>>> >> >>> It was XWiki RESTful API which doesn't support JSON
in some
cases.
>>> >> >>> So
>>> >> it's
>>> >> >>> safe to go with xml.
>>> >> >>>
>>> >> >>> >
>>> >> >>> > Having full JAXB support sound a bit overweight
for such an
>>> >> >>> > "embedded
>>> >> >>> > API", even if one day it is natively
supported by Android.
What's
>>> >> >>> > important
is to have an easy and fast deserialization, IMO.
>>> >> >>> > The only advantage I can see of going JAXB would
be in
re-using
>>> >> >>> > the
>>> >> >>> > exact representations and body readers/writers
from XWiki
core.
>>> >> >>> > But
>>> >> >>> > you probably don't even want to do that since
it would mean
>>> >> >>> > dragging
>>> >> >>> > XWiki core with you :)
>>> >> >>> >
>>> >> >>> > Jerome
>>> >> >>> >
>>> >> >>> > >
>>> >> >>> > >>
>>> >> >>> > >> [3] INFO
>>> >> >>> > >> I had to change some pom.xml s. As the
current project
at:
>>> >> >>> > >>
https://github.com/xwiki-contrib/android-client.gitdoes not
>>> >> build.
>>> >> >>> > Error
>>> >> >>> > >> with parent pom.xml coordinates.
>>> >> >>> > >
>>> >> >>> > > You probably did not setup you maven install
properly
since
>>> >> >>> > >
what's
>>> >> on
>>> >> >>> > >
https://github.com/xwiki-contrib/android-client.git build
>>> >> perfectly
>>> >> >>> as
>>> >> >>> > > you can see on
>>> >> http://ci.xwiki.org/view/All/job/xwiki-android-client/
>>> >> >>> > > which run a build every time something
changes on the git
>>> >> repository..
>>> >> >>> > > You should look at
>>> >> >>> > >
http://dev.xwiki.org/xwiki/bin/view/Community/Building.
>>> >> >>> > >
>>> >> >>> > >>
>>> >> >>> > >>
>>> >> >>> > >> Thank you
>>> >> >>> > >> Best Regards.
>>> >> >>> > >> Sasinda Rukshan
>>> >> >>> > >>
_______________________________________________
>>> >> >>> > >> devs mailing list
>>> >> >>> > >> devs(a)xwiki.org
>>> >> >>> > >>
http://lists.xwiki.org/mailman/listinfo/devs
>>> >> >>> > >
>>> >> >>> > >
>>> >> >>> > >
>>> >> >>> > > --
>>> >> >>> > > Thomas Mortagne
>>> >> >>> > >
_______________________________________________
>>> >> >>> > > devs mailing list
>>> >> >>> > > devs(a)xwiki.org
>>> >> >>> > > http://lists.xwiki.org/mailman/listinfo/devs
>>> >> >>> >
>>> >> >>> >
>>> >> >>> >
>>> >> >>> > --
>>> >> >>> > Jérôme Velociter
>>> >> >>> > Winesquare
>>> >> >>> > http://www.winesquare.net/
>>> >> >>> > _______________________________________________
>>> >> >>> > 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
>>> >> >>>
>>> >> >>
>>> >> >>
>>> >> > _______________________________________________
>>> >> > devs mailing list
>>> >> > devs(a)xwiki.org
>>> >> > http://lists.xwiki.org/mailman/listinfo/devs
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Thomas Mortagne
>>> >> _______________________________________________
>>> >> 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
>>>
>>>
>>>
>>> --
>>> Thomas Mortagne
>>
>>
>
>
>
> --
> Thomas Mortagne
--
Thomas Mortagne
--
Thomas Mortagne