18 Jun
2012
18 Jun
'12
11:30 a.m.
---------- Forwarded message ----------
From: sasinda rukshan <sasindarukshan(a)gmail.com>
Date: Mon, Jun 18, 2012 at 2:56 PM
Subject: Re: [xwiki-devs] [GSoc] XDroid Platform
To: XWiki Developers <devs(a)xwiki.org>
Hi Thomas,
Thanks for the explanations.
The methods toXML , toEmbedXML are wrong.It was just an idea that came up
without much thinking. I will use a separate model
converter.(xwikitTosimpleModelConverter implements ModelConverter like
thing). So the model objects don't know about it at all.
By what you ment by "user" I think it is the client app developer is it?
you did not mean end user. I never reveal the xml representations to end
users.
I came up with a simpler design. I will post diagram later tomorrow.
To give a brief on it,
XObject : has protected property List<XProperty>
|__XPoperty :<< all objects that can be added as a property of an objects
should extend this. Has an attribute list. cancels the
| property list of XObject
| |_____XString :
|__Abstract XDocObject :<< all documents should have an object of this.
This is the pages class. Has a object List<XObject>
| |____XBlog :<< all documents which are blogs should
have a object of this. This determines the class of the object.
| but this data is not posted
anywhere in <link rel="...../class"> . It is just kept for type checks.
That is like
| this page should include
XBlogPost objects.
|__XBlogPost : <<the BlogPostClass object.
In my view I assume every page has an object of some class. And this object
holds the objects which you can get under .../pages/BlogPg1/objects/
[
an added advantage:
I think we can make a ViewEngine to generate android View components from
the above model. Since the objects in the page carry rendering
descriptions.We can make a general model like a browser to
brows xwiki using generated the views. But the problem is some features in
specific spaces like blog do not seem to be totally defined by the XWiki
Object model behind them. Also this is just an idea (not suggesting I do
for the GSoc).Making it a usable reality is a little challenge.
]
So as you said if a document (I think it equivalent to a page) can have
many class types my assumption fails.
Why should a document be of multiple classes. I was thinking a page belongs
to a class. And the page is an instance of that class. If page can have
multiple classes my understanding should be wrong. Isn't it?
Thanks
Best Regards
Sasinda.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
>>>
>>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne
>>> >>>> > <thomas.mortagne(a)xwiki.com>wrote;wrote:
>>> >>>> >
>>> >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan
>>> >>>> >> <sasindarukshan(a)gmail.com> wrote:
>>> >>>> >> > Hi,
>>> >>>> >> > I am studying ORM Lite these days.
>>> >>>> >> > Please It would be comforting if you can
confirm whether it
is
>>> worth
>>> >>>> >> > the
>>> >>>> >> > overhead to use ORM Lite.
>>> >>>> >> >
>>> >>>> >>
>>> >>>> >>
>>>
http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projec…
>>> >>>> >> >
http://ormlite.com/
>>> >>>> >> > ORM Lite features:
>>> >>>> >> > Automatically Creates standard DAOs for an
annotated entity.
>>> >>>> >> > Coding will be lot easier.
>>> >>>> >>
>>> >>>> >> Remember it's a framework for a mobile platform
so it has to
>>> remain
>>> >>>> >> light and have good performances. I can see that
Android
version
>>> of
>>> >>>> >> ormlite is very small but I never used it so I
don't know if
>>> it's good
>>> >>>> >> or not. At least it seems petty active which is a
good point
so I
>>> >>>> >> don't
have anything against it.
>>> >>>> >>
>>> >>>> >> >
>>> >>>> >> > Can you suggest how to name the entities.
>>> >>>> >> > I am going to go with,
>>> >>>> >> > <entity> org.xwiki.xdroid.data.User
--> <table> C_USER
>>> >>>> >>
>>> >>>> >> Note that there is already a package name prefix
and group id
>>> defined
>>> >>>> >> for the framework and it's org.xwiki.android as
you can see on
>>> >>>> >> https://github.com/xwiki-contrib/android-client.
Why do you
>>> want to
>>> >>>> >> change it ? It's more consistent with
>>> >>>> >>
org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I
>>> would
>>> >>>> >> prefer to keep it that way unless you can give
arguments. The
>>> goal is
>>> >>>> >> not to redo something completely but complete and
improve the
>>> existing
>>> >>>> >> framework.
>>> >>>> >>
>>> >>>> >> Also as far as I can see there is already several
things
called
>>> >>>> >>
"xdroid" on Google play among which an application developer
>>> >>>> >>
(https://play.google.com/store/apps/developer?id=x-droid)
and an
>>> >>>> >> application
(
>>> >>>> >>
>>> >>>> >>
>>>
https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdro…
>>> >>>> >> ).
>>> >>>> >>
>>> >>>> >> >
>>> >>>> >> > Thanks,
>>> >>>> >> > Best Regards
>>> >>>> >> >
>>> >>>> >> > Sasinda.
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda
rukshan
>>> >>>> >> > <sasindarukshan(a)gmail.com>wrote;wrote:
>>> >>>> >> >
>>> >>>> >> >> Hi,
>>> >>>> >> >>
>>> >>>> >> >> I am commiting my work to my fork
>>> >>>> >> >>
https://github.com/sasinda/android-client.
>>> >>>> >> >> I ll request to pull it to xwiki-contrib
later.
>>> >>>> >> >>
>>> >>>> >> >> I was running in a wrong path these days.
Wanted to save
login
>>> >>>> >> >>
history
>>> >>>> >> and
>>> >>>> >> >> suggest login. I was going to do it using
an xml file
(login
>>> >>>> >>
attempts.xml).
>>> >>>> >> >> Now it seems database is better.
>>> >>>> >> >> Any way before I go wrong again I will say
what I am going
to
>>> do.
>>> >>>> >> >> I am going to enforce following
conventions.These are not
yet
>>> >>>> >> >>
needed,
>>> >>>> >> >> considered the small scale.But when the
system grows it
would
>>> be
>>> >>>> >> >> nice to
>>> >>>> >> >> have them to avoid confusions.
>>> >>>> >> >> *Database prefixes for:*
>>> >>>> >> >> *Platform tables (can begin with
appropriate prefix)*
>>> >>>> >> >> AD_ //application dictionary : don't
know when it will be
>>> needed ;-)
>>> >>>> >> >> C_ //core functionality
>>> >>>> >> >> *Client Applications.*
>>> >>>> >> >> X<App name prefix> ex: XBLOG_ for
Blog app// All client
>>> add in
>>> >>>> >> modules
>>> >>>> >> >> must begin with table prefix X(for xwiki
and ordering) +
App
>>> name.
>>> >>>> >> This is
>>> >>>> >> >> for my blog.
>>> >>>> >> >>
>>> >>>> >> >> I will create
>>> >>>> >> >> C_User for user data.
>>> >>>> >> >> C_LoginAttempt for saving login
attempts.
>>> >>>> >> >>
>>> >>>> >> >> From C_LoginAttempt I can filter uniqe
login combinations
and
>>> give
>>> >>>> >> >> suggestions in the login UI component.
Also save the
history.
>>> >>>> >> >>
>>> >>>> >> >> All saved data for blog app will be linked
to a perticular
>>> login :
>>> >>>> >> >> User,
>>> >>>> >> >> XWiki server.
>>> >>>> >> >> But only a single user will be most
probably using his
>>> personal
>>> >>>> >> >> device.
>>> >>>> >> So
>>> >>>> >> >> above will be relevant only when he has
multiple wikis.
>>> >>>> >> >>
>>> >>>> >> >> Best Regards,
>>> >>>> >> >> Sasinda Rukshan.
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >> On Sun, May 27, 2012 at 5:43 PM, Chamika
Weerasinghe <
>>> >>>> >> chamikaw(a)gmail.com>wroteote:
>>> >>>> >> >>
>>> >>>> >> >>> On Fri, May 25, 2012 at 1:25 AM,
Jerome Velociter <
>>> >>>> >> jerome(a)winesquare.net
>>> >>>> >> >>> >wrote:
>>> >>>> >> >>>
>>> >>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM,
Thomas Mortagne
>>> >>>> >> >>> > <thomas.mortagne(a)xwiki.com>
wrote:
>>> >>>> >> >>> > > On Thu, May 24, 2012 at 5:52
PM, sasinda rukshan
>>> >>>> >> >>> > >
<sasindarukshan(a)gmail.com> wrote:
>>> >>>> >> >>> > >> Hi all,
>>> >>>> >> >>> > >> I am starting this
thread for my XWiki Android
Platform
>>> >>>> >>
>>> > >> Project.
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > >> Please check whether
following are OK.
>>> >>>> >> >>> > >> [1] INFO
>>> >>>> >> >>> > >> I tried to start my new
modules with the
>>> >>>> >> >>> de.akquinet.android.archetypes:
>>> >>>> >> >>> > >>
android-quickstart:1.0.8. (added eclipse plugins
m2e,
>>> >>>> >>
>>> > >> m2e-android[a.k.a *Android
>>> >>>> >> >>> > >> Configurator* ]). But
this seems buggy in eclipse.
>>> >>>> >> >>> > >> Any way the earlier
project has not followed the
above
>>> >>>> >>
>>> > >> archtype
>>> >>>> >> >>> either.
>>> >>>> >> >>> > So
>>> >>>> >> >>> > >> I am going to write
pom.xml manually for my each
module.
>>> >>>> >>
>>> > >>
>>> >>>> >> >>> > >> [2] ADVICE NEEDED
>>> >>>> >> >>> > >> xwiki-rest-model module
contains 2 submodules
>>> >>>> >> >>> > >> |--
xwiki-rest-model-gson ( gson should be
corrected
>>> to
>>> >>>> >> >>> > >> json)
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > No the g is not a mistake,
it's a model to be used
with
>>> the
>>> >>>> >> >>> > > gson
>>> >>>> >> >>> > > library
(http://code.google.com/p/google-gson/). See
>>> >>>> >> >>> > >
>>> >>>> >> >>> >
>>> >>>> >> >>>
>>> >>>> >>
>>> >>>> >>
>>>
http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#…
>>> >>>> >>
>>> > .
>>> >>>> >> >>> > >
>>> >>>> >> >>> > >> |--
xwiki-rest-model-simplexml
>>> >>>> >> >>> > >> I think the
xwiki-rest-model-gson is redundant. The
>>> classes
>>> >>>> >> >>> > >> in
xwiki-rest-model-simplexml is added with simple
xml
>>> >>>> >>
annotations,
>>> >>>> >> >>> > >> otherwise both modules
have same classes. There is no
>>> problem
>>> >>>> >> >>> > >> with
>>> >>>> >> >>> the
>>> >>>> >> >>> > >> added annotations for
using the same model objects
for
>>> Json
>>> >>>> >> >>> > >> REST
>>> >>>> >> web
>>> >>>> >> >>> > >> services. And I intend
to add my JPA (ORMLite library
>>> for
>>> >>>> >> >>> persistence)
>>> >>>> >> >>> > >> annotations on top of
it.
>>> >>>> >> >>> > >> Shall I re-factor them
to a single module
>>> xwiki-rest-model.
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > No keep them separated, the
idea is that both are
useful
>>> tool
>>> >>>> >> >>> > > to be
>>> >>>> >> >>> > > used by someone else that
might be moved to
>>> xwiki-platform at
>>> >>>> >> >>> > > some
>>> >>>> >> >>> > > point along with the current
xwiki-rest-model (to be
>>> renamed to
>>> >>>> >> >>> > > xwiki-rest-model-jaxb).
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > Chamika initially started
with gson and since XWiki
REST
>>> JSON
>>> >>>> >> >>> > > representation had some
limitation he moved to XML
>>> >>>> >> >>> > > representation.
>>> >>>> >> >>> > > Maybe at some point Android
will have native support
for
>>> jaxb
>>> >>>> >> >>> > > which
>>> >>>> >> >>> > > would obviously be the
easier for us (embedding jaxb
is
>>> not an
>>> >>>> >> option
>>> >>>> >> >>> > > in mobile world where size
it still pretty important
>>> especially
>>> >>>> >> >>> > > on
>>> >>>> >> >>> > > phones). Maybe it's
already the case on most recent
>>> versions
>>> >>>> >> >>> > > like
>>> >>>> >> 4.0
>>> >>>> >> >>> > > I don't know.
>>> >>>> >> >>> >
>>> >>>> >> >>> > There's also Jackson that
could be tried for JSON
>>> >>>> >> >>> > deserialization, if
>>> >>>> >> >>> > said limitations are actually
GSON limitations.
>>> >>>> >> >>> >
>>> >>>> >> >>> GSON wasn't the limitation.
>>> >>>> >> >>> It was XWiki RESTful API which
doesn't support JSON in
some
>>> cases.
>>> >>>> >> >>> So
>>> >>>> >> it's
>>> >>>> >> >>> safe to go with xml.
>>> >>>> >> >>>
>>> >>>> >> >>> >
>>> >>>> >> >>> > Having full JAXB support sound a
bit overweight for
such an
>>> >>>> >>
>>> > "embedded
>>> >>>> >> >>> > API", even if one day it is
natively supported by
Android.
>>> What's
>>> >>>> >> >>> > important is to have an easy and
fast deserialization,
IMO.
>>> >>>> >>
>>> > The only advantage I can see of going JAXB would be in
>>> re-using
>>> >>>> >> >>> > the
>>> >>>> >> >>> > exact representations and body
readers/writers from
XWiki
>>> core.
>>> >>>> >> >>> > But
>>> >>>> >> >>> > you probably don't even want
to do that since it would
mean
>>> >>>> >>
>>> > dragging
>>> >>>> >> >>> > XWiki core with you :)
>>> >>>> >> >>> >
>>> >>>> >> >>> > Jerome
>>> >>>> >> >>> >
>>> >>>> >> >>> > >
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > >> [3] INFO
>>> >>>> >> >>> > >> I had to change some
pom.xml s. As the current
project
>>> at:
>>> >>>> >> >>> > >>
https://github.com/xwiki-contrib/android-client.gitdoes not
>>> >>>> >> build.
>>> >>>> >> >>> > Error
>>> >>>> >> >>> > >> with parent pom.xml
coordinates.
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > You probably did not setup
you maven install properly
>>> since
>>> >>>> >> >>> > > what's
>>> >>>> >> on
>>> >>>> >> >>> > >
https://github.com/xwiki-contrib/android-client.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
> >>>> >> >>> > >> devs(a)xwiki.org
> >>>> >> >>> > >>
http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >> >>> > >
> >>>> >> >>> > >
> >>>> >> >>> > >
> >>>> >> >>> > > --
> >>>> >> >>> > > Thomas Mortagne
> >>>> >> >>> > >
_______________________________________________
> >>>> >> >>> > > devs mailing list
> >>>> >> >>> > > devs(a)xwiki.org
> >>>> >> >>> > >
http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >> >>> >
> >>>> >> >>> >
> >>>> >> >>> >
> >>>> >> >>> > --
> >>>> >> >>> > Jérôme Velociter
> >>>> >> >>> > Winesquare
> >>>> >> >>> > http://www.winesquare.net/
> >>>> >> >>> >
_______________________________________________
> >>>> >> >>> > devs mailing list
> >>>> >> >>> > devs(a)xwiki.org
> >>>> >> >>> >
http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >> >>> >
> >>>> >> >>>
_______________________________________________
> >>>> >> >>> devs mailing list
> >>>> >> >>> devs(a)xwiki.org
> >>>> >> >>> http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >> >>>
> >>>> >> >>
> >>>> >> >>
> >>>> >> > _______________________________________________
> >>>> >> > devs mailing list
> >>>> >> > devs(a)xwiki.org
> >>>> >> > http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> --
> >>>> >> Thomas Mortagne
> >>>> >> _______________________________________________
> >>>> >> devs mailing list
> >>>> >> devs(a)xwiki.org
> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>>> >>
> >>>> > _______________________________________________
> >>>> > devs mailing list
> >>>> > devs(a)xwiki.org
> >>>> > http://lists.xwiki.org/mailman/listinfo/devs
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Thomas Mortagne
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Thomas Mortagne
> >
> >
> >
> > --
> > Thomas Mortagne
>
>
>
> --
> Thomas Mortagne
>
18 Jun
18 Jun
11:38 a.m.
New subject: [xwiki-devs] Fwd: [GSoc] XDroid Platform
On Mon, Jun 18, 2012 at 11:30 AM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
---------- Forwarded message ----------
From: sasinda rukshan <sasindarukshan(a)gmail.com>
Date: Mon, Jun 18, 2012 at 2:56 PM
Subject: Re: [xwiki-devs] [GSoc] XDroid Platform
To: XWiki Developers <devs(a)xwiki.org>
Hi Thomas,
Thanks for the explanations.
The methods toXML , toEmbedXML are wrong.It was just an idea that came up
without much thinking. I will use a separate model
converter.(xwikitTosimpleModelConverter implements ModelConverter like
thing). So the model objects don't know about it at all.
By what you ment by "user" I think it is the client app developer is it?
Yes I mean the user of the API.
you did not mean end user. I never reveal the xml
representations to end
users.
I came up with a simpler design. I will post diagram later tomorrow.
Ok, this ASCII art here is not very easy to read ;)
To give a brief on it,
XObject : has protected property List<XProperty>
A Map<XProperty> would probably make more sense here since each
property as a unique name in an object and you will need to set some
specific property very often.
|__XPoperty :<< all objects that can be added
as a property of an objects
should extend this. Has an attribute list. cancels the
| property list of XObject
| |_____XString :
|__Abstract XDocObject :<< all documents should have an object of this.
This is the pages class. Has a object List<XObject>
| |____XBlog :<< all documents which are blogs should
have a object of this. This determines the class of the object.
| but this data is not posted
anywhere in <link rel="...../class"> . It is just kept for type checks.
That is like
| this page should include
XBlogPost objects.
|__XBlogPost : <<the BlogPostClass object.
In my view I assume every page has an object of some class. And this object
holds the objects which you can get under .../pages/BlogPg1/objects/
Well not exactly, you don't always have an object. A document can be
just about content. Just a wiki page if you prefer.
[
an added advantage:
I think we can make a ViewEngine to generate android View components from
the above model. Since the objects in the page carry rendering
descriptions.We can make a general model like a browser to
brows xwiki using generated the views. But the problem is some features in
specific spaces like blog do not seem to be totally defined by the XWiki
Object model behind them. Also this is just an idea (not suggesting I do
for the GSoc).Making it a usable reality is a little challenge.
]
So as you said if a document (I think it equivalent to a page) can have
many class types my assumption fails.
Why should a document be of multiple classes. I was thinking a page belongs
to a class. And the page is an instance of that class. If page can have
multiple classes my understanding should be wrong. Isn't it?
I don't understand, what I said is that you can only have one class in
a document but you can have several objects.
Thanks
Best Regards
Sasinda.
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
>>> >>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne
>>> >>>> > <thomas.mortagne(a)xwiki.com>wrote;wrote:
>>> >>>> >
>>> >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan
>>> >>>> >> <sasindarukshan(a)gmail.com> wrote:
>>> >>>> >> > Hi,
>>> >>>> >> > I am studying ORM Lite these days.
>>> >>>> >> > Please It would be comforting if you can
confirm whether it
is
>>> worth
>>> >>>> >> > the
>>> >>>> >> > overhead to use ORM Lite.
>>> >>>> >> >
>>> >>>> >>
>>> >>>> >>
>>>
http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projec…
>>> >>>> >> >
http://ormlite.com/
>>> >>>> >> > ORM Lite features:
>>> >>>> >> > Automatically Creates standard DAOs for an
annotated entity.
>>> >>>> >> > Coding will be lot easier.
>>> >>>> >>
>>> >>>> >> Remember it's a framework for a mobile platform
so it has to
>>> remain
>>> >>>> >> light and have good performances. I can see that
Android
version
>>> of
>>> >>>> >> ormlite is very small but I never used it so I
don't know if
>>> it's good
>>> >>>> >> or not. At least it seems petty active which is a
good point
so I
>>> >>>> >> don't
have anything against it.
>>> >>>> >>
>>> >>>> >> >
>>> >>>> >> > Can you suggest how to name the entities.
>>> >>>> >> > I am going to go with,
>>> >>>> >> > <entity> org.xwiki.xdroid.data.User
--> <table> C_USER
>>> >>>> >>
>>> >>>> >> Note that there is already a package name prefix
and group id
>>> defined
>>> >>>> >> for the framework and it's org.xwiki.android as
you can see on
>>> >>>> >> https://github.com/xwiki-contrib/android-client.
Why do you
>>> want to
>>> >>>> >> change it ? It's more consistent with
>>> >>>> >>
org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I
>>> would
>>> >>>> >> prefer to keep it that way unless you can give
arguments. The
>>> goal is
>>> >>>> >> not to redo something completely but complete and
improve the
>>> existing
>>> >>>> >> framework.
>>> >>>> >>
>>> >>>> >> Also as far as I can see there is already several
things
called
>>> >>>> >>
"xdroid" on Google play among which an application developer
>>> >>>> >>
(https://play.google.com/store/apps/developer?id=x-droid)
and an
>>> >>>> >> application
(
>>> >>>> >>
>>> >>>> >>
>>>
https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdro…
>>> >>>> >> ).
>>> >>>> >>
>>> >>>> >> >
>>> >>>> >> > Thanks,
>>> >>>> >> > Best Regards
>>> >>>> >> >
>>> >>>> >> > Sasinda.
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda
rukshan
>>> >>>> >> > <sasindarukshan(a)gmail.com>wrote;wrote:
>>> >>>> >> >
>>> >>>> >> >> Hi,
>>> >>>> >> >>
>>> >>>> >> >> I am commiting my work to my fork
>>> >>>> >> >>
https://github.com/sasinda/android-client.
>>> >>>> >> >> I ll request to pull it to xwiki-contrib
later.
>>> >>>> >> >>
>>> >>>> >> >> I was running in a wrong path these days.
Wanted to save
login
>>> >>>> >> >>
history
>>> >>>> >> and
>>> >>>> >> >> suggest login. I was going to do it using
an xml file
(login
>>> >>>> >>
attempts.xml).
>>> >>>> >> >> Now it seems database is better.
>>> >>>> >> >> Any way before I go wrong again I will say
what I am going
to
>>> do.
>>> >>>> >> >> I am going to enforce following
conventions.These are not
yet
>>> >>>> >> >>
needed,
>>> >>>> >> >> considered the small scale.But when the
system grows it
would
>>> be
>>> >>>> >> >> nice to
>>> >>>> >> >> have them to avoid confusions.
>>> >>>> >> >> *Database prefixes for:*
>>> >>>> >> >> *Platform tables (can begin with
appropriate prefix)*
>>> >>>> >> >> AD_ //application dictionary : don't
know when it will be
>>> needed ;-)
>>> >>>> >> >> C_ //core functionality
>>> >>>> >> >> *Client Applications.*
>>> >>>> >> >> X<App name prefix> ex: XBLOG_ for
Blog app// All client
>>> add in
>>> >>>> >> modules
>>> >>>> >> >> must begin with table prefix X(for xwiki
and ordering) +
App
>>> name.
>>> >>>> >> This is
>>> >>>> >> >> for my blog.
>>> >>>> >> >>
>>> >>>> >> >> I will create
>>> >>>> >> >> C_User for user data.
>>> >>>> >> >> C_LoginAttempt for saving login
attempts.
>>> >>>> >> >>
>>> >>>> >> >> From C_LoginAttempt I can filter uniqe
login combinations
and
>>> give
>>> >>>> >> >> suggestions in the login UI component.
Also save the
history.
>>> >>>> >> >>
>>> >>>> >> >> All saved data for blog app will be linked
to a perticular
>>> login :
>>> >>>> >> >> User,
>>> >>>> >> >> XWiki server.
>>> >>>> >> >> But only a single user will be most
probably using his
>>> personal
>>> >>>> >> >> device.
>>> >>>> >> So
>>> >>>> >> >> above will be relevant only when he has
multiple wikis.
>>> >>>> >> >>
>>> >>>> >> >> Best Regards,
>>> >>>> >> >> Sasinda Rukshan.
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >> On Sun, May 27, 2012 at 5:43 PM, Chamika
Weerasinghe <
>>> >>>> >> chamikaw(a)gmail.com>wroteote:
>>> >>>> >> >>
>>> >>>> >> >>> On Fri, May 25, 2012 at 1:25 AM,
Jerome Velociter <
>>> >>>> >> jerome(a)winesquare.net
>>> >>>> >> >>> >wrote:
>>> >>>> >> >>>
>>> >>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM,
Thomas Mortagne
>>> >>>> >> >>> > <thomas.mortagne(a)xwiki.com>
wrote:
>>> >>>> >> >>> > > On Thu, May 24, 2012 at 5:52
PM, sasinda rukshan
>>> >>>> >> >>> > >
<sasindarukshan(a)gmail.com> wrote:
>>> >>>> >> >>> > >> Hi all,
>>> >>>> >> >>> > >> I am starting this
thread for my XWiki Android
Platform
>>> >>>> >>
>>> > >> Project.
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > >> Please check whether
following are OK.
>>> >>>> >> >>> > >> [1] INFO
>>> >>>> >> >>> > >> I tried to start my new
modules with the
>>> >>>> >> >>> de.akquinet.android.archetypes:
>>> >>>> >> >>> > >>
android-quickstart:1.0.8. (added eclipse plugins
m2e,
>>> >>>> >>
>>> > >> m2e-android[a.k.a *Android
>>> >>>> >> >>> > >> Configurator* ]). But
this seems buggy in eclipse.
>>> >>>> >> >>> > >> Any way the earlier
project has not followed the
above
>>> >>>> >>
>>> > >> archtype
>>> >>>> >> >>> either.
>>> >>>> >> >>> > So
>>> >>>> >> >>> > >> I am going to write
pom.xml manually for my each
module.
>>> >>>> >>
>>> > >>
>>> >>>> >> >>> > >> [2] ADVICE NEEDED
>>> >>>> >> >>> > >> xwiki-rest-model module
contains 2 submodules
>>> >>>> >> >>> > >> |--
xwiki-rest-model-gson ( gson should be
corrected
>>> to
>>> >>>> >> >>> > >> json)
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > No the g is not a mistake,
it's a model to be used
with
>>> the
>>> >>>> >> >>> > > gson
>>> >>>> >> >>> > > library
(http://code.google.com/p/google-gson/). See
>>> >>>> >> >>> > >
>>> >>>> >> >>> >
>>> >>>> >> >>>
>>> >>>> >>
>>> >>>> >>
>>>
http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#…
>>> >>>> >>
>>> > .
>>> >>>> >> >>> > >
>>> >>>> >> >>> > >> |--
xwiki-rest-model-simplexml
>>> >>>> >> >>> > >> I think the
xwiki-rest-model-gson is redundant. The
>>> classes
>>> >>>> >> >>> > >> in
xwiki-rest-model-simplexml is added with simple
xml
>>> >>>> >>
annotations,
>>> >>>> >> >>> > >> otherwise both modules
have same classes. There is no
>>> problem
>>> >>>> >> >>> > >> with
>>> >>>> >> >>> the
>>> >>>> >> >>> > >> added annotations for
using the same model objects
for
>>> Json
>>> >>>> >> >>> > >> REST
>>> >>>> >> web
>>> >>>> >> >>> > >> services. And I intend
to add my JPA (ORMLite library
>>> for
>>> >>>> >> >>> persistence)
>>> >>>> >> >>> > >> annotations on top of
it.
>>> >>>> >> >>> > >> Shall I re-factor them
to a single module
>>> xwiki-rest-model.
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > No keep them separated, the
idea is that both are
useful
>>> tool
>>> >>>> >> >>> > > to be
>>> >>>> >> >>> > > used by someone else that
might be moved to
>>> xwiki-platform at
>>> >>>> >> >>> > > some
>>> >>>> >> >>> > > point along with the current
xwiki-rest-model (to be
>>> renamed to
>>> >>>> >> >>> > > xwiki-rest-model-jaxb).
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > Chamika initially started
with gson and since XWiki
REST
>>> JSON
>>> >>>> >> >>> > > representation had some
limitation he moved to XML
>>> >>>> >> >>> > > representation.
>>> >>>> >> >>> > > Maybe at some point Android
will have native support
for
>>> jaxb
>>> >>>> >> >>> > > which
>>> >>>> >> >>> > > would obviously be the
easier for us (embedding jaxb
is
>>> not an
>>> >>>> >> option
>>> >>>> >> >>> > > in mobile world where size
it still pretty important
>>> especially
>>> >>>> >> >>> > > on
>>> >>>> >> >>> > > phones). Maybe it's
already the case on most recent
>>> versions
>>> >>>> >> >>> > > like
>>> >>>> >> 4.0
>>> >>>> >> >>> > > I don't know.
>>> >>>> >> >>> >
>>> >>>> >> >>> > There's also Jackson that
could be tried for JSON
>>> >>>> >> >>> > deserialization, if
>>> >>>> >> >>> > said limitations are actually
GSON limitations.
>>> >>>> >> >>> >
>>> >>>> >> >>> GSON wasn't the limitation.
>>> >>>> >> >>> It was XWiki RESTful API which
doesn't support JSON in
some
>>> cases.
>>> >>>> >> >>> So
>>> >>>> >> it's
>>> >>>> >> >>> safe to go with xml.
>>> >>>> >> >>>
>>> >>>> >> >>> >
>>> >>>> >> >>> > Having full JAXB support sound a
bit overweight for
such an
>>> >>>> >>
>>> > "embedded
>>> >>>> >> >>> > API", even if one day it is
natively supported by
Android.
>>> What's
>>> >>>> >> >>> > important is to have an easy and
fast deserialization,
IMO.
>>> >>>> >>
>>> > The only advantage I can see of going JAXB would be in
>>> re-using
>>> >>>> >> >>> > the
>>> >>>> >> >>> > exact representations and body
readers/writers from
XWiki
>>> core.
>>> >>>> >> >>> > But
>>> >>>> >> >>> > you probably don't even want
to do that since it would
mean
>>> >>>> >>
>>> > dragging
>>> >>>> >> >>> > XWiki core with you :)
>>> >>>> >> >>> >
>>> >>>> >> >>> > Jerome
>>> >>>> >> >>> >
>>> >>>> >> >>> > >
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > >> [3] INFO
>>> >>>> >> >>> > >> I had to change some
pom.xml s. As the current
project
>>> at:
>>> >>>> >> >>> > >>
https://github.com/xwiki-contrib/android-client.gitdoes not
>>> >>>> >> build.
>>> >>>> >> >>> > Error
>>> >>>> >> >>> > >> with parent pom.xml
coordinates.
>>> >>>> >> >>> > >
>>> >>>> >> >>> > > You probably did not setup
you maven install properly
>>> since
>>> >>>> >> >>> > > what's
>>> >>>> >> on
>>> >>>> >> >>> > >
https://github.com/xwiki-contrib/android-client.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
>> >>>> >> >>> > >> devs(a)xwiki.org
>> >>>> >> >>> > >>
http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>> > >
>> >>>> >> >>> > >
>> >>>> >> >>> > >
>> >>>> >> >>> > > --
>> >>>> >> >>> > > Thomas Mortagne
>> >>>> >> >>> > >
_______________________________________________
>> >>>> >> >>> > > devs mailing list
>> >>>> >> >>> > > devs(a)xwiki.org
>> >>>> >> >>> > >
http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>> >
>> >>>> >> >>> >
>> >>>> >> >>> >
>> >>>> >> >>> > --
>> >>>> >> >>> > Jérôme Velociter
>> >>>> >> >>> > Winesquare
>> >>>> >> >>> > http://www.winesquare.net/
>> >>>> >> >>> >
_______________________________________________
>> >>>> >> >>> > devs mailing list
>> >>>> >> >>> > devs(a)xwiki.org
>> >>>> >> >>> >
http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>> >
>> >>>> >> >>>
_______________________________________________
>> >>>> >> >>> devs mailing list
>> >>>> >> >>> devs(a)xwiki.org
>> >>>> >> >>>
http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>>
>> >>>> >> >>
>> >>>> >> >>
>> >>>> >> > _______________________________________________
>> >>>> >> > devs mailing list
>> >>>> >> > devs(a)xwiki.org
>> >>>> >> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> --
>> >>>> >> Thomas Mortagne
>> >>>> >> _______________________________________________
>> >>>> >> devs mailing list
>> >>>> >> devs(a)xwiki.org
>> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>
>> >>>> > _______________________________________________
>> >>>> > devs mailing list
>> >>>> > devs(a)xwiki.org
>> >>>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Thomas Mortagne
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Thomas Mortagne
>> >
>> >
>> >
>> > --
>> > Thomas Mortagne
>>
>>
>>
>> --
>> Thomas Mortagne
>>
>
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:50 a.m.
New subject: [xwiki-devs] Fwd: Fwd: [GSoc] XDroid Platform
Hi Thomas,
Oops sorry,
--
Thomas Mortagne
I don't understand, what I said is that you can
only have one class in
a document but you can have several objects
I was busy with some office work also. Just skimmed through.
I will send a draft UML class diagram later.It will be prettier than asci
art :-).
>A Map<XProperty> would probably make more
sense
Yeah needs to use Maps. Thnx. I was careless.
Thanks for the Quick reply.
Best Regards
Sasinda.
---------- Forwarded message ----------
From: Thomas Mortagne <thomas.mortagne(a)xwiki.com>
Date: Mon, Jun 18, 2012 at 3:08 PM
Subject: Re: [xwiki-devs] Fwd: [GSoc] XDroid Platform
To: sasindarukshan(a)gmail.com, XWiki Developers <devs(a)xwiki.org>
On Mon, Jun 18, 2012 at 11:30 AM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
---------- Forwarded message ----------
From: sasinda rukshan <sasindarukshan(a)gmail.com>
Date: Mon, Jun 18, 2012 at 2:56 PM
Subject: Re: [xwiki-devs] [GSoc] XDroid Platform
To: XWiki Developers <devs(a)xwiki.org>
Hi Thomas,
Thanks for the explanations.
The methods toXML , toEmbedXML are wrong.It was just an idea that came up
without much thinking. I will use a separate model
converter.(xwikitTosimpleModelConverter implements ModelConverter like
thing). So the model objects don't know about it at all.
By what you ment by "user" I think it is the client app developer is it?
Yes I mean the user of the API.
you did not mean end user. I never reveal the xml
representations to end
users.
I came up with a simpler design. I will post diagram later tomorrow.
Ok, this ASCII art here is not very easy to read ;)
To give a brief on it,
XObject : has protected property List<XProperty>
A Map<XProperty> would probably make more sense here since each
property as a unique name in an object and you will need to set some
specific property very often.
|__XPoperty :<< all objects that can be added
as a property of an
objects
should extend this. Has an attribute list. cancels
the
| property list of XObject
| |_____XString :
|__Abstract XDocObject :<< all documents should have an object of this.
This is the pages class. Has a object List<XObject>
| |____XBlog :<< all documents which are blogs should
have a object of this. This determines the class of the object.
| but this data is not posted
anywhere in <link rel="...../class"> . It is just kept for type checks.
That is like
| this page should include
XBlogPost objects.
|__XBlogPost : <<the BlogPostClass object.
In my view I assume every page has an object of some class. And this
object
holds the objects which you can get under
.../pages/BlogPg1/objects/
Well not exactly, you don't always have an object. A document can be
just about content. Just a wiki page if you prefer.
[
an added advantage:
I think we can make a ViewEngine to generate android View components from
the above model. Since the objects in the page carry rendering
descriptions.We can make a general model like a browser to
brows xwiki using generated the views. But the problem is some features in
specific spaces like blog do not seem to be totally defined by the XWiki
Object model behind them. Also this is just an idea (not suggesting I do
for the GSoc).Making it a usable reality is a little challenge.
]
So as you said if a document (I think it equivalent to a page) can have
many class types my assumption fails.
Why should a document be of multiple classes. I was thinking a page
belongs
to a class. And the page is an instance of that class.
If page can have
multiple classes my understanding should be wrong. Isn't it?
I don't understand, what I said is that you can only have one class in
a document but you can have several objects.
Thanks
Best Regards
Sasinda.
> >>>> >>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas
Mortagne
> >>>> >>>> > <thomas.mortagne(a)xwiki.com>wrote;wrote:
> >>>> >>>> >
> >>>> >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda
rukshan
> >>>> >>>> >> <sasindarukshan(a)gmail.com> wrote:
> >>>> >>>> >> > Hi,
> >>>> >>>> >> > I am studying ORM Lite these days.
> >>>> >>>> >> > Please It would be comforting if you
can confirm whether
it
> is
> >>>> worth
> >>>> >>>> >> > the
> >>>> >>>> >> > overhead to use ORM Lite.
> >>>> >>>> >> >
> >>>> >>>> >>
> >>>> >>>> >>
> >>>>
>
http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projec…
> >>>> >>>> >> >
http://ormlite.com/
> >>>> >>>> >> > ORM Lite features:
> >>>> >>>> >> > Automatically Creates standard DAOs
for an annotated
entity.
> >>>> >>>> >> >
Coding will be lot easier.
> >>>> >>>> >>
> >>>> >>>> >> Remember it's a framework for a mobile
platform so it has to
> >>>> remain
> >>>> >>>> >> light and have good performances. I can
see that Android
> version
> >>>> of
> >>>> >>>> >> ormlite is very small but I never used it
so I don't know if
> >>>> it's good
> >>>> >>>> >> or not. At least it seems petty active
which is a good point
> so I
> >>>> >>>> >> don't have anything against it.
> >>>> >>>> >>
> >>>> >>>> >> >
> >>>> >>>> >> > Can you suggest how to name the
entities.
> >>>> >>>> >> > I am going to go with,
> >>>> >>>> >> > <entity>
org.xwiki.xdroid.data.User --> <table> C_USER
> >>>> >>>> >>
> >>>> >>>> >> Note that there is already a package name
prefix and group
id
> >>>> defined
> >>>> >>>> >> for the framework and it's
org.xwiki.android as you can see
on
> >>>> >>>> >>
https://github.com/xwiki-contrib/android-client. Why do you
> >>>> want to
> >>>> >>>> >> change it ? It's more consistent with
> >>>> >>>> >>
org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so
I
> >>>> would
> >>>> >>>> >> prefer to keep it that way unless you can
give arguments.
The
> >>>> goal is
> >>>> >>>> >> not to redo something completely but
complete and improve
the
> >>>> existing
> >>>> >>>> >> framework.
> >>>> >>>> >>
> >>>> >>>> >> Also as far as I can see there is already
several things
> called
> >>>> >>>> >> "xdroid" on Google play among
which an application developer
> >>>> >>>> >>
(https://play.google.com/store/apps/developer?id=x-droid)
> and an
> >>>> >>>> >> application (
> >>>> >>>> >>
> >>>> >>>> >>
> >>>>
>
https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdro…
> >>>> >>>> >> ).
> >>>> >>>> >>
> >>>> >>>> >> >
> >>>> >>>> >> > Thanks,
> >>>> >>>> >> > Best Regards
> >>>> >>>> >> >
> >>>> >>>> >> > Sasinda.
> >>>> >>>> >> >
> >>>> >>>> >> >
> >>>> >>>> >> >
> >>>> >>>> >> >
> >>>> >>>> >> >
> >>>> >>>> >> > On Wed, May 30, 2012 at 7:42 AM,
sasinda rukshan
> >>>> >>>> >> >
<sasindarukshan(a)gmail.com>wrote;wrote:
> >>>> >>>> >> >
> >>>> >>>> >> >> Hi,
> >>>> >>>> >> >>
> >>>> >>>> >> >> I am commiting my work to my
fork
> >>>> >>>> >> >>
https://github.com/sasinda/android-client.
> >>>> >>>> >> >> I ll request to pull it to
xwiki-contrib later.
> >>>> >>>> >> >>
> >>>> >>>> >> >> I was running in a wrong path
these days. Wanted to save
> login
> >>>> >>>> >> >> history
> >>>> >>>> >> and
> >>>> >>>> >> >> suggest login. I was going to do
it using an xml file
> (login
> >>>> >>>> >> attempts.xml).
> >>>> >>>> >> >> Now it seems database is better.
> >>>> >>>> >> >> Any way before I go wrong again I
will say what I am
going
> to
> >>>> do.
> >>>> >>>> >> >> I am going to enforce following
conventions.These are not
> yet
> >>>> >>>> >> >> needed,
> >>>> >>>> >> >> considered the small scale.But
when the system grows it
> would
> >>>> be
> >>>> >>>> >> >> nice to
> >>>> >>>> >> >> have them to avoid confusions.
> >>>> >>>> >> >> *Database prefixes for:*
> >>>> >>>> >> >> *Platform tables (can begin with
appropriate prefix)*
> >>>> >>>> >> >> AD_ //application dictionary :
don't know when it will be
> >>>> needed ;-)
> >>>> >>>> >> >> C_ //core functionality
> >>>> >>>> >> >> *Client Applications.*
> >>>> >>>> >> >> X<App name prefix> ex:
XBLOG_ for Blog app// All
client
> >>>> add in
> >>>> >>>> >> modules
> >>>> >>>> >> >> must begin with table prefix
X(for xwiki and ordering) +
> App
> >>>> name.
> >>>> >>>> >> This is
> >>>> >>>> >> >> for my blog.
> >>>> >>>> >> >>
> >>>> >>>> >> >> I will create
> >>>> >>>> >> >> C_User for user data.
> >>>> >>>> >> >> C_LoginAttempt for saving login
attempts.
> >>>> >>>> >> >>
> >>>> >>>> >> >> From C_LoginAttempt I can filter
uniqe login combinations
> and
> >>>> give
> >>>> >>>> >> >> suggestions in the login UI
component. Also save the
> history.
> >>>> >>>> >> >>
> >>>> >>>> >> >> All saved data for blog app will
be linked to a
perticular
> >>>> login :
> >>>> >>>> >> >> User,
> >>>> >>>> >> >> XWiki server.
> >>>> >>>> >> >> But only a single user will be
most probably using his
> >>>> personal
> >>>> >>>> >> >> device.
> >>>> >>>> >> So
> >>>> >>>> >> >> above will be relevant only when
he has multiple wikis.
> >>>> >>>> >> >>
> >>>> >>>> >> >> Best Regards,
> >>>> >>>> >> >> Sasinda Rukshan.
> >>>> >>>> >> >>
> >>>> >>>> >> >>
> >>>> >>>> >> >>
> >>>> >>>> >> >>
> >>>> >>>> >> >>
> >>>> >>>> >> >> On Sun, May 27, 2012 at 5:43 PM,
Chamika Weerasinghe <
> >>>> >>>> >> chamikaw(a)gmail.com>wroteote:
> >>>> >>>> >> >>
> >>>> >>>> >> >>> On Fri, May 25, 2012 at 1:25
AM, Jerome Velociter <
> >>>> >>>> >> jerome(a)winesquare.net
> >>>> >>>> >> >>> >wrote:
> >>>> >>>> >> >>>
> >>>> >>>> >> >>> > On Thu, May 24, 2012 at
6:09 PM, Thomas Mortagne
> >>>> >>>> >> >>> >
<thomas.mortagne(a)xwiki.com> wrote:
> >>>> >>>> >> >>> > > On Thu, May 24,
2012 at 5:52 PM, sasinda rukshan
> >>>> >>>> >> >>> > >
<sasindarukshan(a)gmail.com> wrote:
> >>>> >>>> >> >>> > >> Hi all,
> >>>> >>>> >> >>> > >> I am starting
this thread for my XWiki Android
> Platform
> >>>> >>>> >> >>> > >> Project.
> >>>> >>>> >> >>> > >>
> >>>> >>>> >> >>> > >> Please check
whether following are OK.
> >>>> >>>> >> >>> > >> [1] INFO
> >>>> >>>> >> >>> > >> I tried to
start my new modules with the
> >>>> >>>> >> >>>
de.akquinet.android.archetypes:
> >>>> >>>> >> >>> > >>
android-quickstart:1.0.8. (added eclipse plugins
> m2e,
> >>>> >>>> >> >>> > >>
m2e-android[a.k.a *Android
> >>>> >>>> >> >>> > >> Configurator*
]). But this seems buggy in eclipse.
> >>>> >>>> >> >>> > >> Any way the
earlier project has not followed the
> above
> >>>> >>>> >> >>> > >> archtype
> >>>> >>>> >> >>> either.
> >>>> >>>> >> >>> > So
> >>>> >>>> >> >>> > >> I am going to
write pom.xml manually for my each
> module.
> >>>> >>>> >> >>> > >>
> >>>> >>>> >> >>> > >> [2] ADVICE
NEEDED
> >>>> >>>> >> >>> > >>
xwiki-rest-model module contains 2 submodules
> >>>> >>>> >> >>> > >> |--
xwiki-rest-model-gson ( gson should be
> corrected
> >>>> to
> >>>> >>>> >> >>> > >> json)
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> > > No the g is not a
mistake, it's a model to be used
> with
> >>>> the
> >>>> >>>> >> >>> > > gson
> >>>> >>>> >> >>> > > library
(http://code.google.com/p/google-gson/). See
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> >
> >>>> >>>> >> >>>
> >>>> >>>> >>
> >>>> >>>> >>
> >>>>
>
http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#…
> >>>> >>>> >>
>>> > .
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> > >> |--
xwiki-rest-model-simplexml
> >>>> >>>> >> >>> > >> I think the
xwiki-rest-model-gson is redundant. The
> >>>> classes
> >>>> >>>> >> >>> > >> in
xwiki-rest-model-simplexml is added with simple
> xml
> >>>> >>>> >> annotations,
> >>>> >>>> >> >>> > >> otherwise both
modules have same classes. There is
no
> >>>> problem
> >>>> >>>> >> >>> > >> with
> >>>> >>>> >> >>> the
> >>>> >>>> >> >>> > >> added
annotations for using the same model objects
> for
> >>>> Json
> >>>> >>>> >> >>> > >> REST
> >>>> >>>> >> web
> >>>> >>>> >> >>> > >> services. And I
intend to add my JPA (ORMLite
library
> >>>> for
> >>>> >>>> >> >>> persistence)
> >>>> >>>> >> >>> > >> annotations on
top of it.
> >>>> >>>> >> >>> > >> Shall I
re-factor them to a single module
> >>>> xwiki-rest-model.
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> > > No keep them
separated, the idea is that both are
> useful
> >>>> tool
> >>>> >>>> >> >>> > > to be
> >>>> >>>> >> >>> > > used by someone
else that might be moved to
> >>>> xwiki-platform at
> >>>> >>>> >> >>> > > some
> >>>> >>>> >> >>> > > point along with
the current xwiki-rest-model (to be
> >>>> renamed to
> >>>> >>>> >> >>> > >
xwiki-rest-model-jaxb).
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> > > Chamika initially
started with gson and since XWiki
> REST
> >>>> JSON
> >>>> >>>> >> >>> > > representation had
some limitation he moved to XML
> >>>> >>>> >> >>> > > representation.
> >>>> >>>> >> >>> > > Maybe at some point
Android will have native support
> for
> >>>> jaxb
> >>>> >>>> >> >>> > > which
> >>>> >>>> >> >>> > > would obviously be
the easier for us (embedding jaxb
> is
> >>>> not an
> >>>> >>>> >> option
> >>>> >>>> >> >>> > > in mobile world
where size it still pretty important
> >>>> especially
> >>>> >>>> >> >>> > > on
> >>>> >>>> >> >>> > > phones). Maybe
it's already the case on most recent
> >>>> versions
> >>>> >>>> >> >>> > > like
> >>>> >>>> >> 4.0
> >>>> >>>> >> >>> > > I don't know.
> >>>> >>>> >> >>> >
> >>>> >>>> >> >>> > There's also Jackson
that could be tried for JSON
> >>>> >>>> >> >>> > deserialization, if
> >>>> >>>> >> >>> > said limitations are
actually GSON limitations.
> >>>> >>>> >> >>> >
> >>>> >>>> >> >>> GSON wasn't the
limitation.
> >>>> >>>> >> >>> It was XWiki RESTful API
which doesn't support JSON in
> some
> >>>> cases.
> >>>> >>>> >> >>> So
> >>>> >>>> >> it's
> >>>> >>>> >> >>> safe to go with xml.
> >>>> >>>> >> >>>
> >>>> >>>> >> >>> >
> >>>> >>>> >> >>> > Having full JAXB support
sound a bit overweight for
> such an
> >>>> >>>> >> >>> > "embedded
> >>>> >>>> >> >>> > API", even if one
day it is natively supported by
> Android.
> >>>> What's
> >>>> >>>> >> >>> > important is to have an
easy and fast deserialization,
> IMO.
> >>>> >>>> >> >>> > The only advantage I can
see of going JAXB would be in
> >>>> re-using
> >>>> >>>> >> >>> > the
> >>>> >>>> >> >>> > exact representations
and body readers/writers from
> XWiki
> >>>> core.
> >>>> >>>> >> >>> > But
> >>>> >>>> >> >>> > you probably don't
even want to do that since it would
> mean
> >>>> >>>> >> >>> > dragging
> >>>> >>>> >> >>> > XWiki core with you :)
> >>>> >>>> >> >>> >
> >>>> >>>> >> >>> > Jerome
> >>>> >>>> >> >>> >
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> > >>
> >>>> >>>> >> >>> > >> [3] INFO
> >>>> >>>> >> >>> > >> I had to
change some pom.xml s. As the current
> project
> >>>> at:
> >>>> >>>> >> >>> > >>
> https://github.com/xwiki-contrib/android-client.gitdoes not
> >>>> >>>> >> build.
> >>>> >>>> >> >>> > Error
> >>>> >>>> >> >>> > >> with parent
pom.xml coordinates.
> >>>> >>>> >> >>> > >
> >>>> >>>> >> >>> > > You probably did
not setup you maven install
properly
> >>>> since
> >>>> >>>> >> >>> > > what's
> >>>> >>>> >> on
> >>>> >>>> >> >>> > >
> https://github.com/xwiki-contrib/android-client.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
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs >>> >>>> >>
repository..
>>> >>>> >> >>> > > You should look at
>>> >>>> >> >>> > >
http://dev.xwiki.org/xwiki/bin/view/Community/Building.
>>
>>>> >> >>> > >
>> >>>> >> >>> > >>
>> >>>> >> >>> > >>
>> >>>> >> >>> > >> Thank you
>> >>>> >> >>> > >> Best Regards.
>> >>>> >> >>> > >> Sasinda Rukshan
>> >>>> >> >>> > >>
_______________________________________________
>> >>>> >> >>> > >> devs mailing list
>> >>>> >> >>> > >> devs(a)xwiki.org
>> >>>> >> >>> > >>
http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>> > >
>> >>>> >> >>> > >
>> >>>> >> >>> > >
>> >>>> >> >>> > > --
>> >>>> >> >>> > > Thomas Mortagne
>> >>>> >> >>> > >
_______________________________________________
>> >>>> >> >>> > > devs mailing list
>> >>>> >> >>> > > devs(a)xwiki.org
>> >>>> >> >>> > >
http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>> >
>> >>>> >> >>> >
>> >>>> >> >>> >
>> >>>> >> >>> > --
>> >>>> >> >>> > Jérôme Velociter
>> >>>> >> >>> > Winesquare
>> >>>> >> >>> > http://www.winesquare.net/
>> >>>> >> >>> >
_______________________________________________
>> >>>> >> >>> > devs mailing list
>> >>>> >> >>> > devs(a)xwiki.org
>> >>>> >> >>> >
http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>> >
>> >>>> >> >>>
_______________________________________________
>> >>>> >> >>> devs mailing list
>> >>>> >> >>> devs(a)xwiki.org
>> >>>> >> >>>
http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >> >>>
>> >>>> >> >>
>> >>>> >> >>
>> >>>> >> > _______________________________________________
>> >>>> >> > devs mailing list
>> >>>> >> > devs(a)xwiki.org
>> >>>> >> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> --
>> >>>> >> Thomas Mortagne
>> >>>> >> _______________________________________________
>> >>>> >> devs mailing list
>> >>>> >> devs(a)xwiki.org
>> >>>> >> http://lists.xwiki.org/mailman/listinfo/devs
>> >>>> >>
>> >>>> > _______________________________________________
>> >>>> > devs mailing list
>> >>>> > devs(a)xwiki.org
>> >>>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Thomas Mortagne
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Thomas Mortagne
>> >
>> >
>> >
>> > --
>> > Thomas Mortagne
>>
>>
>>
>> --
>> Thomas Mortagne
>>
>
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
22 Jun
22 Jun
4:01 a.m.
New subject: [xwiki-devs] Fwd: [GSoc] XDroid Platform
Hi,
Pushed some initial scaffolding's of XWiki model to android, in to
https://github.com/xwiki-contrib/android-client
This is the basic idea.
The client app developers will be only exposed to a service layer. All
packages suffixed with "Svc" have these.
package: cmnSvc >> has the LoginFacade. called to log in to server and
system.(also update state of XWikiContext in the android and etc)
package blogSvc >> will have BlogDocument, CategoryDocument and etc which
can be used to create posts and update server.
The base class Document will handle all server updations(through a
ReSTfulAdapter, to decouple Document and underlying rest model: simple
XML/Gson) and etc.
Please check whether approach to redesigning com.xpn....objects into
org.xwiki.android.xmodel.xobjects is correct.
Thanks.
Best Regards.
Sasinda.
On Mon, Jun 18, 2012 at 3:20 PM, sasinda rukshan
<sasindarukshan(a)gmail.com>wrote;wrote:
Hi Thomas,
---------- Forwarded message ----------
From: Thomas Mortagne <thomas.mortagne(a)xwiki.com>
Date: Mon, Jun 18, 2012 at 3:08 PM
Subject: Re: [xwiki-devs] Fwd: [GSoc] XDroid Platform
To: sasindarukshan(a)gmail.com, XWiki Developers <devs(a)xwiki.org>
On Mon, Jun 18, 2012 at 11:30 AM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
---------- Forwarded message ----------
From: sasinda rukshan <sasindarukshan(a)gmail.com>
Date: Mon, Jun 18, 2012 at 2:56 PM
Subject: Re: [xwiki-devs] [GSoc] XDroid Platform
To: XWiki Developers <devs(a)xwiki.org>
Hi Thomas,
Thanks for the explanations.
The methods toXML , toEmbedXML are wrong.It was just an idea that came up
without much thinking. I will use a separate model
converter.(xwikitTosimpleModelConverter implements ModelConverter like
thing). So the model objects don't know about it at all.
By what you ment by "user" I think it is the client app developer is it?
Yes I mean the user of the API.
you did not mean end user. I never reveal the xml
representations to end
users.
I came up with a simpler design. I will post diagram later tomorrow.
Ok, this ASCII art here is not very easy to read ;)
To give a brief on it,
XObject : has protected property List<XProperty>
A Map<XProperty> would probably make more sense here since each
property as a unique name in an object and you will need to set some
specific property very often.
|__XPoperty :<< all objects that can be
added as a property of an
objects
should extend this. Has an attribute list.
cancels the
| property list of XObject
| |_____XString :
|__Abstract XDocObject :<< all documents should have an object of this.
This is the pages class. Has a object List<XObject>
| |____XBlog :<< all documents which are blogs should
have a object of this. This determines the class of the object.
| but this data is not posted
anywhere in <link rel="...../class"> . It is just kept for type checks.
That is like
| this page should include
XBlogPost objects.
|__XBlogPost : <<the BlogPostClass object.
In my view I assume every page has an object of some class. And this
object
holds the objects which you can get under
.../pages/BlogPg1/objects/
Well not exactly, you don't always have an object. A document can be
just about content. Just a wiki page if you prefer.
[
an added advantage:
I think we can make a ViewEngine to generate android View components from
the above model. Since the objects in the page carry rendering
descriptions.We can make a general model like a browser to
brows xwiki using generated the views. But the problem is some features
in
specific spaces like blog do not seem to be
totally defined by the XWiki
Object model behind them. Also this is just an idea (not suggesting I do
for the GSoc).Making it a usable reality is a little challenge.
]
So as you said if a document (I think it equivalent to a page) can have
many class types my assumption fails.
Why should a document be of multiple classes. I was thinking a page
belongs
to a class. And the page is an instance of that
class. If page can have
multiple classes my understanding should be wrong. Isn't it?
I don't understand, what I said is that you can only have one class in
a document but you can have several objects.
Thanks
Best Regards
Sasinda.
4:03 a.m.
New subject: [xwiki-devs] Fwd: [GSoc] XDroid Platform
hi,
PS:
check the *p2 branch*. Not master. Did not merge yet. :-)
Regards,
Sasinda.
On Fri, Jun 22, 2012 at 7:31 AM, sasinda rukshan
<sasindarukshan(a)gmail.com>wrote;wrote:
Hi,
Pushed some initial scaffolding's of XWiki model to android, in to
https://github.com/xwiki-contrib/android-client
This is the basic idea.
The client app developers will be only exposed to a service layer. All
packages suffixed with "Svc" have these.
package: cmnSvc >> has the LoginFacade. called to log in to server and
system.(also update state of XWikiContext in the android and etc)
package blogSvc >> will have BlogDocument, CategoryDocument and etc which
can be used to create posts and update server.
The base class Document will handle all server updations(through a
ReSTfulAdapter, to decouple Document and underlying rest model: simple
XML/Gson) and etc.
Please check whether approach to redesigning com.xpn....objects into
org.xwiki.android.xmodel.xobjects is correct.
Thanks.
Best Regards.
Sasinda.
On Mon, Jun 18, 2012 at 3:20 PM, sasinda rukshan <sasindarukshan(a)gmail.com
wrote:
Hi Thomas,
---------- Forwarded message ----------
From: Thomas Mortagne <thomas.mortagne(a)xwiki.com>
Date: Mon, Jun 18, 2012 at 3:08 PM
Subject: Re: [xwiki-devs] Fwd: [GSoc] XDroid Platform
To: sasindarukshan(a)gmail.com, XWiki Developers <devs(a)xwiki.org>
On Mon, Jun 18, 2012 at 11:30 AM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
---------- Forwarded message ----------
From: sasinda rukshan <sasindarukshan(a)gmail.com>
Date: Mon, Jun 18, 2012 at 2:56 PM
Subject: Re: [xwiki-devs] [GSoc] XDroid Platform
To: XWiki Developers <devs(a)xwiki.org>
Hi Thomas,
Thanks for the explanations.
The methods toXML , toEmbedXML are wrong.It was just an idea that came
up
without much thinking. I will use a separate
model
converter.(xwikitTosimpleModelConverter implements ModelConverter like
thing). So the model objects don't know about it at all.
By what you ment by "user" I think it is the client app developer is it?
Yes I mean the user of the API.
you did not mean end user. I never reveal the xml
representations to end
users.
I came up with a simpler design. I will post diagram later tomorrow.
Ok, this ASCII art here is not very easy to read ;)
To give a brief on it,
XObject : has protected property List<XProperty>
A Map<XProperty> would probably make more sense here since each
property as a unique name in an object and you will need to set some
specific property very often.
|__XPoperty :<< all objects that can be
added as a property of an
objects
should extend this. Has an attribute list.
cancels the
| property list of XObject
| |_____XString :
|__Abstract XDocObject :<< all documents should have an object of this.
This is the pages class. Has a object List<XObject>
| |____XBlog :<< all documents which are blogs should
have a object of this. This determines the class of the object.
| but this data is not posted
anywhere in <link rel="...../class"> . It is just kept for type checks.
That is like
| this page should include
XBlogPost objects.
|__XBlogPost : <<the BlogPostClass object.
In my view I assume every page has an object of some class. And this
object
holds the objects which you can get under
.../pages/BlogPg1/objects/
Well not exactly, you don't always have an object. A document can be
just about content. Just a wiki page if you prefer.
[
an added advantage:
I think we can make a ViewEngine to generate android View components
from
the above model. Since the objects in the page
carry rendering
descriptions.We can make a general model like a browser to
brows xwiki using generated the views. But the problem is some features
in
specific spaces like blog do not seem to be
totally defined by the XWiki
Object model behind them. Also this is just an idea (not suggesting I do
for the GSoc).Making it a usable reality is a little challenge.
]
So as you said if a document (I think it equivalent to a page) can have
many class types my assumption fails.
Why should a document be of multiple classes. I was thinking a page
belongs
to a class. And the page is an instance of that
class. If page can have
multiple classes my understanding should be wrong. Isn't it?
I don't understand, what I said is that you can only have one class in
a document but you can have several objects.
Thanks
Best Regards
Sasinda.
5:38 a.m.
New subject: [xwiki-devs] Fwd: [GSoc] XDroid Platform
hi,
Document API.
*create()*
put the page on server. If the doc includes Objects post them as well.
(likely for comments tags, attatchments)
*
*
*update(int strategy)*
Update all things in Page. Throw XWikiException if page not yet created.
@param : strategy values={MERGE / FORCED } OR {ALL/ OBJECTS / TAGS/...}
ex: thing there are objects 0,1,2 in server page.
- merge (when local doc has objects 0,1 only)
- update obj 0,1
- forced (whne local doc has obj 0,1 only)
- delete obj 2 in server. Update obj 0,1.
usage:
doc.update(MERGE || OBJECTS || TAGS) means update page,
merge objects and tags. Leave the rest as it is
*delete() *
delete the whole document.
*get()*
load the doc from server
*save()*
save to local device
*load()*
load from local device
Document API is not exposed directly to Client Developers. All it's methods
are protected.
We have a BlogDocument [extension to Document] which is exposed to the
BlogClient developer.
BlogDocument knows what a blog post is and it knows that it only needs to
update the BlogPostClass object in the server page. It calls the super
update() method with the relevant strategy.
Any way the Document is not the real guy who does all these updates to
server and local saves and loads.
For local saves and loads it calls a DAO(data Access Object ) in our
persistence lib.This DAO will call a FAO (File Access Object ) to save the
documents bulk to the local file system and enter a light weight entry in
the SQLite DataBase.
For updating the server, Document delegate duties to
ReSTfulDocumentAdapter{implements ReSTfulAdapter}.We can configure which
ReST model to use in the adapter (currently only simpleXML model). Adapters
convert and adapt the Document model to a rest model and call the XWikiReST
API abstraction layer to update the remote server.
By the way, those ReSTfulAdapter(s) do a lot of things. Convert Document to
REST model.Choose an Update Strategy object for the document (passed by
param in doc.update(strat)) Calls REST api abstraction inside android
according to the Update strategy. They do a lot of things for an adapter.I
don't know what to call it :-).An Adapter or something else ??? :-O.
Also for automatic syncs with the server when the device is offline and
user have made a blog post, user should be given the option to select
whether to automatically do it or manually post it.
For automatic sync/posting we can make android Services.
Also currently the xwiki-androi-rest module does not use android native
services to call server.If a user gets a phone call or something when
uploading to server things might get messy.This is because android
Activities are stoped and may be destroyed on these occasions.I will see if
I can rectify it if I have time after the mid eval.(It may totally affect
how web services are called from upper layers)
Thanks
Best Regards.
Sasinda.
On Fri, Jun 22, 2012 at 7:33 AM, sasinda rukshan
<sasindarukshan(a)gmail.com>wrote;wrote:
hi,
PS:
check the *p2 branch*. Not master. Did not merge yet. :-)
Regards,
Sasinda.
On Fri, Jun 22, 2012 at 7:31 AM, sasinda rukshan <sasindarukshan(a)gmail.com
wrote:
Hi,
Pushed some initial scaffolding's of XWiki model to android, in to
https://github.com/xwiki-contrib/android-client
This is the basic idea.
The client app developers will be only exposed to a service layer. All
packages suffixed with "Svc" have these.
package: cmnSvc >> has the LoginFacade. called to log in to server and
system.(also update state of XWikiContext in the android and etc)
package blogSvc >> will have BlogDocument, CategoryDocument and etc which
can be used to create posts and update server.
The base class Document will handle all server updations(through a
ReSTfulAdapter, to decouple Document and underlying rest model: simple
XML/Gson) and etc.
Please check whether approach to redesigning com.xpn....objects into
org.xwiki.android.xmodel.xobjects is correct.
Thanks.
Best Regards.
Sasinda.
On Mon, Jun 18, 2012 at 3:20 PM, sasinda rukshan <
sasindarukshan(a)gmail.com> wrote:
Hi Thomas,
---------- Forwarded message ----------
From: Thomas Mortagne <thomas.mortagne(a)xwiki.com>
Date: Mon, Jun 18, 2012 at 3:08 PM
Subject: Re: [xwiki-devs] Fwd: [GSoc] XDroid Platform
To: sasindarukshan(a)gmail.com, XWiki Developers <devs(a)xwiki.org>
On Mon, Jun 18, 2012 at 11:30 AM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
---------- Forwarded message ----------
From: sasinda rukshan <sasindarukshan(a)gmail.com>
Date: Mon, Jun 18, 2012 at 2:56 PM
Subject: Re: [xwiki-devs] [GSoc] XDroid Platform
To: XWiki Developers <devs(a)xwiki.org>
Hi Thomas,
Thanks for the explanations.
The methods toXML , toEmbedXML are wrong.It was just an idea that came
up
without much thinking. I will use a separate
model
converter.(xwikitTosimpleModelConverter implements ModelConverter like
thing). So the model objects don't know about it at all.
By what you ment by "user" I think it is the client app developer is
it?
Yes I mean the user of the API.
you did not mean end user. I never reveal the xml
representations to
end
users.
I came up with a simpler design. I will post diagram later tomorrow.
Ok, this ASCII art here is not very easy to read ;)
To give a brief on it,
XObject : has protected property List<XProperty>
A Map<XProperty> would probably make more sense here since each
property as a unique name in an object and you will need to set some
specific property very often.
|__XPoperty :<< all objects that can be
added as a property of an
objects
should extend this. Has an attribute list.
cancels the
| property list of XObject
| |_____XString :
|__Abstract XDocObject :<< all documents should have an object of
this.
This is the pages class. Has a object
List<XObject>
| |____XBlog :<< all documents which are blogs should
have a object of this. This determines the class of the object.
| but this data is not posted
anywhere in <link rel="...../class"> . It is just kept for type checks.
That is like
| this page should include
XBlogPost objects.
|__XBlogPost : <<the BlogPostClass object.
In my view I assume every page has an object of some class. And this
object
holds the objects which you can get under
.../pages/BlogPg1/objects/
Well not exactly, you don't always have an object. A document can be
just about content. Just a wiki page if you prefer.
[
an added advantage:
I think we can make a ViewEngine to generate android View components
from
the above model. Since the objects in the page
carry rendering
descriptions.We can make a general model like a browser to
brows xwiki using generated the views. But the problem is some
features in
specific spaces like blog do not seem to be
totally defined by the
XWiki
Object model behind them. Also this is just an
idea (not suggesting I
do
for the GSoc).Making it a usable reality is a
little challenge.
]
So as you said if a document (I think it equivalent to a page) can have
many class types my assumption fails.
Why should a document be of multiple classes. I was thinking a page
belongs
to a class. And the page is an instance of that
class. If page can have
multiple classes my understanding should be wrong. Isn't it?
I don't understand, what I said is that you can only have one class in
a document but you can have several objects.
Thanks
Best Regards
Sasinda.
23 Jun
23 Jun
6:56 a.m.
New subject: [xwiki-devs] Fwd: [GSoc] XDroid Platform
hi,
API update.
Document: create,retrieve,update,delete. (same as above)
We are using a ReSTful Manager and ReSTfulAccessObject[i.e. RAO<Document>
for accssing doc from server and all that.]. It is the Data Access Object
Pattern.This is to hide the underlying rest communication model.(i.e.
Jackson/Gson/SimpleXml...). Also this will apply a database like feeling
when accessing remote server ReSTful API. (this makes the architecture
simple and consistent also).
I did not see a method to querry all pages having a BlogPostClass object,
in the ReSTAPI documentation. Only possible way I found is to retrieve all
pages and there object summaries and find which pages have a BlogPostClass
in them.
I will add the querry method to an implementation of RAO<Space>.
It will be something like this.
class defs
interface RAO<T>{has a method querry()}
MYSpaceRAOImpl implements RAO<Space>
ReSTfulManager : Think that an instance of this is like a hibernate
session. Since this is a mobile env (and I am not that smart to implement
something like hibernate:-)
we get an RAO(same as a DataAccessObject)
from it rather than hiding everything behind it.
RAO<Space> spcRAO=ResTfulManager.getRAO(Space.class , fetchstrategy)
spcRAO.querry( all documents having a BlogPostClass object in them)
The SpaceRAO will handle the querying and return Document objects matching
the query. Actually this should return a list of Wrappers of Document
objects, to do things like lazy fetching from the RemoteXWiki Server.Since
time is limited, I will forget about wrappers and return back the whole
document, fully loaded.
I will implement a minimal functionality set in the above components. It is
very easy to evolve the feature set later because of the patterns applied.
Please give feedback on the idea.
Thanks
Best Regards.
Sasinda.
On Fri, Jun 22, 2012 at 9:08 AM, sasinda rukshan
<sasindarukshan(a)gmail.com>wrote;wrote:
hi,
Document API.
*create()*
put the page on server. If the doc includes Objects post them as well.
(likely for comments tags, attatchments)
*
*
*update(int strategy)*
Update all things in Page. Throw XWikiException if page not yet created.
@param : strategy values={MERGE / FORCED } OR {ALL/ OBJECTS / TAGS/...}
ex: thing there are objects 0,1,2 in server page.
- merge (when local doc has objects 0,1 only)
- update obj 0,1
- forced (whne local doc has obj 0,1 only)
- delete obj 2 in server. Update obj 0,1.
usage:
doc.update(MERGE || OBJECTS || TAGS) means update page,
merge objects and tags. Leave the rest as it is
*delete() *
delete the whole document.
*get()*
load the doc from server
*save()*
save to local device
*load()*
load from local device
Document API is not exposed directly to Client Developers. All it's
methods are protected.
We have a BlogDocument [extension to Document] which is exposed to the
BlogClient developer.
BlogDocument knows what a blog post is and it knows that it only needs to
update the BlogPostClass object in the server page. It calls the super
update() method with the relevant strategy.
Any way the Document is not the real guy who does all these updates to
server and local saves and loads.
For local saves and loads it calls a DAO(data Access Object ) in our
persistence lib.This DAO will call a FAO (File Access Object ) to save the
documents bulk to the local file system and enter a light weight entry in
the SQLite DataBase.
For updating the server, Document delegate duties to
ReSTfulDocumentAdapter{implements ReSTfulAdapter}.We can configure which
ReST model to use in the adapter (currently only simpleXML model). Adapters
convert and adapt the Document model to a rest model and call the XWikiReST
API abstraction layer to update the remote server.
By the way, those ReSTfulAdapter(s) do a lot of things. Convert Document
to REST model.Choose an Update Strategy object for the document (passed by
param in doc.update(strat)) Calls REST api abstraction inside android
according to the Update strategy. They do a lot of things for an adapter.I
don't know what to call it :-).An Adapter or something else ??? :-O.
Also for automatic syncs with the server when the device is offline and
user have made a blog post, user should be given the option to select
whether to automatically do it or manually post it.
For automatic sync/posting we can make android Services.
Also currently the xwiki-androi-rest module does not use android native
services to call server.If a user gets a phone call or something when
uploading to server things might get messy.This is because android
Activities are stoped and may be destroyed on these occasions.I will see if
I can rectify it if I have time after the mid eval.(It may totally affect
how web services are called from upper layers)
Thanks
Best Regards.
Sasinda.
On Fri, Jun 22, 2012 at 7:33 AM, sasinda rukshan <sasindarukshan(a)gmail.com
wrote:
hi,
PS:
check the *p2 branch*. Not master. Did not merge yet. :-)
Regards,
Sasinda.
On Fri, Jun 22, 2012 at 7:31 AM, sasinda rukshan <
sasindarukshan(a)gmail.com> wrote:
Hi,
Pushed some initial scaffolding's of XWiki model to android, in to
https://github.com/xwiki-contrib/android-client
This is the basic idea.
The client app developers will be only exposed to a service layer. All
packages suffixed with "Svc" have these.
package: cmnSvc >> has the LoginFacade. called to log in to server and
system.(also update state of XWikiContext in the android and etc)
package blogSvc >> will have BlogDocument, CategoryDocument and etc
which can be used to create posts and update server.
The base class Document will handle all server updations(through a
ReSTfulAdapter, to decouple Document and underlying rest model: simple
XML/Gson) and etc.
Please check whether approach to redesigning com.xpn....objects into
org.xwiki.android.xmodel.xobjects is correct.
Thanks.
Best Regards.
Sasinda.
On Mon, Jun 18, 2012 at 3:20 PM, sasinda rukshan <
sasindarukshan(a)gmail.com> wrote:
Hi Thomas,
---------- Forwarded message ----------
From: Thomas Mortagne <thomas.mortagne(a)xwiki.com>
Date: Mon, Jun 18, 2012 at 3:08 PM
Subject: Re: [xwiki-devs] Fwd: [GSoc] XDroid Platform
To: sasindarukshan(a)gmail.com, XWiki Developers <devs(a)xwiki.org>
On Mon, Jun 18, 2012 at 11:30 AM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
> ---------- Forwarded message ----------
> From: sasinda rukshan <sasindarukshan(a)gmail.com>
> Date: Mon, Jun 18, 2012 at 2:56 PM
> Subject: Re: [xwiki-devs] [GSoc] XDroid Platform
> To: XWiki Developers <devs(a)xwiki.org>
>
>
> Hi Thomas,
>
> Thanks for the explanations.
> The methods toXML , toEmbedXML are wrong.It was just an idea that
came up
> without much thinking. I will use a separate model
> converter.(xwikitTosimpleModelConverter implements ModelConverter like
> thing). So the model objects don't know about it at all.
> By what you ment by "user" I think it is the client app developer is
it?
Yes I mean the user of the API.
> you did not mean end user. I never reveal the xml representations to
end
> users.
>
> I came up with a simpler design. I will post diagram later tomorrow.
Ok, this ASCII art here is not very easy to read ;)
> To give a brief on it,
> XObject : has protected property List<XProperty>
A Map<XProperty> would probably make more sense here since each
property as a unique name in an object and you will need to set some
specific property very often.
> |__XPoperty :<< all objects that can be added as a property of an
objects
> should extend this. Has an attribute list. cancels the
> | property list of XObject
> | |_____XString :
> |__Abstract XDocObject :<< all documents should have an object of
this.
> This is the pages class. Has a object List<XObject>
> | |____XBlog :<< all documents which are blogs
should
> have a object of this. This determines the class of the object.
> | but this data is not posted
> anywhere in <link rel="...../class"> . It is just kept for type
checks.
> That is like
> | this page should include
> XBlogPost objects.
> |__XBlogPost : <<the BlogPostClass object.
>
> In my view I assume every page has an object of some class. And this
object
> holds the objects which you can get under .../pages/BlogPg1/objects/
Well not exactly, you don't always have an object. A document can be
just about content. Just a wiki page if you prefer.
>
> [
> an added advantage:
> I think we can make a ViewEngine to generate android View components
from
> the above model. Since the objects in the page carry rendering
> descriptions.We can make a general model like a browser to
> brows xwiki using generated the views. But the problem is some
features in
> specific spaces like blog do not seem to be totally defined by the
XWiki
> Object model behind them. Also this is just an idea (not suggesting I
do
> for the GSoc).Making it a usable reality is a little challenge.
> ]
>
> So as you said if a document (I think it equivalent to a page) can
have
> many class types my assumption fails.
> Why should a document be of multiple classes. I was thinking a page
belongs
> to a class. And the page is an instance of that class. If page can
have
> multiple classes my understanding should be wrong. Isn't it?
I don't understand, what I said is that you can only have one class in
a document but you can have several objects.
>
> Thanks
> Best Regards
> Sasinda.
>
>
>
>
7:10 a.m.
New subject: [xwiki-devs] Fwd: [GSoc] XDroid Platform
PS:
Forgot to mention,
Document API will have 2 additional methods.
activate()
passivate()
These are introduced to passivate the document when an Android Activity
shuts down if user is doing multi tasking.
For the rationale behind this, refer to
http://developer.android.com/guide/components/tasks-and-back-stack.html
Tasks and BackStack
http://developer.android.com/guide/components/activities.html
see, figure1:The Activity Lifecycle
passivate() will pass the Document object to an Android
Service which will persist document to the device.
I will do an incremental development.
1st increment: BlogDocument object will have functionality to send a
BlogPost. All lower layer functinality needed will be implemented.
2nd increment: Save the BlogDocument in the device drive.
Rest I have not planned.
Thanks
Best Regards.
Sasinda.
On Sat, Jun 23, 2012 at 10:26 AM, sasinda rukshan
<sasindarukshan(a)gmail.com>wrote;wrote:
hi,
API update.
Document: create,retrieve,update,delete. (same as above)
We are using a ReSTful Manager and ReSTfulAccessObject[i.e. RAO<Document>
for accssing doc from server and all that.]. It is the Data Access Object
Pattern.This is to hide the underlying rest communication model.(i.e.
Jackson/Gson/SimpleXml...). Also this will apply a database like feeling
when accessing remote server ReSTful API. (this makes the architecture
simple and consistent also).
I did not see a method to querry all pages having a BlogPostClass object,
in the ReSTAPI documentation. Only possible way I found is to retrieve all
pages and there object summaries and find which pages have a BlogPostClass
in them.
I will add the querry method to an implementation of RAO<Space>.
It will be something like this.
class defs
interface RAO<T>{has a method querry()}
MYSpaceRAOImpl implements RAO<Space>
ReSTfulManager : Think that an instance of this is like a hibernate
session. Since this is a mobile env (and I am not that smart to implement
something like hibernate:-)
we get an RAO(same as a DataAccessObject)
from it rather than hiding everything behind it.
RAO<Space> spcRAO=ResTfulManager.getRAO(Space.class , fetchstrategy)
spcRAO.querry( all documents having a BlogPostClass object in them)
The SpaceRAO will handle the querying and return Document objects matching
the query. Actually this should return a list of Wrappers of Document
objects, to do things like lazy fetching from the RemoteXWiki Server.Since
time is limited, I will forget about wrappers and return back the whole
document, fully loaded.
I will implement a minimal functionality set in the above components. It
is very easy to evolve the feature set later because of the patterns
applied.
Please give feedback on the idea.
Thanks
Best Regards.
Sasinda.
On Fri, Jun 22, 2012 at 9:08 AM, sasinda rukshan <sasindarukshan(a)gmail.com
wrote:
hi,
Document API.
*create()*
put the page on server. If the doc includes Objects post them as well.
(likely for comments tags, attatchments)
*
*
*update(int strategy)*
Update all things in Page. Throw XWikiException if page not yet created.
@param : strategy values={MERGE / FORCED } OR {ALL/ OBJECTS / TAGS/...}
ex: thing there are objects 0,1,2 in server page.
- merge (when local doc has objects 0,1 only)
- update obj 0,1
- forced (whne local doc has obj 0,1 only)
- delete obj 2 in server. Update obj 0,1.
usage:
doc.update(MERGE || OBJECTS || TAGS) means update page,
merge objects and tags. Leave the rest as it is
*delete() *
delete the whole document.
*get()*
load the doc from server
*save()*
save to local device
*load()*
load from local device
Document API is not exposed directly to Client Developers. All it's
methods are protected.
We have a BlogDocument [extension to Document] which is exposed to the
BlogClient developer.
BlogDocument knows what a blog post is and it knows that it only needs to
update the BlogPostClass object in the server page. It calls the super
update() method with the relevant strategy.
Any way the Document is not the real guy who does all these updates to
server and local saves and loads.
For local saves and loads it calls a DAO(data Access Object ) in our
persistence lib.This DAO will call a FAO (File Access Object ) to save the
documents bulk to the local file system and enter a light weight entry in
the SQLite DataBase.
For updating the server, Document delegate duties to
ReSTfulDocumentAdapter{implements ReSTfulAdapter}.We can configure which
ReST model to use in the adapter (currently only simpleXML model). Adapters
convert and adapt the Document model to a rest model and call the XWikiReST
API abstraction layer to update the remote server.
By the way, those ReSTfulAdapter(s) do a lot of things. Convert Document
to REST model.Choose an Update Strategy object for the document (passed by
param in doc.update(strat)) Calls REST api abstraction inside android
according to the Update strategy. They do a lot of things for an adapter.I
don't know what to call it :-).An Adapter or something else ??? :-O.
Also for automatic syncs with the server when the device is offline and
user have made a blog post, user should be given the option to select
whether to automatically do it or manually post it.
For automatic sync/posting we can make android Services.
Also currently the xwiki-androi-rest module does not use android native
services to call server.If a user gets a phone call or something when
uploading to server things might get messy.This is because android
Activities are stoped and may be destroyed on these occasions.I will see if
I can rectify it if I have time after the mid eval.(It may totally affect
how web services are called from upper layers)
Thanks
Best Regards.
Sasinda.
On Fri, Jun 22, 2012 at 7:33 AM, sasinda rukshan <
sasindarukshan(a)gmail.com> wrote:
hi,
PS:
check the *p2 branch*. Not master. Did not merge yet. :-)
Regards,
Sasinda.
On Fri, Jun 22, 2012 at 7:31 AM, sasinda rukshan <
sasindarukshan(a)gmail.com> wrote:
Hi,
Pushed some initial scaffolding's of XWiki model to android, in to
https://github.com/xwiki-contrib/android-client
This is the basic idea.
The client app developers will be only exposed to a service layer. All
packages suffixed with "Svc" have these.
package: cmnSvc >> has the LoginFacade. called to log in to server and
system.(also update state of XWikiContext in the android and etc)
package blogSvc >> will have BlogDocument, CategoryDocument and etc
which can be used to create posts and update server.
The base class Document will handle all server updations(through a
ReSTfulAdapter, to decouple Document and underlying rest model: simple
XML/Gson) and etc.
Please check whether approach to redesigning com.xpn....objects into
org.xwiki.android.xmodel.xobjects is correct.
Thanks.
Best Regards.
Sasinda.
On Mon, Jun 18, 2012 at 3:20 PM, sasinda rukshan <
sasindarukshan(a)gmail.com> wrote:
> Hi Thomas,
>
>
> ---------- Forwarded message ----------
> From: Thomas Mortagne <thomas.mortagne(a)xwiki.com>
> Date: Mon, Jun 18, 2012 at 3:08 PM
> Subject: Re: [xwiki-devs] Fwd: [GSoc] XDroid Platform
> To: sasindarukshan(a)gmail.com, XWiki Developers <devs(a)xwiki.org>
>
>
> On Mon, Jun 18, 2012 at 11:30 AM, sasinda rukshan
> <sasindarukshan(a)gmail.com> wrote:
> > ---------- Forwarded message ----------
> > From: sasinda rukshan <sasindarukshan(a)gmail.com>
> > Date: Mon, Jun 18, 2012 at 2:56 PM
> > Subject: Re: [xwiki-devs] [GSoc] XDroid Platform
> > To: XWiki Developers <devs(a)xwiki.org>
> >
> >
> > Hi Thomas,
> >
> > Thanks for the explanations.
> > The methods toXML , toEmbedXML are wrong.It was just an idea that
> came up
> > without much thinking. I will use a separate model
> > converter.(xwikitTosimpleModelConverter implements ModelConverter
> like
> > thing). So the model objects don't know about it at all.
> > By what you ment by "user" I think it is the client app developer is
> it?
>
> Yes I mean the user of the API.
>
> > you did not mean end user. I never reveal the xml representations to
> end
> > users.
> >
> > I came up with a simpler design. I will post diagram later tomorrow.
>
> Ok, this ASCII art here is not very easy to read ;)
>
> > To give a brief on it,
> > XObject : has protected property List<XProperty>
>
> A Map<XProperty> would probably make more sense here since each
> property as a unique name in an object and you will need to set some
> specific property very often.
>
> > |__XPoperty :<< all objects that can be added as a property of an
> objects
> > should extend this. Has an attribute list. cancels the
> > | property list of XObject
> > | |_____XString :
> > |__Abstract XDocObject :<< all documents should have an object of
> this.
> > This is the pages class. Has a object List<XObject>
> > | |____XBlog :<< all documents which are blogs
> should
> > have a object of this. This determines the class of the object.
> > | but this data is not
> posted
> > anywhere in <link rel="...../class"> . It is just kept for type
> checks.
> > That is like
> > | this page should include
> > XBlogPost objects.
> > |__XBlogPost : <<the BlogPostClass object.
> >
> > In my view I assume every page has an object of some class. And this
> object
> > holds the objects which you can get under .../pages/BlogPg1/objects/
>
> Well not exactly, you don't always have an object. A document can be
> just about content. Just a wiki page if you prefer.
>
> >
> > [
> > an added advantage:
> > I think we can make a ViewEngine to generate android View components
> from
> > the above model. Since the objects in the page carry rendering
> > descriptions.We can make a general model like a browser to
> > brows xwiki using generated the views. But the problem is some
> features in
> > specific spaces like blog do not seem to be totally defined by the
> XWiki
> > Object model behind them. Also this is just an idea (not suggesting
> I do
> > for the GSoc).Making it a usable reality is a little challenge.
> > ]
> >
> > So as you said if a document (I think it equivalent to a page) can
> have
> > many class types my assumption fails.
> > Why should a document be of multiple classes. I was thinking a page
> belongs
> > to a class. And the page is an instance of that class. If page can
> have
> > multiple classes my understanding should be wrong. Isn't it?
>
> I don't understand, what I said is that you can only have one class in
> a document but you can have several objects.
>
> >
> > Thanks
> > Best Regards
> > Sasinda.
> >
> >
> >
> >
>
24 Jun
24 Jun
10:17 a.m.
New subject: [xwiki-devs] Fwd: [GSoc] XDroid Platform
Hi ,
Updated current archi.
https://docs.google.com/drawings/d/1hwfQMVgCvYKS6iHU060drcET3Aq3Vles2DQlJOO…
Improved XWikiApplicationContext object. It is now used for IOC.
Also it is now integrated to android native runtime. All activities can now
call android native method "this.getApplication()" to receive a
XWikiApplicationContext.
https://github.com/xwiki-contrib/android-client/tree/p2
Thanks
Regards.
Thanks,
Best Regards.
On Sat, Jun 23, 2012 at 10:40 AM, sasinda rukshan
<sasindarukshan(a)gmail.com>wrote;wrote:
PS:
Forgot to mention,
Document API will have 2 additional methods.
activate()
passivate()
These are introduced to passivate the document when an Android Activity
shuts down if user is doing multi tasking.
For the rationale behind this, refer to
http://developer.android.com/guide/components/tasks-and-back-stack.html
Tasks and BackStack
http://developer.android.com/guide/components/activities.html
see, figure1:The Activity Lifecycle
passivate() will pass the Document object to an Android
Service which will persist document to the device.
I will do an incremental development.
1st increment: BlogDocument object will have functionality to send a
BlogPost. All lower layer functinality needed will be implemented.
2nd increment: Save the BlogDocument in the device drive.
Rest I have not planned.
Thanks
Best Regards.
Sasinda.
On Sat, Jun 23, 2012 at 10:26 AM, sasinda rukshan <
sasindarukshan(a)gmail.com> wrote:
hi,
API update.
Document: create,retrieve,update,delete. (same as above)
We are using a ReSTful Manager and ReSTfulAccessObject[i.e. RAO<Document>
for accssing doc from server and all that.]. It is the Data Access Object
Pattern.This is to hide the underlying rest communication model.(i.e.
Jackson/Gson/SimpleXml...). Also this will apply a database like feeling
when accessing remote server ReSTful API. (this makes the architecture
simple and consistent also).
I did not see a method to querry all pages having a BlogPostClass object,
in the ReSTAPI documentation. Only possible way I found is to retrieve all
pages and there object summaries and find which pages have a BlogPostClass
in them.
I will add the querry method to an implementation of RAO<Space>.
It will be something like this.
class defs
interface RAO<T>{has a method querry()}
MYSpaceRAOImpl implements RAO<Space>
ReSTfulManager : Think that an instance of this is like a hibernate
session. Since this is a mobile env (and I am not that smart to implement
something like hibernate:-)
we get an RAO(same as a DataAccessObject)
from it rather than hiding everything behind it.
RAO<Space> spcRAO=ResTfulManager.getRAO(Space.class , fetchstrategy)
spcRAO.querry( all documents having a BlogPostClass object in them)
The SpaceRAO will handle the querying and return Document objects
matching the query. Actually this should return a list of Wrappers of
Document objects, to do things like lazy fetching from the RemoteXWiki
Server.Since time is limited, I will forget about wrappers and return back
the whole document, fully loaded.
I will implement a minimal functionality set in the above components. It
is very easy to evolve the feature set later because of the patterns
applied.
Please give feedback on the idea.
Thanks
Best Regards.
Sasinda.
On Fri, Jun 22, 2012 at 9:08 AM, sasinda rukshan <
sasindarukshan(a)gmail.com> wrote:
hi,
Document API.
*create()*
put the page on server. If the doc includes Objects post them as well.
(likely for comments tags, attatchments)
*
*
*update(int strategy)*
Update all things in Page. Throw XWikiException if page not yet created.
@param : strategy values={MERGE / FORCED } OR {ALL/ OBJECTS /
TAGS/...}
ex: thing there are objects 0,1,2 in server page.
- merge (when local doc has objects 0,1 only)
- update obj 0,1
- forced (whne local doc has obj 0,1 only)
- delete obj 2 in server. Update obj 0,1.
usage:
doc.update(MERGE || OBJECTS || TAGS) means update page,
merge objects and tags. Leave the rest as it is
*delete() *
delete the whole document.
*get()*
load the doc from server
*save()*
save to local device
*load()*
load from local device
Document API is not exposed directly to Client Developers. All it's
methods are protected.
We have a BlogDocument [extension to Document] which is exposed to the
BlogClient developer.
BlogDocument knows what a blog post is and it knows that it only needs
to update the BlogPostClass object in the server page. It calls the super
update() method with the relevant strategy.
Any way the Document is not the real guy who does all these updates to
server and local saves and loads.
For local saves and loads it calls a DAO(data Access Object ) in our
persistence lib.This DAO will call a FAO (File Access Object ) to save the
documents bulk to the local file system and enter a light weight entry in
the SQLite DataBase.
For updating the server, Document delegate duties to
ReSTfulDocumentAdapter{implements ReSTfulAdapter}.We can configure which
ReST model to use in the adapter (currently only simpleXML model). Adapters
convert and adapt the Document model to a rest model and call the XWikiReST
API abstraction layer to update the remote server.
By the way, those ReSTfulAdapter(s) do a lot of things. Convert Document
to REST model.Choose an Update Strategy object for the document (passed by
param in doc.update(strat)) Calls REST api abstraction inside android
according to the Update strategy. They do a lot of things for an adapter.I
don't know what to call it :-).An Adapter or something else ??? :-O.
Also for automatic syncs with the server when the device is offline and
user have made a blog post, user should be given the option to select
whether to automatically do it or manually post it.
For automatic sync/posting we can make android Services.
Also currently the xwiki-androi-rest module does not use android native
services to call server.If a user gets a phone call or something when
uploading to server things might get messy.This is because android
Activities are stoped and may be destroyed on these occasions.I will see if
I can rectify it if I have time after the mid eval.(It may totally affect
how web services are called from upper layers)
Thanks
Best Regards.
Sasinda.
On Fri, Jun 22, 2012 at 7:33 AM, sasinda rukshan <
sasindarukshan(a)gmail.com> wrote:
hi,
PS:
check the *p2 branch*. Not master. Did not merge yet. :-)
Regards,
Sasinda.
On Fri, Jun 22, 2012 at 7:31 AM, sasinda rukshan <
sasindarukshan(a)gmail.com> wrote:
> Hi,
> Pushed some initial scaffolding's of XWiki model to android, in to
> https://github.com/xwiki-contrib/android-client
> This is the basic idea.
> The client app developers will be only exposed to a service layer. All
> packages suffixed with "Svc" have these.
> package: cmnSvc >> has the LoginFacade. called to log in to server and
> system.(also update state of XWikiContext in the android and etc)
> package blogSvc >> will have BlogDocument, CategoryDocument and etc
> which can be used to create posts and update server.
> The base class Document will handle all server updations(through a
> ReSTfulAdapter, to decouple Document and underlying rest model: simple
> XML/Gson) and etc.
>
> Please check whether approach to redesigning com.xpn....objects into
> org.xwiki.android.xmodel.xobjects is correct.
>
> Thanks.
> Best Regards.
> Sasinda.
>
>
>
>
> On Mon, Jun 18, 2012 at 3:20 PM, sasinda rukshan <
> sasindarukshan(a)gmail.com> wrote:
>
>> Hi Thomas,
>>
>>
>
>> ---------- Forwarded message ----------
>> From: Thomas Mortagne <thomas.mortagne(a)xwiki.com>
>> Date: Mon, Jun 18, 2012 at 3:08 PM
>> Subject: Re: [xwiki-devs] Fwd: [GSoc] XDroid Platform
>> To: sasindarukshan(a)gmail.com, XWiki Developers <devs(a)xwiki.org>
>>
>>
>> On Mon, Jun 18, 2012 at 11:30 AM, sasinda rukshan
>> <sasindarukshan(a)gmail.com> wrote:
>> > ---------- Forwarded message ----------
>> > From: sasinda rukshan <sasindarukshan(a)gmail.com>
>> > Date: Mon, Jun 18, 2012 at 2:56 PM
>> > Subject: Re: [xwiki-devs] [GSoc] XDroid Platform
>> > To: XWiki Developers <devs(a)xwiki.org>
>> >
>> >
>> > Hi Thomas,
>> >
>> > Thanks for the explanations.
>> > The methods toXML , toEmbedXML are wrong.It was just an idea that
>> came up
>> > without much thinking. I will use a separate model
>> > converter.(xwikitTosimpleModelConverter implements ModelConverter
>> like
>> > thing). So the model objects don't know about it at all.
>> > By what you ment by "user" I think it is the client app developer
>> is it?
>>
>> Yes I mean the user of the API.
>>
>> > you did not mean end user. I never reveal the xml representations
>> to end
>> > users.
>> >
>> > I came up with a simpler design. I will post diagram later tomorrow.
>>
>> Ok, this ASCII art here is not very easy to read ;)
>>
>> > To give a brief on it,
>> > XObject : has protected property List<XProperty>
>>
>> A Map<XProperty> would probably make more sense here since each
>> property as a unique name in an object and you will need to set some
>> specific property very often.
>>
>> > |__XPoperty :<< all objects that can be added as a property of an
>> objects
>> > should extend this. Has an attribute list. cancels the
>> > | property list of XObject
>> > | |_____XString :
>> > |__Abstract XDocObject :<< all documents should have an object of
>> this.
>> > This is the pages class. Has a object List<XObject>
>> > | |____XBlog :<< all documents which are blogs
>> should
>> > have a object of this. This determines the class of the object.
>> > | but this data is not
>> posted
>> > anywhere in <link rel="...../class"> . It is just kept for
type
>> checks.
>> > That is like
>> > | this page should include
>> > XBlogPost objects.
>> > |__XBlogPost : <<the BlogPostClass object.
>> >
>> > In my view I assume every page has an object of some class. And
>> this object
>> > holds the objects which you can get under .../pages/BlogPg1/objects/
>>
>> Well not exactly, you don't always have an object. A document can be
>> just about content. Just a wiki page if you prefer.
>>
>> >
>> > [
>> > an added advantage:
>> > I think we can make a ViewEngine to generate android View
>> components from
>> > the above model. Since the objects in the page carry rendering
>> > descriptions.We can make a general model like a browser to
>> > brows xwiki using generated the views. But the problem is some
>> features in
>> > specific spaces like blog do not seem to be totally defined by the
>> XWiki
>> > Object model behind them. Also this is just an idea (not suggesting
>> I do
>> > for the GSoc).Making it a usable reality is a little challenge.
>> > ]
>> >
>> > So as you said if a document (I think it equivalent to a page) can
>> have
>> > many class types my assumption fails.
>> > Why should a document be of multiple classes. I was thinking a page
>> belongs
>> > to a class. And the page is an instance of that class. If page can
>> have
>> > multiple classes my understanding should be wrong. Isn't it?
>>
>> I don't understand, what I said is that you can only have one class in
>> a document but you can have several objects.
>>
>> >
>> > Thanks
>> > Best Regards
>> > Sasinda.
>> >
>> >
>> >
>> >
>>
>
3 Jul
3 Jul
5:18 p.m.
New subject: [xwiki-devs] Fwd: [GSoc] XDroid Platform
Hi,
Looks like you merge your work on master which is great but is it
normal that the "p2" branch is still here ? Also I don't understand
what is the "tm" branch for.
On Sun, Jun 24, 2012 at 10:17 AM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
Hi ,
Updated current archi.
https://docs.google.com/drawings/d/1hwfQMVgCvYKS6iHU060drcET3Aq3Vles2DQlJOO…
Improved XWikiApplicationContext object. It is now used for IOC.
Also it is now integrated to android native runtime. All activities can now
call android native method "this.getApplication()" to receive a
XWikiApplicationContext.
https://github.com/xwiki-contrib/android-client/tree/p2
Thanks
Regards.
Thanks,
Best Regards.
On Sat, Jun 23, 2012 at 10:40 AM, sasinda rukshan
<sasindarukshan(a)gmail.com>wrote;wrote:
--
Thomas Mortagne
PS:
Forgot to mention,
Document API will have 2 additional methods.
activate()
passivate()
These are introduced to passivate the document when an Android Activity
shuts down if user is doing multi tasking.
For the rationale behind this, refer to
http://developer.android.com/guide/components/tasks-and-back-stack.html
Tasks and BackStack
http://developer.android.com/guide/components/activities.html
see, figure1:The Activity Lifecycle
passivate() will pass the Document object to an Android
Service which will persist document to the device.
I will do an incremental development.
1st increment: BlogDocument object will have functionality to send a
BlogPost. All lower layer functinality needed will be implemented.
2nd increment: Save the BlogDocument in the device drive.
Rest I have not planned.
Thanks
Best Regards.
Sasinda.
On Sat, Jun 23, 2012 at 10:26 AM, sasinda rukshan <
sasindarukshan(a)gmail.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs hi,
API update.
Document: create,retrieve,update,delete. (same as above)
We are using a ReSTful Manager and ReSTfulAccessObject[i.e. RAO<Document>
for accssing doc from server and all that.]. It is the Data Access Object
Pattern.This is to hide the underlying rest communication model.(i.e.
Jackson/Gson/SimpleXml...). Also this will apply a database like feeling
when accessing remote server ReSTful API. (this makes the architecture
simple and consistent also).
I did not see a method to querry all pages having a BlogPostClass object,
in the ReSTAPI documentation. Only possible way I found is to retrieve all
pages and there object summaries and find which pages have a BlogPostClass
in them.
I will add the querry method to an implementation of RAO<Space>.
It will be something like this.
class defs
interface RAO<T>{has a method querry()}
MYSpaceRAOImpl implements RAO<Space>
ReSTfulManager : Think that an instance of this is like a hibernate
session. Since this is a mobile env (and I am not that smart to implement
something like hibernate:-)
we get an RAO(same as a DataAccessObject)
from it rather than hiding everything behind it.
RAO<Space> spcRAO=ResTfulManager.getRAO(Space.class , fetchstrategy)
spcRAO.querry( all documents having a BlogPostClass object in them)
The SpaceRAO will handle the querying and return Document objects
matching the query. Actually this should return a list of Wrappers of
Document objects, to do things like lazy fetching from the RemoteXWiki
Server.Since time is limited, I will forget about wrappers and return back
the whole document, fully loaded.
I will implement a minimal functionality set in the above components. It
is very easy to evolve the feature set later because of the patterns
applied.
Please give feedback on the idea.
Thanks
Best Regards.
Sasinda.
On Fri, Jun 22, 2012 at 9:08 AM, sasinda rukshan <
sasindarukshan(a)gmail.com> wrote:
hi,
Document API.
*create()*
put the page on server. If the doc includes Objects post them as well.
(likely for comments tags, attatchments)
*
*
*update(int strategy)*
Update all things in Page. Throw XWikiException if page not yet created.
@param : strategy values={MERGE / FORCED } OR {ALL/ OBJECTS /
TAGS/...}
ex: thing there are objects 0,1,2 in server page.
- merge (when local doc has objects 0,1 only)
- update obj 0,1
- forced (whne local doc has obj 0,1 only)
- delete obj 2 in server. Update obj 0,1.
usage:
doc.update(MERGE || OBJECTS || TAGS) means update page,
merge objects and tags. Leave the rest as it is
*delete() *
delete the whole document.
*get()*
load the doc from server
*save()*
save to local device
*load()*
load from local device
Document API is not exposed directly to Client Developers. All it's
methods are protected.
We have a BlogDocument [extension to Document] which is exposed to the
BlogClient developer.
BlogDocument knows what a blog post is and it knows that it only needs
to update the BlogPostClass object in the server page. It calls the super
update() method with the relevant strategy.
Any way the Document is not the real guy who does all these updates to
server and local saves and loads.
For local saves and loads it calls a DAO(data Access Object ) in our
persistence lib.This DAO will call a FAO (File Access Object ) to save the
documents bulk to the local file system and enter a light weight entry in
the SQLite DataBase.
For updating the server, Document delegate duties to
ReSTfulDocumentAdapter{implements ReSTfulAdapter}.We can configure which
ReST model to use in the adapter (currently only simpleXML model). Adapters
convert and adapt the Document model to a rest model and call the XWikiReST
API abstraction layer to update the remote server.
By the way, those ReSTfulAdapter(s) do a lot of things. Convert Document
to REST model.Choose an Update Strategy object for the document (passed by
param in doc.update(strat)) Calls REST api abstraction inside android
according to the Update strategy. They do a lot of things for an adapter.I
don't know what to call it :-).An Adapter or something else ??? :-O.
Also for automatic syncs with the server when the device is offline and
user have made a blog post, user should be given the option to select
whether to automatically do it or manually post it.
For automatic sync/posting we can make android Services.
Also currently the xwiki-androi-rest module does not use android native
services to call server.If a user gets a phone call or something when
uploading to server things might get messy.This is because android
Activities are stoped and may be destroyed on these occasions.I will see if
I can rectify it if I have time after the mid eval.(It may totally affect
how web services are called from upper layers)
Thanks
Best Regards.
Sasinda.
On Fri, Jun 22, 2012 at 7:33 AM, sasinda rukshan <
sasindarukshan(a)gmail.com> wrote:
> hi,
> PS:
> check the *p2 branch*. Not master. Did not merge yet. :-)
>
> Regards,
> Sasinda.
>
> On Fri, Jun 22, 2012 at 7:31 AM, sasinda rukshan <
> sasindarukshan(a)gmail.com> wrote:
>
>> Hi,
>> Pushed some initial scaffolding's of XWiki model to android, in to
>> https://github.com/xwiki-contrib/android-client
>> This is the basic idea.
>> The client app developers will be only exposed to a service layer. All
>> packages suffixed with "Svc" have these.
>> package: cmnSvc >> has the LoginFacade. called to log in to server and
>> system.(also update state of XWikiContext in the android and etc)
>> package blogSvc >> will have BlogDocument, CategoryDocument and etc
>> which can be used to create posts and update server.
>> The base class Document will handle all server updations(through a
>> ReSTfulAdapter, to decouple Document and underlying rest model: simple
>> XML/Gson) and etc.
>>
>> Please check whether approach to redesigning com.xpn....objects into
>> org.xwiki.android.xmodel.xobjects is correct.
>>
>> Thanks.
>> Best Regards.
>> Sasinda.
>>
>>
>>
>>
>> On Mon, Jun 18, 2012 at 3:20 PM, sasinda rukshan <
>> sasindarukshan(a)gmail.com> wrote:
>>
>>> Hi Thomas,
>>>
>>>
>>
>>> ---------- Forwarded message ----------
>>> From: Thomas Mortagne <thomas.mortagne(a)xwiki.com>
>>> Date: Mon, Jun 18, 2012 at 3:08 PM
>>> Subject: Re: [xwiki-devs] Fwd: [GSoc] XDroid Platform
>>> To: sasindarukshan(a)gmail.com, XWiki Developers <devs(a)xwiki.org>
>>>
>>>
>>> On Mon, Jun 18, 2012 at 11:30 AM, sasinda rukshan
>>> <sasindarukshan(a)gmail.com> wrote:
>>> > ---------- Forwarded message ----------
>>> > From: sasinda rukshan <sasindarukshan(a)gmail.com>
>>> > Date: Mon, Jun 18, 2012 at 2:56 PM
>>> > Subject: Re: [xwiki-devs] [GSoc] XDroid Platform
>>> > To: XWiki Developers <devs(a)xwiki.org>
>>> >
>>> >
>>> > Hi Thomas,
>>> >
>>> > Thanks for the explanations.
>>> > The methods toXML , toEmbedXML are wrong.It was just an idea that
>>> came up
>>> > without much thinking. I will use a separate model
>>> > converter.(xwikitTosimpleModelConverter implements ModelConverter
>>> like
>>> > thing). So the model objects don't know about it at all.
>>> > By what you ment by "user" I think it is the client app
developer
>>> is it?
>>>
>>> Yes I mean the user of the API.
>>>
>>> > you did not mean end user. I never reveal the xml representations
>>> to end
>>> > users.
>>> >
>>> > I came up with a simpler design. I will post diagram later tomorrow.
>>>
>>> Ok, this ASCII art here is not very easy to read ;)
>>>
>>> > To give a brief on it,
>>> > XObject : has protected property List<XProperty>
>>>
>>> A Map<XProperty> would probably make more sense here since each
>>> property as a unique name in an object and you will need to set some
>>> specific property very often.
>>>
>>> > |__XPoperty :<< all objects that can be added as a property of
an
>>> objects
>>> > should extend this. Has an attribute list. cancels the
>>> > | property list of XObject
>>> > | |_____XString :
>>> > |__Abstract XDocObject :<< all documents should have an object
of
>>> this.
>>> > This is the pages class. Has a object List<XObject>
>>> > | |____XBlog :<< all documents which are blogs
>>> should
>>> > have a object of this. This determines the class of the object.
>>> > | but this data is not
>>> posted
>>> > anywhere in <link rel="...../class"> . It is just kept
for type
>>> checks.
>>> > That is like
>>> > | this page should include
>>> > XBlogPost objects.
>>> > |__XBlogPost : <<the BlogPostClass object.
>>> >
>>> > In my view I assume every page has an object of some class. And
>>> this object
>>> > holds the objects which you can get under .../pages/BlogPg1/objects/
>>>
>>> Well not exactly, you don't always have an object. A document can be
>>> just about content. Just a wiki page if you prefer.
>>>
>>> >
>>> > [
>>> > an added advantage:
>>> > I think we can make a ViewEngine to generate android View
>>> components from
>>> > the above model. Since the objects in the page carry rendering
>>> > descriptions.We can make a general model like a browser to
>>> > brows xwiki using generated the views. But the problem is some
>>> features in
>>> > specific spaces like blog do not seem to be totally defined by the
>>> XWiki
>>> > Object model behind them. Also this is just an idea (not suggesting
>>> I do
>>> > for the GSoc).Making it a usable reality is a little challenge.
>>> > ]
>>> >
>>> > So as you said if a document (I think it equivalent to a page) can
>>> have
>>> > many class types my assumption fails.
>>> > Why should a document be of multiple classes. I was thinking a page
>>> belongs
>>> > to a class. And the page is an instance of that class. If page can
>>> have
>>> > multiple classes my understanding should be wrong. Isn't it?
>>>
>>> I don't understand, what I said is that you can only have one class in
>>> a document but you can have several objects.
>>>
>>> >
>>> > Thanks
>>> > Best Regards
>>> > Sasinda.
>>> >
>>> >
>>> >
>>> >
>>>
>>
>
5:19 p.m.
New subject: [xwiki-devs] Fwd: [GSoc] XDroid Platform
Note that it would be nice to update
https://github.com/xwiki-contrib/android-client/blob/master/README
with new stuff.
On Tue, Jul 3, 2012 at 5:18 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi,
Looks like you merge your work on master which is great but is it
normal that the "p2" branch is still here ? Also I don't understand
what is the "tm" branch for.
On Sun, Jun 24, 2012 at 10:17 AM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
--
Thomas Mortagne
Hi ,
Updated current archi.
https://docs.google.com/drawings/d/1hwfQMVgCvYKS6iHU060drcET3Aq3Vles2DQlJOO…
Improved XWikiApplicationContext object. It is now used for IOC.
Also it is now integrated to android native runtime. All activities can now
call android native method "this.getApplication()" to receive a
XWikiApplicationContext.
https://github.com/xwiki-contrib/android-client/tree/p2
Thanks
Regards.
Thanks,
Best Regards.
On Sat, Jun 23, 2012 at 10:40 AM, sasinda rukshan
<sasindarukshan(a)gmail.com>wrote;wrote:
--
Thomas Mortagne PS:
Forgot to mention,
Document API will have 2 additional methods.
activate()
passivate()
These are introduced to passivate the document when an Android Activity
shuts down if user is doing multi tasking.
For the rationale behind this, refer to
http://developer.android.com/guide/components/tasks-and-back-stack.html
Tasks and BackStack
http://developer.android.com/guide/components/activities.html
see, figure1:The Activity Lifecycle
passivate() will pass the Document object to an Android
Service which will persist document to the device.
I will do an incremental development.
1st increment: BlogDocument object will have functionality to send a
BlogPost. All lower layer functinality needed will be implemented.
2nd increment: Save the BlogDocument in the device drive.
Rest I have not planned.
Thanks
Best Regards.
Sasinda.
On Sat, Jun 23, 2012 at 10:26 AM, sasinda rukshan <
sasindarukshan(a)gmail.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs hi,
API update.
Document: create,retrieve,update,delete. (same as above)
We are using a ReSTful Manager and ReSTfulAccessObject[i.e. RAO<Document>
for accssing doc from server and all that.]. It is the Data Access Object
Pattern.This is to hide the underlying rest communication model.(i.e.
Jackson/Gson/SimpleXml...). Also this will apply a database like feeling
when accessing remote server ReSTful API. (this makes the architecture
simple and consistent also).
I did not see a method to querry all pages having a BlogPostClass object,
in the ReSTAPI documentation. Only possible way I found is to retrieve all
pages and there object summaries and find which pages have a BlogPostClass
in them.
I will add the querry method to an implementation of RAO<Space>.
It will be something like this.
class defs
interface RAO<T>{has a method querry()}
MYSpaceRAOImpl implements RAO<Space>
ReSTfulManager : Think that an instance of this is like a hibernate
session. Since this is a mobile env (and I am not that smart to implement
something like hibernate:-)
we get an RAO(same as a DataAccessObject)
from it rather than hiding everything behind it.
RAO<Space> spcRAO=ResTfulManager.getRAO(Space.class , fetchstrategy)
spcRAO.querry( all documents having a BlogPostClass object in them)
The SpaceRAO will handle the querying and return Document objects
matching the query. Actually this should return a list of Wrappers of
Document objects, to do things like lazy fetching from the RemoteXWiki
Server.Since time is limited, I will forget about wrappers and return back
the whole document, fully loaded.
I will implement a minimal functionality set in the above components. It
is very easy to evolve the feature set later because of the patterns
applied.
Please give feedback on the idea.
Thanks
Best Regards.
Sasinda.
On Fri, Jun 22, 2012 at 9:08 AM, sasinda rukshan <
sasindarukshan(a)gmail.com> wrote:
> hi,
> Document API.
>
> *create()*
> put the page on server. If the doc includes Objects post them as well.
> (likely for comments tags, attatchments)
> *
> *
> *update(int strategy)*
> Update all things in Page. Throw XWikiException if page not yet created.
> @param : strategy values={MERGE / FORCED } OR {ALL/ OBJECTS /
> TAGS/...}
> ex: thing there are objects 0,1,2 in server page.
>
> - merge (when local doc has objects 0,1 only)
> - update obj 0,1
> - forced (whne local doc has obj 0,1 only)
> - delete obj 2 in server. Update obj 0,1.
>
> usage:
> doc.update(MERGE || OBJECTS || TAGS) means update page,
> merge objects and tags. Leave the rest as it is
>
>
> *delete() *
> delete the whole document.
>
> *get()*
> load the doc from server
>
> *save()*
> save to local device
> *load()*
> load from local device
>
> Document API is not exposed directly to Client Developers. All it's
> methods are protected.
> We have a BlogDocument [extension to Document] which is exposed to the
> BlogClient developer.
> BlogDocument knows what a blog post is and it knows that it only needs
> to update the BlogPostClass object in the server page. It calls the super
> update() method with the relevant strategy.
> Any way the Document is not the real guy who does all these updates to
> server and local saves and loads.
> For local saves and loads it calls a DAO(data Access Object ) in our
> persistence lib.This DAO will call a FAO (File Access Object ) to save the
> documents bulk to the local file system and enter a light weight entry in
> the SQLite DataBase.
> For updating the server, Document delegate duties to
> ReSTfulDocumentAdapter{implements ReSTfulAdapter}.We can configure which
> ReST model to use in the adapter (currently only simpleXML model). Adapters
> convert and adapt the Document model to a rest model and call the XWikiReST
> API abstraction layer to update the remote server.
> By the way, those ReSTfulAdapter(s) do a lot of things. Convert Document
> to REST model.Choose an Update Strategy object for the document (passed by
> param in doc.update(strat)) Calls REST api abstraction inside android
> according to the Update strategy. They do a lot of things for an adapter.I
> don't know what to call it :-).An Adapter or something else ??? :-O.
>
> Also for automatic syncs with the server when the device is offline and
> user have made a blog post, user should be given the option to select
> whether to automatically do it or manually post it.
> For automatic sync/posting we can make android Services.
>
> Also currently the xwiki-androi-rest module does not use android native
> services to call server.If a user gets a phone call or something when
> uploading to server things might get messy.This is because android
> Activities are stoped and may be destroyed on these occasions.I will see if
> I can rectify it if I have time after the mid eval.(It may totally affect
> how web services are called from upper layers)
>
> Thanks
> Best Regards.
> Sasinda.
>
>
>
>
>
>
>
> On Fri, Jun 22, 2012 at 7:33 AM, sasinda rukshan <
> sasindarukshan(a)gmail.com> wrote:
>
>> hi,
>> PS:
>> check the *p2 branch*. Not master. Did not merge yet. :-)
>>
>> Regards,
>> Sasinda.
>>
>> On Fri, Jun 22, 2012 at 7:31 AM, sasinda rukshan <
>> sasindarukshan(a)gmail.com> wrote:
>>
>>> Hi,
>>> Pushed some initial scaffolding's of XWiki model to android, in to
>>> https://github.com/xwiki-contrib/android-client
>>> This is the basic idea.
>>> The client app developers will be only exposed to a service layer. All
>>> packages suffixed with "Svc" have these.
>>> package: cmnSvc >> has the LoginFacade. called to log in to server and
>>> system.(also update state of XWikiContext in the android and etc)
>>> package blogSvc >> will have BlogDocument, CategoryDocument and etc
>>> which can be used to create posts and update server.
>>> The base class Document will handle all server updations(through a
>>> ReSTfulAdapter, to decouple Document and underlying rest model: simple
>>> XML/Gson) and etc.
>>>
>>> Please check whether approach to redesigning com.xpn....objects into
>>> org.xwiki.android.xmodel.xobjects is correct.
>>>
>>> Thanks.
>>> Best Regards.
>>> Sasinda.
>>>
>>>
>>>
>>>
>>> On Mon, Jun 18, 2012 at 3:20 PM, sasinda rukshan <
>>> sasindarukshan(a)gmail.com> wrote:
>>>
>>>> Hi Thomas,
>>>>
>>>>
>>>
>>>> ---------- Forwarded message ----------
>>>> From: Thomas Mortagne <thomas.mortagne(a)xwiki.com>
>>>> Date: Mon, Jun 18, 2012 at 3:08 PM
>>>> Subject: Re: [xwiki-devs] Fwd: [GSoc] XDroid Platform
>>>> To: sasindarukshan(a)gmail.com, XWiki Developers <devs(a)xwiki.org>
>>>>
>>>>
>>>> On Mon, Jun 18, 2012 at 11:30 AM, sasinda rukshan
>>>> <sasindarukshan(a)gmail.com> wrote:
>>>> > ---------- Forwarded message ----------
>>>> > From: sasinda rukshan <sasindarukshan(a)gmail.com>
>>>> > Date: Mon, Jun 18, 2012 at 2:56 PM
>>>> > Subject: Re: [xwiki-devs] [GSoc] XDroid Platform
>>>> > To: XWiki Developers <devs(a)xwiki.org>
>>>> >
>>>> >
>>>> > Hi Thomas,
>>>> >
>>>> > Thanks for the explanations.
>>>> > The methods toXML , toEmbedXML are wrong.It was just an idea that
>>>> came up
>>>> > without much thinking. I will use a separate model
>>>> > converter.(xwikitTosimpleModelConverter implements ModelConverter
>>>> like
>>>> > thing). So the model objects don't know about it at all.
>>>> > By what you ment by "user" I think it is the client app
developer
>>>> is it?
>>>>
>>>> Yes I mean the user of the API.
>>>>
>>>> > you did not mean end user. I never reveal the xml representations
>>>> to end
>>>> > users.
>>>> >
>>>> > I came up with a simpler design. I will post diagram later
tomorrow.
>>>>
>>>> Ok, this ASCII art here is not very easy to read ;)
>>>>
>>>> > To give a brief on it,
>>>> > XObject : has protected property List<XProperty>
>>>>
>>>> A Map<XProperty> would probably make more sense here since each
>>>> property as a unique name in an object and you will need to set some
>>>> specific property very often.
>>>>
>>>> > |__XPoperty :<< all objects that can be added as a property
of an
>>>> objects
>>>> > should extend this. Has an attribute list. cancels the
>>>> > | property list of XObject
>>>> > | |_____XString :
>>>> > |__Abstract XDocObject :<< all documents should have an
object of
>>>> this.
>>>> > This is the pages class. Has a object List<XObject>
>>>> > | |____XBlog :<< all documents which are
blogs
>>>> should
>>>> > have a object of this. This determines the class of the object.
>>>> > | but this data is not
>>>> posted
>>>> > anywhere in <link rel="...../class"> . It is just
kept for type
>>>> checks.
>>>> > That is like
>>>> > | this page should include
>>>> > XBlogPost objects.
>>>> > |__XBlogPost : <<the BlogPostClass object.
>>>> >
>>>> > In my view I assume every page has an object of some class. And
>>>> this object
>>>> > holds the objects which you can get under
.../pages/BlogPg1/objects/
>>>>
>>>> Well not exactly, you don't always have an object. A document can be
>>>> just about content. Just a wiki page if you prefer.
>>>>
>>>> >
>>>> > [
>>>> > an added advantage:
>>>> > I think we can make a ViewEngine to generate android View
>>>> components from
>>>> > the above model. Since the objects in the page carry rendering
>>>> > descriptions.We can make a general model like a browser to
>>>> > brows xwiki using generated the views. But the problem is some
>>>> features in
>>>> > specific spaces like blog do not seem to be totally defined by the
>>>> XWiki
>>>> > Object model behind them. Also this is just an idea (not suggesting
>>>> I do
>>>> > for the GSoc).Making it a usable reality is a little challenge.
>>>> > ]
>>>> >
>>>> > So as you said if a document (I think it equivalent to a page) can
>>>> have
>>>> > many class types my assumption fails.
>>>> > Why should a document be of multiple classes. I was thinking a page
>>>> belongs
>>>> > to a class. And the page is an instance of that class. If page can
>>>> have
>>>> > multiple classes my understanding should be wrong. Isn't it?
>>>>
>>>> I don't understand, what I said is that you can only have one class
in
>>>> a document but you can have several objects.
>>>>
>>>> >
>>>> > Thanks
>>>> > Best Regards
>>>> > Sasinda.
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>
>>
>
4511
days inactive
4526
days old
10 comments
2 participants
participants (2)
-
sasinda rukshan -
Thomas Mortagne