On Sat, Jun 16, 2012 at 7:01 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). ?
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/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. 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 > <[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 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
