Hi devs,
Since we're in a rush for the final 1.6 release I'm proposing to
postpone creating the 1.6 branch to this Thursday. This means that
trunks stays 1.6 final and thus only bug fixes should be done.
Thus this means postponing any 1.7 change to after Thursday.
Is that ok with everyone?
Thanks
-Vincent
Hi devs,
You know we've been facing some problems in the new GWT editor. Marius
needs 2 days more to finish fixing the 2 important bugs related to:
- paragraph support
- bolding/unbolding (same for italic and underline I guess)
We also need 1 day to all test the new GWT WYSIWYG and try to find
more issues.
Note that since we've had to do low level JS, it's currently only
working for FF... So the editor won't work on IE or any other browser
to 1.6 final. It may work but it won't work perfectly well yet.
In addition and to reduce the 1.6 final release date (compared to the
original plan of 22nd of September), I propose that we release the
final 1.6 on this Thursday (the 2nd).
To do this I propose that we ALL spend time testing the current 1.6
trunk code to verify that all works fine.
This is a bet we're taking but I think we could easily win 1 or 2
weeks by doing it. In addition and should we need it we can quickly
release a 1.6.1 release.
Here's my +1 for this plan + for helping test it.
Thanks
-Vincent
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, 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
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
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 = {
Someone was asking about JS execution in PDF exports.
Found this announcement today: http://www.theserverside.com/news/thread.tss?thread_id=50837
This is just a FYI and a reminder to look into it when we overhaul the
PDF export.
Thanks
-Vincent