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 <i> to <em>, <b> to <strong>. 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 <p class="underline">
centre -> <span style="text-align:center">
font -> <span style="color:red;font-family=Arial;font-size=12;">
basefont -> <span style="color:red;font-family=Arial;font-size=12;">
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
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
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/
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/
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
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
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
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
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
