September 2008 - xwiki-devs@xwiki.org

[xwiki-devs] how to deal with the deprecated tags in xhtml
by Wang Ning 03 Sep '08

03 Sep '08

Hi, Using the HtmlCleaner 2.1, we can just replace the deprecated tags to appropriate alternative. We can remove TagSwapCleaningFilter.java and set CleanerTransformations in DefaultHTMLCleaner.java instead. Now we only swap to , to . Is it necessary to replace more deprecated tags? I collect some other tags I think can be replaced. s -> del strike -> del u -> ins or centre -> font -> basefont -> Should we replaces all the tags above to their alternative? WDYT? There are some deprecated tags which don't have explicit alternative, as below: applet dir menu isindex -- Thanks Wang Ning

3 3

[xwiki-devs] [Proposal] Components and svn directory organization
by Vincent Massol 03 Sep '08

03 Sep '08

Hi devs, Right now we have: platform/ |_ core/ |_ xwiki-core/ |_ (others)/ |_ plugins/ |_ ... The problem I see is twofold: 1) We can have platform components that are not core components (for example I'd like to commit the office component done by Wang Ning). 2) I'd like that we decide to deprecate the plugins/ system going forward and that all new code only write components. For 1) I'd like to propose: platform/ |_ components/ (contains (others)/ from above) |_ core/ (is the core/xwiki-core from above, to be removed once fully split into components) |_ plugins/ (to be removed once fully split into components) |_ ... For 2) I'd like to propose: * Create an interface for Velocity APIs. Something like VelocityBridge (or VelocityAccess or VelocityApi or...). It would be empty. * Each component that want to be accessed from velocity will need to implement a component implementing VelocityBridge. It'll have a role- hint being the name under which it'll be access from Velocity. * Create a VelocityService class (component) which has a single get(String name) method and which uses the ComponentManager to look up components which implement VelocityBridge using the name as the role hint. * Put that VelocityService in the Velocity context under the name "services". In practice this means that users will be able to access all our components through the VelocityBridge implementations with a syntax like: $services.office.convert(...) $services.translation.translate(...) ... Note1: We would need to be careful that it would be forbidden for any java code to use a VelocityBridge. This is to ensure all code logic is put into components and not into the bridges. We should use the maven enforcer plugin to enforce this rule. Note2: This means we'll have 2 APIs to maintain: the velocity one (the bridges) + the "Java"' one (the main components). But I don't see any other way... WDYT? Thanks -Vincent

7 15

03 Sep '08

vmassol (SVN) wrote: > Author: vmassol > Date: 2008-09-02 12:18:10 +0200 (Tue, 02 Sep 2008) > New Revision: 12357 > > Added: > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/block/AbstractVerbatimBlock.java > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/block/InlineVerbatimBlock.java > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/block/StandaloneVerbatimBlock.java > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/block/VerbatimBlock.java > platform/core/trunk/xwiki-rendering/src/test/resources/verbatim/ > platform/core/trunk/xwiki-rendering/src/test/resources/verbatim/verbatim1.test > platform/core/trunk/xwiki-rendering/src/test/resources/verbatim/verbatim2.test > platform/core/trunk/xwiki-rendering/src/test/resources/verbatim/verbatim3.test > Removed: > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/internal/macro/nowiki/ > platform/core/trunk/xwiki-rendering/src/test/resources/macros/macronowiki.test > Modified: > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/block/EscapeBlock.java > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/internal/parser/doxia/DoxiaGeneratorListener.java > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/internal/parser/wikimodel/WikiModelGeneratorListener.java > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/internal/parser/wikimodel/XDOMGeneratorListener.java > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/listener/Listener.java > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/listener/ListenerDelegate.java > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/renderer/EventsRenderer.java > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/renderer/XWikiSyntaxRenderer.java > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/renderer/xhtml/XHTMLRenderer.java > platform/core/trunk/xwiki-rendering/src/main/resources/META-INF/plexus/components.xml > platform/core/trunk/xwiki-rendering/src/test/java/org/xwiki/rendering/RenderingTests.java > Log: > XWIKI-2634: Various tasks for the new rendering implementation > > * Added support for verbatim. > * Removed nowiki macro which is no longer necessary > I'm starting to dislike the way renderers are done. They have many methods to handle each type of element, the renderer classes are already becoming large, and introducing a new element requires changing many classes. Isn't there a better way to do this? One would be to have just an onEvent method, and then the XYZRenderer would forward the call to a specific class responsible for handling that type of event. The downside is that we'll have many small classes and large configuration files, but the advantage is that unimplemented elements won't throw exceptions, but use a generic event handler. I don't know which way is better, fewer huge classes, or more tiny classes. If the syntax will become *very* stable soon, then I guess the current way is good, too. IMHO. -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 2

Re: [xwiki-devs] [xwiki-notifications] r12369 - in platform/core/trunk/xwiki-xml: . src/main/java/org/xwiki/xml/internal/html src/test/java/org/xwiki/xml/internal/html
by Sergiu Dumitriu 02 Sep '08

02 Sep '08

vmassol (SVN) wrote: > Author: vmassol > Date: 2008-09-02 22:15:02 +0200 (Tue, 02 Sep 2008) > New Revision: 12369 > > Added: > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/html/HTMLConstants.java > Removed: > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/html/TagSwapCleaningFilter.java > Modified: > platform/core/trunk/xwiki-xml/pom.xml > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/html/DefaultHTMLCleaner.java > platform/core/trunk/xwiki-xml/src/test/java/org/xwiki/xml/internal/html/DefaultHTMLCleanerTest.java > Log: > XWIKI-2634: Various tasks for the new rendering implementation > > * Improved HTML Cleaning by upgrading to HtmlCleaner 2.1 and by adding more tag transformations. > Patch submitted by Wang Nine, reviewed by Vincent Massol with modifications (it was failing the build with checkstyle errors) > + tt = new TagTransformation(HTMLConstants.CENTRE, HTMLConstants.P, false); > + tt.addAttributeTransformation(HTMLConstants.STYLE_ATTRIBUTE, "text-align:center"); > + transformations.addTransformation(tt); > + /** > + * HTML <centre> tag name. > + */ > + String CENTRE = "centre"; This should be "center", not "centre" -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 1

[xwiki-devs] [Proposal] WYSIWYG 1.6 roadmap
by Marius Dumitru Florea 02 Sep '08

02 Sep '08

Hi devs, Here's the roadmap I propose: * Bugs * fix IE bugs * heading doesn't work (1.6M2) * tool bar separator not shown (1.6M2) * fix cross-browser bugs * pass syntax id to ConversionFilter (xwiki/2.0 currently hardcoded) (1.6M2) * skip tool bar separator for unsupported features (1.6M2) * fix output bugs * return should generate a new paragraph (1.6RC1) * nested lists should be wrapped by a list item (1.6RC1) * HTML special characters are replaced by entities (1.6RC1) * Features waiting for rendering support * justify (left, center, right, full) (?) * indent / outdent (currently supported only for nested lists) (?) * font (family, size) (?) * color (background, foreground) (?) * New features * remove formatting (1.6M2) * insert symbol (1.6M2) * monospace (tt) (1.6RC1) * insert link / unlink (1.6RC1) * insert image (1.6RC1) * insert attachment link (1.6RC1) * UI * infrastructure * configurable menus (1.6M2) * generic dialog box with optimised dragging and glass panel in modal mode (1.6M2) * generic tray (1.6M2) * link menu * dialogs & trays for insert link / image / attachment (1.6RC1) * Server side * services for insert link / image / attachment (1.6RC1) So WDYT? Marius

3 5

[xwiki-devs] XWiki - HSQL to display Current Space
by Prathap Pandian 02 Sep '08

02 Sep '08

HI, How to view current space using HSQL. For Example: select prop.value from BaseObject as obj, StringProperty as prop where obj.className='Blog.Categories' and obj.name = 'Blog.Categories' and prop.id.id = obj.id and prop.id.name='name'* and prop.value = $doc.web* whether above one is correct..? -- Prathap

1 1

[xwiki-devs] HtmlCleaner 2.1
by Vincent Massol 02 Sep '08

02 Sep '08

Just to let you know that HtmlCleaner 2.1 is now out. http://htmlcleaner.sourceforge.net/release.php Apparently they have implemented some of our requests in there so that's cool. If someone (daning?) is intersted in refactoring our HMTL Cleaner to use it that would be great. Thanks -Vincent

2 2

[xwiki-devs] [Rendering] verbatim syntax for xwiki
by Vincent Massol 02 Sep '08

02 Sep '08

Hi, Just to let you know that the following verbatim syntax is now implemented for the XWiki Syntax v2.0: This is {{{***verbatim**}}} {{{ verbatim on several lines }}} Or even: abc{{{def{{{verbatim}}}ghi}}}jkl (in this case the "def{{{verbatim}}}ghi" is not rendered). Thanks -Vincent

1 0

[xwiki-devs] Open questions for the XWiki syntax v2.0
by Vincent Massol 02 Sep '08

02 Sep '08

Some open issues/questions: 1) I think we need a syntax for escaping a block of text. I'd propose using {{{whatever here}}} (same as creole and confluence). We could do it with a macro but I don't know how we could implement it easily... 2) Do we want double curly braces for macros or simple ones: {{macro/}} or {macro/}. If we use simple ones then it won't be easy to enter { and } chars in a text (they would need to be escaped) and since we've decided to have double chars for items ( **, --, ~~, etc) we might as well do that for macros. 3) Do we want to support images in links. For example: [[image:someimage.png]]? We already support URIs in links, such as mailto: so maybe it wouldn't be too hard to support images too I guess. Or do we want only the Image macro? A related question is do we support http images (http://.../someimage.png) inside links and as an inline element directly in the text? 4) Tables: do we keep the table macro or do we want a wiki syntax for tables. Thanks -Vincent

6 19

[xwiki-devs] reloading macros.vm
by Paul Libbrecht 02 Sep '08

02 Sep '08

Hello Xwiki developers, does anyone know how to reload macros.vm ? I seem to need a webapp- reload for this which is quite expensive. paul

2 1