On Sun, Jun 17, 2012 at 2:16 PM, sasinda rukshan <[email protected]> wrote: > Hi, > > Status Rept: > I reverse engineered the com.xpn.objects /.object.classes / .object.meta > packages. I think I understand it somewhat now. > I am making up my own simple design for the model classes. > I will soon post UML diagram with my design. Since XWiki ReST interfaces > are so robust I don't have to fill many of the attribute fields and > propertiest to post a blog post. > I will further experiment (Using Postman chrome plugin for ReST testing, > it's nice) before coming up with the class diagram. > > Questions: > 1) A page has its own class. When we make a new page a custom class gets > created. I checked the xml file for Blog.BlogIntroduction. It looked more > of a representation of a document object. Not a class definition. (It had > values defined. So can it be considered as a class def) ?
Well a better way to see it is that a document contains zero or one class and zero or several objects. Not every document really have a class. You always get an empty class when you ask for the class of a document for the same reason that you get an empty document when your as for a document that does not exists. > > 2) Is this idea correct? > I make a new page named NEWPAGE1 in Blog space. > page :is of class type Blog.NEWPAGE1. > can have objects of any type. > I posted a BlogPostClass object. But there are no restrictions to post > another BlogPostClass object. But only the first BlogPostClass object is > rendered when viewing the page. > > Shouldn't the page be of type BlogClass (extends BlogCode).? > So, > Shall I give a type for a document object. Something like > doc.setType(BlocClass.class); When this happens the document object > enforces type restrictions. Like only BlogPostClass objects should be in > the page and etc. > > I'll be happy to provide with clarifications If I said things very briefly. > I will design a uml class diag for this part and send before implementation > starts. > > > Thanks > Best Regards > Sasinda. > > > > > > > > Thank You > > > On Sat, Jun 16, 2012 at 10:31 PM, sasinda rukshan > <[email protected]>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). ? >> >> 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. There is no such thing as inheritance with XWiki classes (yet). >> 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.gitbuild >>>> >>>> >> 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 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
