On Fri, Jun 26, 2009 at 19:53, Sergiu Dumitriu<sergiu(a)xwiki.com> wrote:
> tmortagne (SVN) wrote:
>> Author: tmortagne
>> Date: 2009-06-19 13:02:05 +0200 (Fri, 19 Jun 2009)
>> New Revision: 21347
>>
>> Modified:
>> platform/core/branches/xwiki-core-1.9/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/main/java/org/xwiki/rendering/internal/macro/velocity/filter/HTMLVelocityMacroFilter.java
>> platform/core/branches/xwiki-core-1.9/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/test/java/org/xwiki/rendering/internal/macro/velocity/filter/HTMLVelocityMacroFilterTest.java
>> Log:
>> XWIKI-3988: Default Velocity macro filter does not match directives on multiple lines
>> * add support for non UNIX newlines
>>
>> Modified: platform/core/branches/xwiki-core-1.9/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/main/java/org/xwiki/rendering/internal/macro/velocity/filter/HTMLVelocityMacroFilter.java
>> ===================================================================
>> --- platform/core/branches/xwiki-core-1.9/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/main/java/org/xwiki/rendering/internal/macro/velocity/filter/HTMLVelocityMacroFilter.java 2009-06-19 07:28:54 UTC (rev 21346)
>> +++ platform/core/branches/xwiki-core-1.9/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/main/java/org/xwiki/rendering/internal/macro/velocity/filter/HTMLVelocityMacroFilter.java 2009-06-19 11:02:05 UTC (rev 21347)
>
>> + * Match not UNIX new lines to replace them.
>> + */
>> + private static final Pattern MSNEWLINE_PATTERN = Pattern.compile("\\r\\n|\\r");
>
> I ran a quick test, and using \\r\\n? instead of \\r\\n|\\r is 40%
> faster. I think it's also safer, since '?' is by definition greedy,
> while '|' doesn't clearly indicate which of the two branches is
> executed, so it might replace just the \r with a new \n, leaving the old
> \n in place, thus yielding the wrong result.
>
>
> And I don't like this name, since \r is MacOS. You could call it
> ALTERNATIVE_LINE_ENDINGS.
Good ideas, i'm applying it.
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
tmortagne (SVN) wrote:
> Author: tmortagne
> Date: 2009-06-21 11:52:13 +0200 (Sun, 21 Jun 2009)
> New Revision: 21370
>
> Modified:
> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/plugin/ldap/XWikiLDAPConfig.java
> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/render/DefaultVelocityManager.java
> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/render/XWikiScriptContextInitializer.java
> Log:
> XWIKI-3942: Can't have the xwiki api Context as "context" binding in most of the JSR-223 engines
> * add "xcontext" binding and deprecate "context" in velocity
>
> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/plugin/ldap/XWikiLDAPConfig.java
> ===================================================================
> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/plugin/ldap/XWikiLDAPConfig.java 2009-06-20 16:35:07 UTC (rev 21369)
> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/plugin/ldap/XWikiLDAPConfig.java 2009-06-21 09:52:13 UTC (rev 21370)
> @@ -134,7 +134,7 @@
> */
> public String getLDAPParam(String prefName, String cfgName, String def, XWikiContext context)
> {
Wrong commit.
> - String param = def;
> + String param = null;
>
> try {
> param = context.getWiki().getXWikiPreference(prefName, context);
>
> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/render/DefaultVelocityManager.java
> ===================================================================
> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/render/DefaultVelocityManager.java 2009-06-20 16:35:07 UTC (rev 21369)
> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/render/DefaultVelocityManager.java 2009-06-21 09:52:13 UTC (rev 21370)
> @@ -85,7 +85,9 @@
>
> // We put the com.xpn.xwiki.api.Context object into the context and not the com.xpn.xwiki.XWikiContext one
> // which is for internal use only. In this manner we control what the user can access.
"Deprecated" should be more than this. How about printing a warning in
the log when using $context?
> + // "context" binding is deprecated since 1.9.1
> vcontext.put("context", new Context(xcontext));
> + vcontext.put("xcontext", new Context(xcontext));
>
> // Make the Syntax Factory component available from Velocity.
> // TODO: We need to decide how we want to expose components in general and how to protect users from
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
vmassol (SVN) wrote:
> Author: vmassol
> Date: 2009-06-19 21:18:47 +0200 (Fri, 19 Jun 2009)
> New Revision: 21360
>
> Modified:
> platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main/java/org/xwiki/xml/XMLUtils.java
> platform/core/branches/xwiki-core-1.8/xwiki-xml/src/test/java/org/xwiki/xml/internal/html/DefaultHTMLCleanerTest.java
> Log:
> XWIKI-4005: HMTL Cleaner should not expand empty elements for BR and HR in order to support IE6
>
>
> Modified: platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main/java/org/xwiki/xml/XMLUtils.java
> ===================================================================
> --- platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main/java/org/xwiki/xml/XMLUtils.java 2009-06-19 16:35:08 UTC (rev 21359)
> +++ platform/core/branches/xwiki-core-1.8/xwiki-xml/src/main/java/org/xwiki/xml/XMLUtils.java 2009-06-19 19:18:47 UTC (rev 21360)
> @@ -213,7 +225,16 @@
> format.setOmitDeclaration(omitDeclaration);
>
> XMLOutputter outputter = new XWikiXMLOutputter(format, omitDoctype);
> - return outputter.outputString(jdomDoc);
> + String result = outputter.outputString(jdomDoc);
> +
> + // Since we need to support IE6 we must generate compact form for the following HTML elements (otherwise they
> + // won't be understood by IE6):
> + for (String specialElement : OMIT_ELEMENT_CLOSE_SET) {
> + result = result.replaceAll(MessageFormat.format("<{0}></{0}>", specialElement),
Shouldn't this be something like "<{0}[^>]*+></{0}>"? I doubt that there
really is <img></img>, and if it is, it won't make much difference which
way it's written.
> + MessageFormat.format("<{0}/>", specialElement));
> + }
> +
> + return result;
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
tmortagne (SVN) wrote:
> Author: tmortagne
> Date: 2009-06-22 15:07:18 +0200 (Mon, 22 Jun 2009)
> New Revision: 21405
>
> Added:
> platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/main/java/org/xwiki/rendering/internal/macro/velocity/filter/IndentVelocityMacroFilter.java
> platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/test/java/org/xwiki/rendering/internal/macro/velocity/filter/IndentVelocityMacroFilterTest.java
> Log:
> XWIKI-4018: Create an indentation velocity macro filter
>
> Added: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/main/java/org/xwiki/rendering/internal/macro/velocity/filter/IndentVelocityMacroFilter.java
> ===================================================================
> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/main/java/org/xwiki/rendering/internal/macro/velocity/filter/IndentVelocityMacroFilter.java (rev 0)
> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/main/java/org/xwiki/rendering/internal/macro/velocity/filter/IndentVelocityMacroFilter.java 2009-06-22 13:07:18 UTC (rev 21405)
> + /**
> + * Match indentation spaces.
> + */
> + private static final Pattern INDENT_PATTERN = Pattern.compile("^[ \t]*", Pattern.MULTILINE);
Replace with "^[ \t]++":
- * means that it matches all line starts, doing a useless replace for
the empty string. Thus the first +.
- The second + is not that useful, since there's no backtracking to
perform, but just to be explicit, it might save some ifs and elses.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
tmortagne (SVN) wrote:
> Author: tmortagne
> Date: 2009-06-19 13:02:05 +0200 (Fri, 19 Jun 2009)
> New Revision: 21347
>
> Modified:
> platform/core/branches/xwiki-core-1.9/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/main/java/org/xwiki/rendering/internal/macro/velocity/filter/HTMLVelocityMacroFilter.java
> platform/core/branches/xwiki-core-1.9/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/test/java/org/xwiki/rendering/internal/macro/velocity/filter/HTMLVelocityMacroFilterTest.java
> Log:
> XWIKI-3988: Default Velocity macro filter does not match directives on multiple lines
> * add support for non UNIX newlines
>
> Modified: platform/core/branches/xwiki-core-1.9/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/main/java/org/xwiki/rendering/internal/macro/velocity/filter/HTMLVelocityMacroFilter.java
> ===================================================================
> --- platform/core/branches/xwiki-core-1.9/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/main/java/org/xwiki/rendering/internal/macro/velocity/filter/HTMLVelocityMacroFilter.java 2009-06-19 07:28:54 UTC (rev 21346)
> +++ platform/core/branches/xwiki-core-1.9/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/main/java/org/xwiki/rendering/internal/macro/velocity/filter/HTMLVelocityMacroFilter.java 2009-06-19 11:02:05 UTC (rev 21347)
> + * Match not UNIX new lines to replace them.
> + */
> + private static final Pattern MSNEWLINE_PATTERN = Pattern.compile("\\r\\n|\\r");
I ran a quick test, and using \\r\\n? instead of \\r\\n|\\r is 40%
faster. I think it's also safer, since '?' is by definition greedy,
while '|' doesn't clearly indicate which of the two branches is
executed, so it might replace just the \r with a new \n, leaving the old
\n in place, thus yielding the wrong result.
And I don't like this name, since \r is MacOS. You could call it
ALTERNATIVE_LINE_ENDINGS.
Hi!
I've managed to implement the bidirectional converter as you suggested .
Thank you very much for your help. Now I have another problem :( .. I tried
to use the OpenOffice cleaner XWiki Component from the OpenOffice Importer
module
http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-officeimporter…
My code is this one:
HTMLCleaner openOfficeHTMLCleaner = (HTMLCleaner)
ecm.lookup(HTMLCleaner.class,"openoffice");
ecm is an EmbeddableComponentManager instance.
And I have at Runtime the follow exceptions: http://pastebin.com/m1920f9cf
I've added openoffice module as dependency. Sorry I'm not very familiar with
XWiki Components. Has anybody an idea what I am missing?
Thanks a lot,
Cristina
Hi XWiki Devs & Users,
here's the current proposal for the XWiki Enterprise 2.0 roadmap. Please
give us your feedback about it and tell us whether you think we missed
anything important. Please note that this roadmap covers the next 3 months
of development work. Improvements not included here will be discussed at the
beginning of the next roadmap (in September 2009).
Shout if you think we forgot something ;-)
The list of tasks is divided in 3 parts: tasks we have already planned to
have people working on, tasks that we would like to complete during the
course of the release but have nobody planning to work on yet and tasks that
will have to be postponed until the next release cycle.
*Tasks with people already planned to work on:*
- Rendering (Thomas)
- Fix bugs
- Make sure the XWiki 2.0 syntax doesn't move any more once XE 2.0 is
out
- WYSIWYG editor (Marius, Anca)
- Fix bugs
- Implement search in the link insertion dialog box
- Improve the macro insertion dialog box
- CAPTCHA integration (Jérôme)
- Clustering (Thomas)
- Write a clustering component based on XWiki events
- Activity Stream integration (JV)
- Watchlist (JV)
- Rewrite the watchlist feature based on the activity stream
- Make the watchlist work in XEM
- Macros (Asiri)
- Write the velocity macro bridge
- Write a number of velocity macros
- UI Improvements (Caty)
- Blog
- User Profile
- Architectural Improvements (Vincent)
*Tasks with nobody planned to work on as of today:*
- Migrate all XWiki Enterprise pages to use the XWiki 2.0 syntax
(Collective effort?)
- Rewrite XWiki's Lucene Search backend (Sergiu?)
- Improve XWiki's default skin (Laurent?)
*Tasks that will have to be postponed to the next release cycle:*
- Application Manager
- Document Type Manager
- Invitation Manager
The current roadmap dates are the following:
- XE 2.0 M1: June 22
- XE 2.0 M2: July 13
- XE 2.0 M3: August 3
- XE 2.0 RC: August 17
- XE 2.0: August 31
Thanks in advance for your feedback.
Guillaume, on behalf of the XWiki Development Team