Hi All,
i want to put a {{warning}} in the header of a page when a specific macro is
not contained. How can i do that. I tried in a Listener when the needed
Macro-Block is not contained with
doc.getXDOM().getRoot().addChild(new WordBlock("{{warning}}Warning
Text.{{/warning}}"));
context.getWiki().saveDocument(doc, context);
This not works. What is the correct way to manipulate the Document DOM on
Load?
Regards,
Matthias
--
View this message in context: http://xwiki.475771.n2.nabble.com/Inject-Warning-in-Page-when-Macro-in-Spac…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi All,
I want to create a component where i can overwrite a method of the component
from velocity or groovy script inside a wiki page. Its also fine if i can
"read" a groovy script to the component so i can use the defined logic.
Maybe i have to use a own programmed macro for that.
Is that possible? Do you use something similar somewhere?
Regards,
Matthias
--
View this message in context: http://xwiki.475771.n2.nabble.com/Overwrite-Method-of-Component-in-Velocity…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi,
Im trying to fix http://jira.xwiki.org/jira/browse/XWIKI-4274
Basically if you do $xwiki.getDocument("someDoc").getRenderedContent()
it'll get executed in the context of the current doc which I believe
is wrong especially since other signatures of getRenderedContent()
execute in the target document's context.
I have fixed this locally but found that admin.vm for example is
assuming that getRenderedContent() will get executed in the context of
the calling doc (i.e. XWiki.Import when doing an import for example).
FYI the chain flow is admin.vm -- getRenderedContent() -->
XWiki.AdminSheet --> XWiki.AdminImportSheet --> importinline.vm, which
requires the current doc to be XWiki.Import (to get/put attachments
from/to it).
I can fix this easily using a new getRenderedContent signature I've
introduced.
However I'm wondering if we have other places that incorrectly use
getRenderedContent() and assume it won't be rendered in the context of
the target document.
Is this change too dangerous to make? If not know, we'll need to it
quickly (2.1M1?) since it's an important bug IMO.
WDYT?
Thanks
-Vincent
Hello,
I would like to request a repository on xwiki-contrib for the Recruitment
Application i am working on.
I'd like the repo to be named application-recruitment and also jira
component.
My github username is chalx.
Thank you,
Alexandru Chelariu
Hello,
i have an idea concerning the icons of base skin colibri or others, we
should integrate "Entypo" on the skin ans delete all image icons, the
advantage is :
1- we win the chargement time of pages
2- reduce the number of code lines in the code.
3- we can add, edit , put color and change the sise of this icons
4- the skin of this icons are in flat design and we can put it in any form
5- its free for any users
for more information http://www.entypo.com/
wordpress have just integrate this solution
Yacine
Hi guys,
I have pushed a first version of flamingo in platform/XE, but it is only a
prototype that need a LOT more do be ready for production.
One of the new things brought by flamingo is the "Applications" left bar,
which is not exactly the same thing as the Applications Panel we already
have.
We can see it more as a "dock" with a list of applications, and in the
future, we could make it customizable by the user. Caty has written a
proposal for this [1].
Right now, for the first implementation, I need to make some choices about
the way we "populate" this bar. We can create new classes to describe the
bar entries, or new UI Extensions (maybe not the good choice regarding the
recent e-mails...), or by re-using the existing AddApplicationUIX... It is
described on
http://design.xwiki.org/xwiki/bin/view/Proposal/AppBar#HImplementationConsi….
Other thing: In my draft, I have created a new VM file on the filesystem
for this concept. Maybe I should create it as an extension point stored in
the database, but it means it won't appear on an empty wiki. WDYT?
I let you make some comments about this.
Thanks,
Caty & Louis-Marie
[1] http://design.xwiki.org/xwiki/bin/view/Proposal/AppBar
Hi everyone,
On the 15th of December (i.e. in a month's time), it will be **10 years**
since the first commit on the XWiki open source project.
Ludovic did the first commit in CVS on Sourceforge:
"
15.12.2003 10:13:33, by ludovic
Initial revision
"
(Can be seen at
http://svnsearch.org/svnsearch/repos/XWIKI/search?from=20030101&to=20040101
)
10 years is starting to be some respectable milestone!
I invite everyone to join us in celebrating by adding your own story about
your interaction with the XWiki community or the XWiki software at
http://dev.xwiki.org/xwiki/bin/view/Drafts/TenYearsOfXWiki
<XWiki SAS hat>
Since I'm also the CTO of the XWiki SAS company, I'd like to officially
invite all the members of this great community to join us in celebrating
the 10 days of the XWiki project at the XWiki SAS office in Paris, France
on the 12th of December 2013.
Here's the invitation:
http://www.xwiki.com/lang/en/News/XWiki+10th+Anniversary
See you there!
</XWiki SAS hat>
Well done everyone!
-Vincent Massol
Folks,
I'm testing kind of scalability of XWiki by simple benchmark which
creates N pages in a loop (one page at a time, it's not parallel run!)
and then when this loop finishes, it again in another loop gets all the
pages from the server (again serially, one page at the time). For page
creation we're using REST API, for getting the pages we're using common
browseable URL (/xwiki/bin/view/...).
Now the problem is that if I try to attempt creation of 100k pages, then
I hit Java's out of memory errors and server is unresponsive from that
time. I've tested this on:
- xwiki-jetty-hsql-6.0.0
- xwiki-jetty-hsql-6.0.1
- xwiki-tomcat7-pgsql -- debian xwiki packages running on top of debian 7.5
Of course I know the way how to increase Java's memory space/heap space.
The problem is that this will not help here. Simply if I do so and then
create 100 millions of pages on one run I will still get to the same
issue just it'll take a lot longer.
I've googled a bit for memoryleaks issues on Java and found an
interesting recommendation to use parallel GC. So I've changed
start_xwiki.sh to include -XX:+UseParallelGC in XWIKI_OPTS
Anyway, the situation is still looking suspiciously. I've connected
JConsole to the xwiki java process and overall view looks:
https://app.box.com/s/udndu96pl2fvuz3igvor
this is whole run overview, but perhaps even more clear is it on last 2
hours view which is here:
https://app.box.com/s/deuix33fzejra4uur941
Sidenote this all is from debugging xwiki-jetty-hsql-6.0.1 distro.
Now, what worries me a lot is this bottom cap which is growing. You can
see that clearly in Heap Memory Usage from 15:15. In CPU usage you can
also see that around the same time the CPU consumption went up from ~15%
to ~45%
When I switch to Memory Tab in JConsole and click several times on
"Perform GC" button, the bottom cap is still there and I cannot get
lower in memory usage. With this going on I can also see server failing
after some time on OOM error.
Any help with this is highly appreciated here.
Thanks!
Karel
Hi,
In Flamingo, we have created the concept of Application Bar, that we have
implemented as a Panel:
http://jira.xwiki.org/browse/XWIKI-10254
I propose to put the Application Bar by default on the left column.
Since we do not have a configuration system at the skin level, it would be
present for both Colibri & Flamingo. I think it is not a problem because I
have managed to make it look good for both (except for the size of the
icons) :
http://jira.xwiki.org/secure/attachment/27707/appbar.png
WDYT?
Thanks,
Guillaume
Hi,
There have been some recently discussions about Application Descriptors and
their utility when generating content for XWiki features, like taking the
icon field from the descriptor in order to generate the application panel
for the AppBar, etc.
I've gathered some use cases / needs on this page:
http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationDescriptor
It would be nice to brainstorm a bit if we consider the 'Application
Descriptor' concept to be needed in our future, especially since the
Flamingo Skin is focused heavily on the Applications concept.
I would be curious why this concept has been deprecated (Application
Manager):
* maybe the fields the descriptor contained are deprecated by the Extension
Manager;
* maybe a bad usage;
* etc.
And also very important is what fields you consider should be needed in the
Application Descriptor and ways to make it easily extensible.
Having an Application Descriptor would facilitate having an index
containing all applications, called Application Index, in order to help the
user navigate and manage the installed applications outside the Extension
Manager (which is found in Administration).
Thanks,
Caty & Louis-Marie