Hello XWikiers,
I did not find a nice way to package our reviews-application.
It should yield a xar and I would have expected the xar could be built
with all items.
Unfortunately, I have only found a way to package the xml files in the
xar and I would like to put groovy and .vm sources there... thus far
I am copy and pasting.
mvn -g did not help me.
thank for hints.
paul
Hi devs,
while developing my XWiki watch component, I've written a quick start tutorial
on XWiki components, which I would like to add in the dedicated section on
platform.xwiki.org.
It is currently in draft version at
http://dev.xwiki.org/xwiki/bin/view/Drafts/CreatingComponents . Please give it a
critical look and signal any errors that might have slipped or send improvement
suggestions.
Here's my +1 for taking it out of draft version, WDYT?
Happy coding,
Anca Luca
Hi Devs,
In the current xwiki-webdav implementation we have introduced a feature
where all the pages under a certain space is grouped according to the
starting characters of those pages. For an example, consider the following
setup :
space : Farm
pages under Farm : Dog, Cat, Donkey, Carrot, Mouse
Then the user will see the following directory structure on webdav,
xwiki/webdav/spaces/Farm/
|
|-D (Dog & Donkey goes here)
|
|-C (Cat & Carrot goes here)
|
|-M (Mouse ends up here)
Note : How many starting characters used to make groupings depends on the
number of documents inside the space.
Now, from xwiki-ui to access various documents via webdav, we have to allow
direct access to pages as well. That is, following url pattern should work
fine :
xwiki/webdav/spaces/<space_name>/<page_name> (makes sense right ?)
Now the problem with the current implementation is that in a url like
xwiki/webdav/spaces/FOO/BAR we don't know whether BAR is a grouping or if it
is a page (direct access). So I propose the following :
* All the grouped directories should start with a "_" and end with a "_"
(may be only one of them, but i like symmetric)
By this way we can easily differentiate direct page requests from indirect
access.
Ex :
Indirect : /xwiki/webdav/spaces/Foo/_D_/D
Direct : /xwiki/webdav/spaces/Foo/D
Note : Here the page name is 'D'.
WDYT ?
Thanks.
- Asiri
Hi Devs, Ludovic,
I'm faced with the following problem,
Currently xwiki-webdav is deployed under /xwiki/webdav/*. And for this to
work, we need PROPFIND method to work correctly on following locations { "/"
, "/xwiki/" , "/xwiki/webdav/*". } For "/" i have written a separate
xwiki-rootwebapp and it works fine. For "/xwiki/" and "/xwiki/webdav/*" I
had defined the following servlet mapping elemnts :
<servlet-mapping>
<servlet-name>xwiki-webdav</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>xwiki-webdav</servlet-name>
<url-pattern>/webdav/*</url-pattern>
</servlet-mapping>
Everything was working fine but lately i discovered that none of the static
content is being served correctly. This is because of the first mapping on
"/", this seems to overrride the default servet of the container (which
serves static files). Without the first mapping some webdav clients fail
because they think the url is not a webdav one.
I'm really stuck here and can't think of a solution, if you have any ideas
please let me know.
Thanks a lot.
- Asiri
Hello Xwiki-Devs,
for the fun of it I let FindBugs check the Xwiki Core code and it found
a bunch of "Issues". Some of them are more severe than others.
Maybe it is interesting to check it out. In my own programs I found some
really interesting errors/problems I was never aware of. (Including some
thread safety related stuff)
The good thing with Findbugs is the extensive documentation, that gives
you a very good explanation why the found issue is an issue. There are
also some "false positives", also explained in the documentation.
http://findbugs.sourceforge.net/
Findbugs also has good Eclipse Integration and a Maven plugin.
Definitely worth a try. A first peek is painlessly done via Java webstart.
It's just a pointer..
Greetings
Jonas
Hi Wang,
Long time no hear, you must be busy :)
Could you let us know what's the status WRT to cleaning up the office-
generated HTML?
The roadmap I'd like to have is to have it fully working for 1.7 final
(that's for the 1st of December). Do you think that's feasible?
My take is that we should have some pretty solid cleaning up by 1.7M1
if we want to have a chance of it being finished for 1.7 final.
Here's the currently planned 1.7 dates:
- 1.7M1: 20th of October (that's more than 3 weeks after the 1.6
release)
- 1.7M2: 10th of November (3 weeks after 1.7M1)
- 1.7RC1: 17 Nov (one week after)
- 1.7RC2 or final: 24 Nov (one week after)
- 1.7 final (if needed): 1st of December
WDYT? Do you need any help to achieve this?
Thanks
-Vincent
Hi everyone,
Just to let you know maven.xwiki.org is undergoign maintenance right
now.
So you might want to run your builds in offline mode for the time being.
Thanks
-Vincent
Hello devs,
I would like to promote XWiki Workspaces 1.1 RC1 as 1.1 final tomorrow.
Only changes from RC2 will be reviewed English translation resources.
Here is my +1 for it.
Jerome.
Hi,
I think we might need to review our singleton components (i.e. all of
them ;)) for sync. issues.
For example take DefaultObservationManager:
private Map<String, List<RegisteredListener>> listeners = new
HashMap<String, List<RegisteredListener>>();
It has for ex a addListener() method.
Imagine several threads all calling addListener().
Since HashMap is not synchronized this can cause problems.
Thus shared objects should all be synchronized or they should only be
filled once (as in an initialize method for ex).
WDYT? Do you agree there's a potential bug in the case above?
Thanks
-Vincent
Is this temporary? I'm not sure it's a good idea to generate HTML from
business code. The HTML should be generated in the templates IMO.
WDYT?
Thanks
-Vincent
On Sep 30, 2008, at 6:31 PM, mflorea (SVN) wrote:
> Author: mflorea
> Date: 2008-09-30 18:31:41 +0200 (Tue, 30 Sep 2008)
> New Revision: 13101
>
> Modified:
> platform/web/trunk/standard/src/main/webapp/templates/
> editwysiwygnew.vm
> Log:
> I'm using the WysiwygPlugin to generate the HTML input hidden
> element that will hold the initial HTML content of the editor. This
> way the HTML special symbols are escaped inside the value attribute.
>
> Modified: platform/web/trunk/standard/src/main/webapp/templates/
> editwysiwygnew.vm
> ===================================================================
> --- platform/web/trunk/standard/src/main/webapp/templates/
> editwysiwygnew.vm 2008-09-30 16:24:51 UTC (rev 13100)
> +++ platform/web/trunk/standard/src/main/webapp/templates/
> editwysiwygnew.vm 2008-09-30 16:31:41 UTC (rev 13101)
> @@ -28,7 +28,7 @@
> ## If JavaScript is disabled the user will still be able to edit the
> document using this HTML text area.
> $xwiki.getTextArea($tdoc.content)
> ## We separated the hook of the editor (the previous HTML text area)
> from editor's input source (the following hidden input)
> -<input type="hidden" id="htmlContent" value="$
> {xwiki.wysiwyg.toHTML($tdoc.content, $doc.syntaxId)}"
> disabled="disabled" />
> +$xwiki.wysiwyg.getInput("htmlContent", $tdoc.content, $doc.syntaxId)
> <script type="text/javascript">
> //<![CDATA[
> var Wysiwyg0 = {