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). ?
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/1hwfQMVgCvYKS6iHU060drcET3Aq3Vles2DQlJOOt3n8/edit<https://docs.google.com/drawings/d/1hwfQMVgCvYKS6iHU060drcET3Aq3Vles2DQlJOOt3n8/edit?pli=1>
)
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.
Thanks
Best Regards.
Sasinda Rukshan.
On Sat, Jun 16, 2012 at 11:21 AM, sasinda rukshan
<[email protected]>wrote:
> 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 <[email protected]
> > 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
>> <[email protected]> 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
>> > <[email protected]> wrote:
>> >> Not need to send this kind of mail privately to me.
>> >>
>> >> On Thu, Jun 7, 2012 at 5:33 AM, sasinda rukshan
>> >> <[email protected]> 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 <
>> [email protected]>
>> >>> wrote:
>> >>>>
>> >>>> On Tue, Jun 5, 2012 at 7:07 PM, sasinda rukshan
>> >>>> <[email protected]> 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-that-supports-add-ons
>> >>>> > 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-components/
>> >>>> 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
>> >>>> > <[email protected]>wrote:
>> >>>> >
>> >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan
>> >>>> >> <[email protected]> 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-projects.html
>> >>>> >> > 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.xdroid
>> >>>> >> ).
>> >>>> >>
>> >>>> >> >
>> >>>> >> > Thanks,
>> >>>> >> > Best Regards
>> >>>> >> >
>> >>>> >> > Sasinda.
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan
>> >>>> >> > <[email protected]>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 <
>> >>>> >> [email protected]>wrote:
>> >>>> >> >>
>> >>>> >> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter <
>> >>>> >> [email protected]
>> >>>> >> >>> >wrote:
>> >>>> >> >>>
>> >>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne
>> >>>> >> >>> > <[email protected]> wrote:
>> >>>> >> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan
>> >>>> >> >>> > > <[email protected]> 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#HXWikiAndroidDevelopmentAPIsandResources
>> >>>> >> >>> > .
>> >>>> >> >>> > >
>> >>>> >> >>> > >> |-- 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
>> >>>> >> >>> > >> [email protected]
>> >>>> >> >>> > >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>> > >
>> >>>> >> >>> > >
>> >>>> >> >>> > >
>> >>>> >> >>> > > --
>> >>>> >> >>> > > Thomas Mortagne
>> >>>> >> >>> > > _______________________________________________
>> >>>> >> >>> > > devs mailing list
>> >>>> >> >>> > > [email protected]
>> >>>> >> >>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>> >
>> >>>> >> >>> >
>> >>>> >> >>> >
>> >>>> >> >>> > --
>> >>>> >> >>> > Jérôme Velociter
>> >>>> >> >>> > Winesquare
>> >>>> >> >>> > http://www.winesquare.net/
>> >>>> >> >>> > _______________________________________________
>> >>>> >> >>> > 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
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> --
>> >>>> >> Thomas Mortagne
>> >>>> >> _______________________________________________
>> >>>> >> devs mailing list
>> >>>> >> [email protected]
>> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>
>> >>>> > _______________________________________________
>> >>>> > devs mailing list
>> >>>> > [email protected]
>> >>>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Thomas Mortagne
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Thomas Mortagne
>> >
>> >
>> >
>> > --
>> > Thomas Mortagne
>>
>>
>>
>> --
>> Thomas Mortagne
>>
>
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
