I have a java macro which I've written that I'd like to reference from a panel.
Is there a way to use xwiki 2.0 syntax in a panel so I can invoke my macro?
It would appear that panels utilize 1.0 syntax? As a workaround I added yet another 2.0 page with just the macro invocation and then included that page in the panel. It seems like a catch22 if I create a component macro I can only use it in 2.0 and if I create a radeox macro I can only use it in 1.0.
How does one write a macro that can be accessable from 1.0 or 2.0 as well as from a panel?
Or, will the 1.0 be jettisoned entirely at some point ?
Thanks,
Glenn
Hi,
I think we need to add a plain text parser & a "plain/1.0" syntax id.
Here's a use case: you want to add a groovy class in a wiki page (and
you don't want it to be rendered as wiki syntax of course).
WDYT?
Thanks
-Vincent
Hi,
Following the previously aborted vote, here's a new proposal. The
problem with the current implementation is that you cannot write:
for (LinkBlock block : xdom.getChildrenByType(LinkBlock.class, true)) {
Block newBlock = new
FormatBlock(Collections.<Block>singletonList(block), Format.ITALIC);
block.replace(newBlock);
}
This fails because when the "block" is added in FormatBlock, its
parent is set to be the FormatBlock and thus when block.replace()
executes the parent of the new block is set to be the format block
instead of its parent.
I thus propose an API that is inline with the w3c DOM API:
/**
* Replaces an existing children block with the passed new block.
* Also sets the new block's parent to be the current block.
*
* @param newBlock the new block to replace the old block with
*/
void replaceChild(Block newBlock, Block oldBlock);
/**
* Replaces an existing children block with the passed new blocks.
* Also sets the new block's parents to be the current block.
*
* @param newBlocks the new blocks to replace the old block with
*/
void replaceChild(List<Block> newBlocks, Block oldBlock);
Note for Sergiu (before he asks ;)):
- We had evaluated using either the w3c Node API or the JCR Node API
before we created our own Block API.
- We cannot use the w3c Node interface since it contains too many
references to XML (like CDATA, ProcessingInstruction, etc)
- We cannot use the JCR Node API since it's too complex and contains
references to mixins, etc.
Here's my +1
Thanks
-Vincent
It seems that plugins that need to add panels or js/css support files end up creating a space with pages to store these elements. This in turn seems like it would lead to a plethora of spaces for which end users don't really have much use.
Ideally it would be nice to just have all these files in the jar file and have them invisibly be part of xwiki without needing to import an xar and create a new space. The advantage of this is you have a nice single package for updating and installation. This is typical of a confluence plugin.
Are there any plans to allow for 'plugin spaces' that might be 'hidden' or possibly have content provided more easily from a jar?
On a separate but related note, how do people deal today with revision control when there are wiki pages needed as part of a plugin? Do you keep exporting the plugin space and checking in xar files? I'm currently keeping page content separately as conventional files and pasting them into the wiki for testing.
I guess I'm not reporting anything is broke here but seems like some rough edges I'd like to smooth out.
--
Glenn
Hi,
Right now we have a Block.replace(List<Block> newBlocks) API but I'd
like to add a new one:
Block.replace(Block newBlock);
Here's a use case, be able to write:
for (LinkBlock block :
xdom.getChildrenByType(LinkBlock.class, true)) {
Block newBlock = new
FormatBlock(Collections.<Block>singletonList(block), Format.ITALIC);
block.replace(newBlock);
}
Rather than:
for (LinkBlock block :
xdom.getChildrenByType(LinkBlock.class, true)) {
Block newBlock = new
FormatBlock(Collections.<Block>singletonList(block), Format.ITALIC);
block.replace(Collections.<Block>singletonList(newBlock));
}
The rationale is that in most cases when we do a replace we do it with
a single block since most of our blocks contain children blocks.
I'd like to add this in 2.0 and also in 1.9 (not breaking anything).
The reason for 1.9 is that I'd like to use it in our Rendering
documentation (actually that's how I discovered the pb).
Here's my +1
Thanks
-Vincent
Hi devs,
Currently our Checkstyle configuration contains this:
<module name="LineLength">
<property name="ignorePattern" value="(@version|@see|@link|^import)"/>
<property name="max" value="120"/>
</module>
I propose we add the following pattern to the ignorePattern property:
@(\w+\.)+\w+::\w+\(
The reason is that "Java identifiers referenced from within JSNI methods
can get quite long and cannot be parsed if split across lines." (
http://code.google.com/webtoolkit/makinggwtbetter.html#codestyle ).
Here's an example:
var editor =
@com.xpn.xwiki.wysiwyg.client.editor.WysiwygEditorApi::new(Lorg/xwiki/gwt/dom/client/JavaScriptObject;)(config);
editor.@com.xpn.xwiki.wysiwyg.client.editor.WysiwygEditorApi::getSourceText(Lorg/xwiki/gwt/dom/client/JavaScriptObject;Lorg/xwiki/gwt/dom/client/JavaScriptObject;)(onSuccess,
onFailure);
So without modifying the ignorePattern I'm forced to exclude an entire
Java source file from Checkstyle just because some of the JSNI lines are
too long.
I'm +1 changing the ignorePattern property.
Thanks,
Marius
On Wed, Jun 3, 2009 at 06:45, asiri <platform-notifications(a)xwiki.org> wrote:
> Author: asiri
> Date: 2009-06-03 06:45:22 +0200 (Wed, 03 Jun 2009)
> New Revision: 20727
>
> Modified:
> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java
> Log:
> [misc] Made setParent() method use a compact document name serializer instead of the toString() method in DocumentName class.
>
> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java
> ===================================================================
> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java 2009-06-03 00:14:00 UTC (rev 20726)
> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java 2009-06-03 04:45:22 UTC (rev 20727)
> @@ -605,7 +605,9 @@
> */
> public void setParent(DocumentName parentName)
> {
> - this.parent = parentName.toString();
> + DocumentNameSerializer serializer =
> + (DocumentNameSerializer) Utils.getComponent(DocumentNameSerializer.class, "compact");
You don't need that, there is already a compactDocumentNameSerializer
initialized in XWikiDocument constructor.
> + this.parent = serializer.serialize(parentName);
> }
>
> public String getFullName()
> @@ -3154,10 +3156,10 @@
>
> public List<String> getChildren(XWikiContext context) throws XWikiException
> {
> - String[] whereParams = { this.getWikiName() + ":" + this.getFullName(), this.getFullName(), this.getName(),
> - this.getSpace() };
> -
> - String whereStatement = "doc.parent=? or doc.parent=? or (doc.parent=? and doc.space=?)";
> + String[] whereParams =
> + {this.getWikiName() + ":" + this.getFullName(), this.getFullName(), this.getName(), this.getSpace()};
> +
> + String whereStatement = "doc.parent=? or doc.parent=? or (doc.parent=? and doc.space=?)";
> return context.getWiki().getStore().searchDocumentsNames(whereStatement, Arrays.asList(whereParams), context);
> }
>
> @@ -3953,10 +3955,7 @@
> * renaming algorithm takes into account the fact that there are several ways to write a link to a given page and
> * all those forms need to be renamed. For example the following links all point to the same page:
> * <ul>
> - * <li>[Page]</li>
> - * <li>[Page?param=1]</li>
> - * <li>[currentwiki:Page]</li>
> - * <li>[CurrentSpace.Page]</li>
> + * <li>[Page]</li> <li>[Page?param=1]</li> <li>[currentwiki:Page]</li> <li>[CurrentSpace.Page]</li>
> * </ul>
> * <p>
> * Note: links without a space are renamed with the space added.
>
> _______________________________________________
> notifications mailing list
> notifications(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/notifications
>
--
Thomas Mortagne
Hello devs,
I'd like to reorganize the document footer as depicted in
http://incubator.myxwiki.org/xwiki/bin/view/Mockups/DocumentFooter , namely:
1: Tags will be displayed after the document content, as links to tag
pages, and not in an input element in the Information tab as they are
now. They are still editable in view mode by clicking an edit button
available after the tags list.
2. The "Created by ... on ..." information about the document will be
displayed before "Last modified by...", under the document content, and
not down in the page footer, where it seems ambiguous (seems to be
referring to the whole wiki), nor in the Information tab.
3. The "Information" tab becomes "Related documents", since it does not
contain the tags and the creator anymore. The related documents are:
* parent (editable in view mode by the same mechanism as the tags)
* children
* included documents
* links and backlinks
4. A new "Rights" tab is displayed for admins after "Related pages",
basically providing the rights management UI.
Here's my +1.
Any objections / other suggestions?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi Devs,
Currently DocumentNames generated by DocumentNameFactory contains the fully
qualified document name at all times. And when they are serialized using
DocumentNameSerializer, they result in the fully qualified document name
string like "wiki:space.name".
The problem with this is that new xwiki components using
DocumentAccessBridge cannot use relative document names. For an example,
"parent" field of a document cannot be set w.r.t the current wiki because
the "wiki:" part is always appended by default (by the serializer). So we
need a mechanism to specify "what kind of document name" we mean (relative
or absolute).
We can achive this in many ways:
1. Allow pasing a Serializer into methods which takes in a DocumentName.
2. Allow associating a Serilizer with a DocumentName.
3. Use Execution as a means of passing the preferred Serializer
4. Use a flag inside DocumentName (ABSOLUTE, WIKI_RELATIVE, SPACE_RELATIVE)
which will be intepretted by the Serializer appropriately whenever a
DocumentName is serialized.
None of the above approaches are perfectly clean. But the fourth approach
seems to make more sense.
I'm +1 for 4.
Thanks.
- Asiri
Hi
Beside the technical issues which are resolved now the other main
reason why I did not adapt XWiki so far is the available Skins. So far
I am running the Wiki based on Mac OS X Server 10.5 Wiki which looks
very slick. You can see under:
http://blogs.madplanet.com/groups/mpc-staff/
or something hat looks like my blog:
http://blogs.madplanet.com/users/schaefa/
XWiki only provides 2 skins which I don't think are very appealing for
readers even though Toucan gets the job done for a writer. So I tried
to figure out how to change a skin but could not find a lot of help on
how to wrap my head around probably because I am a developer and look
to far and think to complicated.
So first I am wondering why aren't there any other skins available?
Application like Drupal, Joopla and other have many available.
In case I want to change the images (let's say making it look like the
ones I mentioned above) do I then need to copy a skin directory and
start to change the images? And if yes which skin should I use? I seem
that 'toucan' has less items and is more up to date but I that is just
a hunch.
Has someone used the XWiki Skin Editor?
Thanks
Andreas Schaefer
CEO of Madplanet.com Inc.
Email: andreas.schaefer(a)madplanet.com
schaefera(a)me.com
Twitter; andy_mpc
AIM: schaefera(a)me.com
Hi devs,
Currently the above method is implemented so as to set the absolute name of
the parent document as the parent name of a page. Assuming we don't support
inter-wiki parent-child relationships, I propose we should modify this
method not to include the "wiki:" prefix in the parent name because it
breaks the wysiwyg (not displaying parent-child relationships correctly).
Now I'm not exactly sure whether it is the wysiwyg or this method that needs
fixing, but the latter is easier to fix.
If we do decide to modify this method, should i simply use:
<code>
public void setParent(DocumentName parentName)
{
this.parent = parentName.getSpace() + "." + parentName.getPage();
}
</code>
Or should I use a custom DocumentNameSerializer?
Thanks a lot.
- Asiri
Hello,
I try to create a page in XWiki/2.0 generating some JSON data but I have
some problems and I have to go back to XWiki/1.0...
* when you write this in a page MySpace.MyPage:
[
{ "field" : "value" }
]
you call MySpace.MyPage?xpage=plain and you get some HTML code:
<p><br/>.{ "field" : "value"...<br/></p>
this is not good for the JSON parser...
* So I try using the verbatim {{{}}}
{{{
[
{ "field" : "value" }
]
}}}
and I call again MySpace.MyPage?xpage=plain and I get:
<pre>
[
{ "field" : "value" }
]
</pre>
Ok for the JSON data but the <pre></pre> is not good also for JSON parser...
* If I write some velocity inside:
{{velocity}}
#doit()
[
{ "field" : "${value}" }
]
{{/velocity}
I get some <!-- velocity-macros --> comments or something like that before
my json encoded into HTML...
not good for the JSON parser also...
What's the solution in XWiki/2.0 to make a page generate JSON?
For the time being, I use XWiki/1.0 but this is not a viable solution.
thanks
Pascal
On Jun 1, 2009, at 4:12 PM, Sergiu Dumitriu wrote:
> vmassol (SVN) wrote:
>> Author: vmassol
>> Date: 2009-06-01 10:49:54 +0200 (Mon, 01 Jun 2009)
>> New Revision: 20681
>>
>> Log:
>> XWIKI-3913: Add support for Component Manager events
>>
>> * TODO: Refactor localization module to use the refactored
>> Observation module
>> * TODO: Refactor Rendering API module by removing notion of Source
>> Macro Manager (rollback as before) and instead use Component
>> Manager events to register Macros dynamically.
>>
>> Added: platform/core/trunk/xwiki-component/xwiki-component-default/
>> src/main/java/org/xwiki/component/manager/
>> ComponentDescriptorAddedEvent.java
>> ===================================================================
>> --- platform/core/trunk/xwiki-component/xwiki-component-default/src/
>> main/java/org/xwiki/component/manager/
>> ComponentDescriptorAddedEvent.java (rev 0)
>> +++ platform/core/trunk/xwiki-component/xwiki-component-default/src/
>> main/java/org/xwiki/component/manager/
>> ComponentDescriptorAddedEvent.java 2009-06-01 08:49:54 UTC (rev
>> 20681)
>> + public boolean matches(Object otherEvent)
>> + {
>> + boolean result = false;
>> +
>> + if
>> (ComponentDescriptorAddedEvent
>> .class.isAssignableFrom(otherEvent.getClass())) {
>> + ComponentDescriptorAddedEvent event =
>> (ComponentDescriptorAddedEvent) otherEvent;
>
> I'd like to support a wildcard here, like a listener for all component
> registrations (if getRole == null, return true).
>
> Also, why is getRole.getName compared to simply getRole?
Fixed, thanks.
>> + if (getRole().getName().equals(event.getRole())) {
>> + result = true;
>> + }
>> + }
>>
>> Modified: platform/core/trunk/xwiki-containers/xwiki-container-
>> servlet/src/main/java/org/xwiki/container/servlet/
>> XWikiPlexusServletContextListener.java
>> ===================================================================
>> // This is a temporary bridge to allow non XWiki components
>> to lookup XWiki components.
>> - // We're putting the XWiki Component Manager instance in
>> the Servlet Context so that it's
>> - // available in the XWikiAction class which in turn puts
>> it into the XWikiContext instance.
>> - // Class that need to lookup then just need to get it from
>> the XWikiContext instance.
>> - // This is of course not necessary for XWiki components
>> since they just need to implement
>> - // the Composable interface to get access to the Component
>> Manager or better they simply
>> - // need to define the Components they require as field
>> members and configure the Plexus
>> - // deployment descriptors (components.xml) so that they
>> are automatically injected.
>> servletContextEvent.getServletContext().setAttribute(
>>
>> org.xwiki.component.manager.ComponentManager.class.getName(),
>> this.componentManager);
>> }
>
> Why did you remove this comment?
Because It wasn't valid any more:
- we're not using XWikiAction
- there's no components.xml
- the compnent manager is now injected.
I thought it wasn't necessary to explain all this here and that saying
it's a temporary bridge that allows non components to lookup
components is enough.
>> Modified: platform/core/trunk/xwiki-core/src/test/java/com/xpn/
>> xwiki/XWikiTest.java
>> ===================================================================
>> --- platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/
>> XWikiTest.java 2009-06-01 07:45:41 UTC (rev 20680)
>> +++ platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/
>> XWikiTest.java 2009-06-01 08:49:54 UTC (rev 20681)
>> @@ -20,6 +20,7 @@
>> package com.xpn.xwiki;
>
> A bit of duplication here:
Actually I think that a bit of duplication isn't bad in tests if it
makes the test simpler to read. That's what I thought there.
>> - TestSaveEventListener listener = new
>> TestSaveEventListener();
>> + Mock mockListener = mock(EventListener.class);
>> +
>> mockListener
>> .stubs().method("getName").will(returnValue("testlistener"));
>> +
>> mockListener
>> .expects
>> (once()).method("getEvents").will(returnValue(Arrays.asList(new
>> DocumentSaveEvent("xwikitest:Some.Document"))));
>> +
>> ObservationManager om = (ObservationManager)
>> getComponentManager().lookup(ObservationManager.class);
>> - om.addListener(new
>> DocumentSaveEvent("xwikitest:Some.Document"), listener);
>> + om.addListener((EventListener) mockListener.proxy());
>> Modified: platform/core/trunk/xwiki-observation/src/main/java/org/
>> xwiki/observation/internal/DefaultObservationManager.java
>> ===================================================================
>
>> + for (Event listenerEvent : regListener.events) {
>
> Why do you check the class also? match() should take care of this, and
> it prohibits event inheritance.
Fixed, thanks.
Thanks for the review!
-Vincent
Hi devs,
Seen that we still have quite a few issues planned for 1.9 RC2 and
seen that Monday is bank holiday in France (and some of xwiki devs are
off on Tuesday) I'm proposing that we postpone the release from Monday
to Thursday 4th of June. In addition I'm proposing that we name it 1.9
final rather than RC2 and do another release (I think we already
agreed this before but let's make sure).
The idea would be to start stabilizing it from Tuesday onwards:
- ensure we have no regresssion (check email threads on the list -
There's one from Pascal to answer that I know of)
- do some strong testing.
+1 from me
Thanks
-Vincent
Hi,
I'm wondering how xwiki applies permissions to various actions. For example, in looking at the ViewAction and DeleteAction classes I don't see anything that would be applying permissions but clearly some part of the system knows that a /view/ action is different than a /delete/ which is different from a /viewrev/.
I created my own action and it 'appears' to be applying the edit permissions. How is this done? What if it was a view type of action?
Thanks,
Glenn
The XWikiClassTemplate velocity script is in a XWiki/1.0 syntax doc:
## replace Main with the Space where you want your documents to be created
## replace the default parent with the one of your choice
## Save this template using the 'Save' button
#set( $class = $doc.name.substring(0,$doc.name.indexOf("Class")))
#set($defaultparent = "kmbase.${class}Class")
#set($defaultweb = "kmbase")
#includeForm("XWiki.ClassSheet")
but now when you create a class, it is XWiki/2.0 and should be:
{{velocity}}
{{html wiki=true}}
## replace Main with the Space where you want your documents to be created
## replace the default parent with the one of your choice
## Save this template using the 'Save' button
#set( $class = $doc.name.substring(0,$doc.name.indexOf("Class")))
#set($defaultparent = "kmbase.${class}Class")
#set($defaultweb = "kmbase")
#includeForm("XWiki.ClassSheet")
{{/html}}
{{/velocity}}
What's the best solution to your mind in order to have something working in
all the cases?
Pascal
Hi,
There's a pb with the current implementation:
When we get the Observation manager implementation and list the
registered listeners we only get the components that have been
initialized *before* we get the Observation manager component. Thus if
we want to be sure all listeners will receive events we need to ensure
they're loaded first. This is hard to do.
I'm proposing instead to modify the observation module:
* Modify EventListener to be a @ComponentRole
* Add List<Event> EventListener.getEvents() (the events that the
listener handles)
* Inject List<EventListener> in DefaultObservationManager. Thus when
the Observation Manager is looked up, all listener components are
created and injected.
* Keep add/removeListener in ObservationManager so that listeners can
be manually added/removed (for ex if a new listener component is added
dynamically in the system) but with following signatures:
- addListener(EventListener);
- removeListener(EventListener);
WDYT?
Thanks
-Vincent
Hello,
I have recompiled a XWiki 1.9-RC1 for jetty+derby and I have some little
problems and I prefer asking before thinking:
- I don't see the icons in the administration page and the last item
"OpenOffice Importer" seems badly HTML formed and displays
"
http://www.mandubian.org/xwiki/bin/download/XWiki/OfficeImporterAdmin/icon.…)
no-repeat;">OpenOffice Server"
Please see the attached screenshot
- I can't view Blog.WebHome because there is some bad SQL for Derby
apparently
Caused by: com.xpn.xwiki.XWikiException: Error number 3223 in 3: Exception
while searching documents with SQL [select distinct doc.space, doc.name,
publishDate.value from XWikiDocument as doc , DBStringListProperty as
categories join categories.list as category, BaseObject obj, IntegerProperty
isPublished, IntegerProperty hidden, DateProperty publishDate
where (doc.hidden <> true or doc.hidden is null) and doc.fullName <>
'Blog.BlogPostTemplate' and
obj.name = doc.fullName and obj.className = 'Blog.BlogPostClass' and
publishDate.id.id = obj.id and publishDate.id.name = 'publishDate' and
isPublished.id.id = obj.id and isPublished.id.name = 'published' and
hidden.id.id = obj.id and hidden.id.name = 'hidden' and
(doc.creator = 'XWiki.Admin' or (isPublished.value = 1 and
hidden.value = 0)) and obj.id = categories.id.id and
categories.id.name='category'
and category in ('Blog.News') order by publishDate.value desc]
Wrapped Exception: could not execute query
at
com.xpn.xwiki.store.XWikiHibernateStore.searchDocumentsNamesInternal(XWikiHibernateStore.java:2302)
at
com.xpn.xwiki.store.XWikiHibernateStore.searchDocumentsNames(XWikiHibernateStore.java:2266)
at
com.xpn.xwiki.store.XWikiHibernateStore.searchDocumentsNames(XWikiHibernateStore.java:2747)
at
com.xpn.xwiki.store.XWikiCacheStore.searchDocumentsNames(XWikiCacheStore.java:267)
at com.xpn.xwiki.api.XWiki.searchDocuments(XWiki.java:406)
at sun.reflect.GeneratedMethodAccessor325.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:389)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:378)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:270)
... 154 more
2009-05-29 12:01:25,585 [http://localhost:8080/xwiki/bin/view/Blog/]
[1857040122@qtp0-6] WARN util.JDBCExceptionReporter - SQL Error:
20000, SQLState: XJ061
2009-05-29 12:01:25,585 [http://localhost:8080/xwiki/bin/view/Blog/]
[1857040122@qtp0-6] ERROR util.JDBCExceptionReporter - The 'absolute()'
method is only allowed on scroll cursors. [ERROR] Exception in macro
#getPagedBlogEntries at Blog.WebHome[line 141, column 5]
[ERROR] Exception in macro #getBlogEntries at Blog.WebHome[line 17, column
3]
[ERROR] Exception in macro #printBlog at Blog.WebHome[line 7, column 3]
org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with
id [Blog.WebHome]
any idea?
Pascal
Hi,
Here is my experience when I tried to publish a post to blog in
gsoc.myxwiki. And I want to clarify few things about it. I have created a
blog post called RunningSeleniumTests to be published. After created it I
have saved it and used small button to publish the post. But it did not
publish or told me any reason why it did not publish.
Questions
1. Is it only allowed to be published after acceptance by some person in
admin group?
After that, I thought I should try to change some rights of the objects and
then changed the rights and only added edit rights to XWikiAdminGroup I
think. and I just saved. After that only I realized I can't edit the post
any more. Is it a bug? because I have created the post and changed rights,
but then I can't edit it any more ?
And also eventhough it is not published you can even view it by adding the
link to your normal page. Eventhough its not published we can view it using
the link.
http://gsoc.myxwiki.org/xwiki/bin/view/XMPPIntegration/RunningSeleniumTests
Finally what I did was added the link to my main page rather than waiting it
to be published. :)
2. Could anyone please tell me some tips to resolve this ?
Kind Regards,
-Tharindu
Hi,
I want to resurface this question in case it is something that could be addressed in the 2.0 release. I have a macro that requires some js support (jquery) and would thus like to have additional files referenced in the head section of the page when the macro is used.
It was suggested that I could specify dependencies of css and js files for a macro by using getPluging("jsfx") and invoking the use method.
>From what I can tell this method does not work so I'm wondering if the 'context' obtained as suggested is not the proper context to add additional elements to the rendered page.
Here is what I've done:
To get the context, I added this:
@Requirement
private Execution execution;
And then in my macro execution method I added the following:
ExecutionContext executionContext = execution.getContext();
XWikiContext context = (XWikiContext) executionContext.getProperty("xwikicontext");
XWiki xwiki = context.getWiki();
AbstractSkinExtensionPlugin plugin = (AbstractSkinExtensionPlugin) xwiki.getPlugin("jsfx", context);
plugin.use("/foo/bar.js",context);
When I utilize this from my macro execution callback it doesn't emit any code in the header. (using jsfx as a velocity macro does work though).
Is the context obtained via this method the right one or is there a different one somehow attached to the rendering agent?
Thanks,
Glenn