12 Sep
2012
12 Sep
'12
11:47 p.m.
hello fellow developers,
at Curriki, we are starting to process XWiki objects in the background using subclasses of
AbstractXWikiRunnable.
Currently I do the following:
// setup
XWikiContext xcontext = (XWikiContext)
Utils.getComponent(Execution.class).getContext()
.getProperty(XWikiContext.EXECUTIONCONTEXT_KEY);
Context context = new Context(xcontext);
XWiki xwiki = new com.xpn.xwiki.api.XWiki(context.getXWiki(), xcontext);
// fetch background info
Document d = xwiki.getDocument(DOCNAME_x);
Object obj = d.getObject("DOCNAME_class");
// modify something
// save
d.save("comment");
However, I wonder if this is the best practice:
- is it expensive to construct a context and xwiki supposing this setup code is run
multiple times?
- is it preferrable to work with the com.xpn.xwiki.* classes?
- is DocReference behaving much differently than fullName if we have a single wiki?
Thanks in advance.
Paul
13 Sep
13 Sep
12:14 a.m.
Hi Paul,
On 09/12/2012 11:47 PM, Paul Libbrecht wrote:
hello fellow developers,
at Curriki, we are starting to process XWiki objects in the background using subclasses
of AbstractXWikiRunnable.
Currently I do the following:
// setup
XWikiContext xcontext = (XWikiContext)
Utils.getComponent(Execution.class).getContext()
.getProperty(XWikiContext.EXECUTIONCONTEXT_KEY);
Context context = new Context(xcontext);
XWiki xwiki = new com.xpn.xwiki.api.XWiki(context.getXWiki(),
xcontext);
// fetch background info
Document d = xwiki.getDocument(DOCNAME_x);
Object obj = d.getObject("DOCNAME_class");
// modify something
// save
d.save("comment");
However, I wonder if this is the best practice:
- is it expensive to construct a context and xwiki supposing this setup code is run
multiple times?
As far as I know there is not much overhead to construct the api wrapper.
- is it preferrable to work with the com.xpn.xwiki.*
classes?
Now I tend to prefer working as much as possible with api.* classes
rather than internal classes, for no specific reason other than the fact
they are proper APIs vs. de facto APIs and that I'm sure I have the same
behavior as when writing scripts.
- is DocReference behaving much differently than
fullName if we have a single wiki?
Yes in the sense it handles escaping properly. It matters if you don't
have control over document names, it matters less if you do have this
control (for example you generate the name automatically or clean user
input with defined rules). I try to use the reference (a.k.a new model)
API as often as possible, but I admit sometimes it feels just too much
when you know you're not having escaping issues or multiwiki issues.
Those times I do things like xwiki.getDocument("XWiki.XWikiPreferences")
and just live with it happily :)
Of course I'm speaking about my experience of using XWiki for my own
needs as an API consumer, not about the development of the XWiki platform.
That was my 2 cents, hope it helped having perspective on what others do,
Jerome
Thanks in advance.
Paul
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Peace,
—Jerome
9:15 a.m.
On Thu, Sep 13, 2012 at 12:14 AM, Jerome Velociter <jerome(a)velociter.fr> wrote:
Not by creating the API wrapper itself but keep in mind that every
time you call some of the script API methods (like save and
getDocument in your example) you will have a right test behind the
scene for many of them.
Hi Paul,
On 09/12/2012 11:47 PM, Paul Libbrecht wrote:
>
> hello fellow developers,
>
> at Curriki, we are starting to process XWiki objects in the background
> using subclasses of AbstractXWikiRunnable.
>
> Currently I do the following:
>
> // setup
> XWikiContext xcontext = (XWikiContext)
> Utils.getComponent(Execution.class).getContext()
> .getProperty(XWikiContext.EXECUTIONCONTEXT_KEY);
> Context context = new Context(xcontext);
> XWiki xwiki = new
> com.xpn.xwiki.api.XWiki(context.getXWiki(), xcontext);
>
> // fetch background info
> Document d = xwiki.getDocument(DOCNAME_x);
>
> Object obj = d.getObject("DOCNAME_class");
> // modify something
>
> // save
> d.save("comment");
>
> However, I wonder if this is the best practice:
There is no official best practice actually so it's going to be my
personal point of view.
- is it expensive to construct a context and xwiki supposing this setup
code is run multiple times?
As far as I know there is not much overhead to construct the api wrapper.
> - is it preferrable to work with the com.xpn.xwiki.* classes?
IMO it mostly depends if you want right test or not. For example in
your example your save will not work if whatever user you have in your
context does not have edit right on that document (same thing with
getDocument and view right). Sometimes that's exactly what you want
(we use the public API a lot in the REST resources for example) and
sometime it's a daemon thread which doesn't care about rights.
If you are in a Java code where you know you can do everything and
don't care about the rights you should use the com.xpn.xwiki.*
classes. Those class have the same level of retro compatibility than
the api.* classes so that should not be an issue.
Now I tend to prefer working as much as possible with api.* classes rather
than internal classes, for no specific reason other than the fact they are
proper APIs vs. de facto APIs and that I'm sure I have the same behavior as
when writing scripts.
Not much to add here but I think I'm using document reference way more
than Jerome even wen I "control the name" ;)
When you do xwiki.getDocument("XWiki.XWikiPreferences") a resolver is
called to parse ir and resolve the current wiki to create the
DocumentReference so it's better to create a DocumentReference
directly when you know all the three parts.
- is DocReference behaving much differently than
fullName if we have a
single wiki?
Yes in the sense it handles escaping properly. It matters if you don't have
control over document names, it matters less if you do have this control
(for example you generate the name automatically or clean user input with
defined rules). I try to use the reference (a.k.a new model) API as often as
possible, but I admit sometimes it feels just too much when you know you're
not having escaping issues or multiwiki issues. Those times I do things like
xwiki.getDocument("XWiki.XWikiPreferences") and just live with it happily :)
Of course I'm speaking about my experience of using XWiki for my own needs
as an API consumer, not about the development of the XWiki platform.
That was my 2 cents, hope it helped having perspective on what others do,
Jerome
--
Thomas Mortagne
Thanks in advance.
Paul
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Peace,
—Jerome
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:59 a.m.
Thanks for sharing Thomas and Jérôme,
That's already good (and good to know).
Not by creating the API wrapper itself but keep in mind that every
time you call some of the script API methods (like save and
getDocument in your example) you will have a right test behind the
scene for many of them.
This is a very important point.
Is there no way to still have the API luxury and disable rights' check?
If no, then indeed, it would be useful to migrate to the base classes but they seem to be
harder to work with.
Not much to add here but I think I'm using document reference way more
than Jerome even wen I "control the name" ;)
When you do xwiki.getDocument("XWiki.XWikiPreferences") a resolver is
called to parse ir and resolve the current wiki to create the
DocumentReference so it's better to create a DocumentReference
directly when you know all the three parts.
So here's a simple question: how do you simply create a document reference with a
String?
I think the area of working with the base class is where I miss a tutorial.
paul
> However, I
wonder if this is the best practice:
There is no official best practice actually so
it's going to be my
personal point of view. - is it expensive to construct a context and xwiki
supposing this setup
code is run multiple times?
As far as I know there is not much overhead to
construct the api wrapper. If you are in a Java code where you know you can do
everything and
don't care about the rights you should use the com.xpn.xwiki.*
classes. Those class have the same level of retro compatibility than
the api.* classes so that should not be an issue.
I could attempt this but I had a much harder time to do that.
- is DocReference behaving much differently than
fullName if we have a
single wiki?
Yes in the sense it handles escaping properly. It matters if you don't have
control over document names, it matters less if you do have this control
(for example you generate the name automatically or clean user input with
defined rules). I try to use the reference (a.k.a new model) API as often as
possible, but I admit sometimes it feels just too much when you know you're
not having escaping issues or multiwiki issues. Those times I do things like
xwiki.getDocument("XWiki.XWikiPreferences") and just live with it happily :)
Of course I'm speaking about my experience of using XWiki for my own needs
as an API consumer, not about the development of the XWiki platform.
12:47 p.m.
On Thu, Sep 13, 2012 at 11:59 AM, Paul Libbrecht <paul(a)hoplahup.net> wrote:
Not much to add here but I think I'm using document reference way more
than Jerome even wen I "control the name" ;)
When you do xwiki.getDocument("XWiki.XWikiPreferences") a resolver is
called to parse ir and resolve the current wiki to create the
DocumentReference so it's better to create a DocumentReference
directly when you know all the three parts.
So here's a simple question: how do you simply create a document reference with a
String?
I think the area of working with the base class is where I miss a tutorial.
See http://extensions.xwiki.org/xwiki/bin/view/Extension/Model+Module
for details and examples about references in general.
Now it depends on what is your input exactly, if what you get from the
user is the actual full name of the document as String then you will
not add much value when converting it on you side before calling
getDocument obviously.
Thanks for sharing Thomas and Jérôme,
That's already good (and good to know).
Not by creating the API wrapper itself but keep in mind that every
time you call some of the script API methods (like save and
getDocument in your example) you will have a right test behind the
scene for many of them.
This is a very important point.
Is there no way to still have the API luxury and disable rights' check?
If no, then indeed, it would be useful to migrate to the base classes but they seem to be
harder to work with.
Well I don't find the java API much more complex than the script API,
its pretty much the same things. The main differences are:
* you have to pass the context in most of the methods
* you save a document by doing xwiki.save(document) instead of document.save()
If you look at the api.* classes implementations you can see that most
of the methods just call the same methods and add context as parameter
(and sometimes not even).
>
However, I wonder if this is the best practice:
There is no official best practice
actually so it's going to be my
personal point of view. - is it expensive to construct a context and xwiki
supposing this setup
code is run multiple times?
As far as I know there is not much overhead to
construct the api wrapper. If you are in a Java code where you know you can
do everything and
don't care about the rights you should use the com.xpn.xwiki.*
classes. Those class have the same level of retro compatibility than
the api.* classes so that should not be an issue.
I could attempt this but I had a much harder time to do that.
- is DocReference behaving much differently than
fullName if we have a
single wiki?
Yes in the sense it handles escaping properly. It matters if you don't have
control over document names, it matters less if you do have this control
(for example you generate the name automatically or clean user input with
defined rules). I try to use the reference (a.k.a new model) API as often as
possible, but I admit sometimes it feels just too much when you know you're
not having escaping issues or multiwiki issues. Those times I do things like
xwiki.getDocument("XWiki.XWikiPreferences") and just live with it happily :)
Of course I'm speaking about my experience of using XWiki for my own needs
as an API consumer, not about the development of the XWiki platform.
paul
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
4386
days inactive
4387
days old
4 comments
3 participants
participants (3)
-
Jerome Velociter -
Paul Libbrecht -
Thomas Mortagne