On Fri, Aug 26, 2011 at 4:49 PM, Sergiu
Dumitriu<sergiu(a)xwiki.com> wrote:
On 08/26/2011 03:00 AM, Grüner Heinrich wrote:
Hi Sergiu,
is there a way
1) to programmatically generate the mentioned wiki document that
generates the data
Yes, you can automatically generate it using
org.xwiki.bridge.DocumentAccessBridge.setDocumentContent (check first if
it exists using .exists from the same component).
You can do that in an observation listener that listens to the
ApplicationStartedEvent to do that at startup.
Actually no you can't because this event is sent before the database is ready.
Then what can be used? The worst way is to check every time the macro is
executed.
>
>> 2) hide this document from the user?
>
> Yes, there are two ways of doing that.
>
> 1 is to put it in the XWiki space, which is blacklisted (hidden from
> normal searches) for simple users. Admins and users that specified in
> their profile that they want to be "advanced" users will still see it
> listed in search results and the index.
>
> 2 is to mark it as hidden, but that requires calling the oldcore method
> com.xpn.xwiki.doc.XWikiDocument.setHidden (and save the document after
> that). This will make it really hard to find the document.
>
>> Maybe I should write a servlet instead and register it in xwikis web.xml ?
>
> Yes, this is one of the other more complicated ways of doing this. I say
> complicated because the first solution requires just putting a jar in
> the classpath, while this also requires changes to the web.xml file. The
> most recent version of the servlet specification allows servlets to be
> declared outside the main web.xml file, making it much easier to extend
> the application, but we're still on an older version to support a wider
> range of containers.
>
>> Thanks,
>> Stefan.
>> Am 26.08.2011 06:05, schrieb Sergiu Dumitriu:
>>> On 08/25/2011 09:50 AM, Grüner Heinrich wrote:
>>>> Hi,
>>>> I am very new to xwiki.
>>>> I've written a java-macro (implementing the
>>>> org.xwiki.rendering.macro.Macro interface), which is generating some
>>>> base content.
>>>> now, this content should be able to query data from the macro-bean via
>>>> ajax-request.
>>>> Is that possible? How should the ajax call look like?
>>> Well, a java bean isn't exactly ready to respond to HTTP requests by
>>> itself, so you need to make an intermediary that lies somewhere in the
>>> way of HTTP requests and exposes this data.
>>>
>>> There are several ways to do this, depending on how complex you want to
>>> make this interaction.
>>>
>>> The best approach I'd advise is to write a scriptable service component
>>> that offers some specific methods you need, and use it inside a wiki
>>> document. Here's a short plan:
>>>
>>> 1. Write another class that implements
>>> org.xwiki.script.service.ScriptService as a component. See
>>>
http://platform.xwiki.org/xwiki/bin/DevGuide/WritingComponents for more
>>> details about writing components (don't forget to declare it in
>>> components.txt). The hint of the component is the name of the service,
>>> so chose something descriptive. Being in Java, you'll find a way to get
>>> hold of your data and manipulate it as you wish. Build and put the jar
>>> in WEB-INF/lib, just like your macro (they can be both in the same jar).
>>>
>>> 2. Write a wiki document that calls your new scriptable service like:
>>> $service.myServiceName.getMyData() and outputs the data in the desired
>>> format. Don't forget to set the correct content type, so if you're
>>> outputting json put something like this:
>>> $response.setContentType('application/json')
>>> Of course, don't forget to wrap your code inside a {{velocity}} macro.
>>>
>>> 3. From Javascript make calls to this page using /get/ as the action and
>>> outputSyntax=plain as the query string. Don't hardcode the URL, use
>>> $xwiki.getURL('Service.DocumentName', 'get',
'outputSyntax=plain') to
>>> let the platform give you the correct URL.
>>>
>>> Speaking of javascript, for the best practice you should read
>>>
http://platform.xwiki.org/xwiki/bin/DevGuide/SkinExtensionsTutorial
>>>
>>>> Thanks,
>>>> Stefan.
>