Hello,
I am working on creating blog entries using xwiki. I was wondering if it would be possible to create a template for the blog entries so that they will be more structured?
Thank you for your time and help!
Hande Aksac
Hi,
Since I'm rewriting the new Rendering component
(see http://dev.xwiki.org/xwiki/bin/view/Design/NewRenderingArchitecture)
, we need to finalize the new syntax we want to have.
Right now I'v planned to use the same wiki syntax as now
(http://platform.xwiki.org/xwiki/bin/view/Main/
XWikiSyntax#HTextStyles) with only one change: all macros now need to
be closed.
For example: {macro}...{/macro} and {macro:text|param=value|.../}
Is that ok with everyone or do we want to make changes?
Thanks
-Vincent
We need a deprecation strategy, i.e. decide for how long we keep
@deprecated methods/classes.
I propose to keep them for 2 full releases after the current version
is released as final.
For example if a method is deprecated in, say Core 1.3M2 then the
method will be removed in 1.6M1. Of course any major new release can
deprecate anything so a XWiki 2.0 is expected to break backward
compatibility.
So for methods deprecated in 1.0 we can remove them in 1.3M1, M2, etc.
WDYT?
If ok then I'll add this to our dev practice guide too.
Note that for this to be easy anyone deprecating methods should add
the information of when it was deprecated. For example:
/**
* @param time the time in milliseconds
* @return the time delta in milliseconds between the current
date and the time passed
* as parameter
* @deprecated replaced by {@link
com.xpn.xwiki.api.Util#getTimeDelta(long)} since 1.3M2
*/
public int XWiki.getTimeDelta(long time)
{
return this.util.getTimeDelta(time);
}
Here's my +1
Thanks
-Vincent
Hi all,
I am working with a XE 1.3.8295 installation where RTF export works
fine. But it will be great programmatically control the output layout
(namely, pictures printed size, space before and after paragraphs or
headings, space before and after pictures, footnotes,...
Please, could you point me in the right direction to face this requirement?
Thanks indeed for your help.
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
Hi fellow XWikiers,
I've been spending some time thinking about the new User Interface we might
want to build for the new WYSIWYG editor. I've posted the ideas I gathered
so far on this page :
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface .
I'd be glad to get some feedback either on the list or in comments right on
the page in order to see whether any given approach clinches or clashes with
your own conceptions of a great rich text editor.
Please bear in mind that I'll probably be adding content to the page on a
regular basis in days to come in order to account for the feedback received
- if any.
In case of an absence of feedback, well, I guess we'll be able to assume
safely that the new WYSIWYG editor doesn't matter that much in the end and
stop its development altogether ;-)
Looking forward hearing from you guys (and girls),
Guillaume
Hi,
I think I've finished enough in the new rendering implementation so
that we should now start defining formally the new XWiki 2.0 syntax.
However before we do that let me highlight one important limitation
due to the underlying frameworks we use (wikimodel in this case):
Wikimodel is using a JavaCC grammar and thus is not able to do look
ahead and backtracking (ANTLR can do it, but even if JavaCC could do
it it would still be too expensive to use). This means that wikimodel
is not able to support the following example:
This is a * that is not a bold.
When wikimodel sees one of XWiki's special char (like the star for
bold) it'll put everything that comes after as bold, till it find
another star or till the end of the document.
There are 2 solutions out of this:
* We don't allow users to enter non-escaped star for example.
* Or better we change our syntax for bold so that it uses a 2 chars.
For example **. It's less likely people will use 2 stars in their
content and this is the reason most wikis use 2 chars. This is also
consistent with our other syntaxes for underline, strikethrough,
italics, etc. Note that this is also inline with the creole syntax: http://www.wikicreole.org/
The same problem exists for links. We're currently using single
brackets which means people cannot use brackets in their text. I'd
also propose to use double brackets for links as in: [[This is a
link]]. Again this is consistent with the rest.
There are several other topics to address but let's start with Bold
and Link syntaxes right now. Once we agree on them, I'll do the
following:
* Create a XWiki 2.0 syntax page on xwiki.org and put Bold and Linkj
syntax there
* Send change requests to wikimodel for the changes we decide
* Adapt the new rendering module code
* Send other emails for remaining syntax elements
To summarize the vote here is about:
* Using ** for bold in the new XWiki 2.0 syntax
* Using [[ for links in the new XWiki 2.0 syntax
Here's my +1 to both.
Thanks
-Vincent
Hi everyone,
For your information, I started coding a "Texifier", i.e. a tool that
converts XWiki pages into a Tex file:
http://playground.xwiki.org/xwiki/bin/view/Main/Texifier
It relies on WikiModel and was written mainly for generating PDF from
XWiki pages using the power of pdflatex.
Comments welcome!
Cheers
Stéphane
Hi,
Does anyone know why we have the following LANG property defined in
our startup scripts:
#!/bin/sh
export LANG=fr_FR.ISO8859-1
JETTY_HOME=.
JETTY_PORT=8080
JAVA_OPTS=-Xmx300m
java $JAVA_OPTS -Dfile.encoding=iso-8859-1 -Djetty.port=$JETTY_PORT -
Djetty.home=$JETTY_HOME -jar $JETTY_HOME/start.jar
I think this is bad as it's french and I don't think we should set it
for the user.
That said, if it's there its probably because it was required in the
past, hence my question here.
To summarize: anyone sees any issue if I remove that "export LANG" line?
Thanks
-Vincent
I'd like to bring forward the release dates for XE 1.5 final, as follows:
* 1.5RC1 - 07/07
* 1.5Final - 15/07
I'd also like to create a branch for 1.5 since it's now in RC stage
and trunk will become 1.6-SNAPSHOT so that committers eager to work on
1.6 can start doing so and so that we're not tempted to push non bug
changes in 1.5.
Reasons:
* Some of us would like to work on 1.6 (like Jerome who'd like to fix
our captcha mechanisms)
* There's an ongoing vote to drop the 1.3 branch, as usual we'd have 2
branches with 1.4 and 1.5 (our standard rule is to support 2
versions).
Here's my +1 to both the new dates and the branch creation.
Thanks,
JV.