Hi Gilles,
I have commented on http://jira.xwiki.org/jira/browse/XWIKI-951.
Could you please let me know if it's ok to apply your patch as is or
if you still need to submit and updated version of it.
Thanks
-Vincent
Hi,
I admit it: I'm not an expert in I8N. However I realize that XWiki
being a wiki we need to have strong I8N features so I'm trying to
catch up with I8N knowledge...
I started yesterday by reading this excellent short tutorial http://
www.joelonsoftware.com/articles/Unicode.html (The Absolute Minimum
Every Software Developer Absolutely, Positively Must Know About
Unicode and Character Sets (No Excuses!)). It's very good and an easy
read. I recommend it to everyone.
This led me to a few questions:
1) Is UTF8 supported on all platforms? Is it supported on mobile
platforms for example?
2) I see in our encoding guide on http://www.xwiki.org/xwiki/bin/view/
AdminGuide/Encoding that we need to set the encoding for the
container. Why is that required? The servlet container reads pages
which have the encoding specified (using Content-Type meta data), so
why does it need to be told about the encoding to use?
3) I see that in our standalone installation we use -
Dfile.encoding=iso-8859-1. Now that I've read Joel's tutorial it
seems to me this is not going to work for everyone and that we should
rather use -Dfile.encoding=UTF-8 by default. WDYT?
4) Should we use the platform encoding or default to using UTF-8 all
the time? (this question is related to 1)). I think we should use the
platform encoding but I'm curious to know what others think.
5) Jackson Wang is proposing in a patch to modify readPackage like this:
private Document readPackage(InputStream is) throws
IOException, DocumentException
{
- byte[] data = new byte[4096];
+ //UTF-8 characters could cause encoding as continued bytes
over 4096 boundary,
+ // so change byte to char. ---Jackson
+ char[] data = new char[4096];
+ BufferedReader in= new BufferedReader(new InputStreamReader
(is));
StringBuffer XmlFile = new StringBuffer();
int Cnt;
- while ((Cnt = is.read(data, 0, 4096)) != -1) {
+ while ((Cnt = in.read(data, 0, 4096)) != -1) {
XmlFile.append(new String(data, 0, Cnt));
- }
+ }
return fromXml(XmlFile.toString());
}
However with my new understanding I'm not sure this would help as
char are stored on 2 bytes in Java and UTF-8 encoding can store on up
to 4 bytes. Am I correct?
However, I would rather use http://jakarta.apache.org/commons/io/api-
release/org/apache/commons/io/IOUtils.html#toString
(java.io.InputStream) than code it ourselves... Sounds safer,
shorter, less maintenance, etc to me... :)
Thanks for your help
-Vincent
I am currently working on improving the documentation about the default
XWiki on XWiki.org. In the process, a lot of information is added, but
Vincent pointed out to me that this information is sometimes related to the
default behavior of any XWiki (eg, "a page is edited when clicking on the
"edit" button) and at some other times related to a particular XWiki (eg,
"the search page looks like this if you are using the XWiki 1.0 B6 XAR").
The problem lies in the fact that a new user might get confused when
accessing the documentation and not be able to distinguish between necessary
features (which are included in XWiki's core, hence present on every XWiki)
and contingent features (which depend on the XAR used for instance).
It would be useful to find a solution in order to separate the different
kinds of documentation on XWiki.org. In the process, it might be necessary
to keep in mind that we could someday release different XARs aiming at
different purposes ("XWiki for developers", "XWiki for architects", ...)
with a new release of the core.
There are different types of potential solutions to this:
- Creating badges saying "this refers to the default XWiki instance /
XWiki 1.0B5 Xar / Another XAR only" and placing it where needed;
- Creating an entirely different section to document features present
only on a specific XWiki instance / xar;
- Another type of solution - original input welcome :-)
And then the whole thing needs to be clear and easy to browse for users
seeking for a specific piece of information... Any suggestions?
Guillaume
--
http://wikibc.blogspot.com/
Hi,
I'd like to propose the following:
* Release RC1 by end of next week with as many important bugs fixed
as possible
* Wait for 1 week after RC1 is released and declare RC1 to be 1.0
final is no critical/blocking bugs are found
* Dedicate the XWIKI 1.0 branch to contain ONLY bug fixes going forward
* Put new features/improvements ONLY on trunk
* Release 1.0.1 2 to 3 weeks after 1.0 is released with bug fixes
* Define a roadmap for 1.1 in term of what we want in it. It should
be achievable within 3 months.
* Change the version on trunk to be 1.1-beta-1 and release after 2-3
weeks. Increase to 1.1-beta-2 and repeat, etc. till we either reach
something close so the initial roadmap for 1.1 in term of features or
we reach the 3 months delay. In any case, release 1.1 at that time.
* I propose to NOT create a branch for 1.1 till the final 1.1 is
released and when it is I propose we don't release 1.0.x releases any
more and instead release 1.1.x bug fixes releases (we don't have
enough manpower to support more than 2 releases in parallel, it's
already going to stretch us a lot).
WDYT?
Thanks
-Vincent
Hi,
I had some time in the train yesterday so I thought about what a new
Importer architecture would look like.
First the reason for changing the current one (which is located in
the Package plugin):
* "bad" design (everything is mixed up in one big class, not modular)
and too complex to maintain
* cannot import HTML, plain text, etc
* cannot convert from one wiki syntax to another
Proposal
=======
* A Importer interface to represent the different importers
o import(Converter converter, DocumentImportFactory factory)
o setFilter(ImportFilter filter) : to decide what document
to import
* A Converter interface to convert original content before it's
imported into a page
o OutputStream convert(InputStream originalContent)
* A DocumentImportFactory interface for delegating how pages are
created. This is important as there are different strategies for
finding out the following data from the original content:
o Language
o Target Space
o Target Page name
o Objects to attach
o Attachments
o Versions
o Author
o API:
+ XWikiDocument createDocument(String
originalFileName, InputStream contentAfterConversion)
+ setMode(REPLACE || APPEND): whether to create a
new version or replace any existing doc
Examples of implementations:
* For Importer: FileImporter, DirectoryImporter, ZIPImporter,
ZipURLImporter, JARImporter
* For Converter: PlainTextConverter, HTMLConverter,
TWikiConverter, ConfluenceConverter, XWikiXMLConverter (for
converting documents in XWiki XML format)
* For DocumentImportFactory: XARDocumentImportFactory,
ExpandedXARDocumentImportFactory, DefaultDocumentImportFactory (uses
the file name as page name and parent directory as space, etc)
Examples of using it
================
* A XAR file
o new ZipImporter(new File(".../.xar"), new
XWikiXMLConverter(), new XARDocumentImportFactory(new File(".../.xar")))
* A single HTML file
o new FileImporter(new File(".../.html"), new HTMLConverter
(), new DefaultDocumentImporterFactory())
* A zip file containing TWiki pages
o new ZipImporter(new File(".../.zip"), new TWikiConverter
(), new DefaultDocumentImporterFactory())
* An expanded directory of HTML files
o new DirectoryImporter(new File(".../somedir"), new
HTMLConverter(), new DefaultDocumentImporterFactory())
I've put all this on http://www.xwiki.org/xwiki/bin/view/Idea/
NewImporterArchitecture but I think it's better to discuss it here as
email is better for discussions...
Note: I'm not planning to implement this yet as our first priority is
still the 1.0 release but once it's released, I'm volunteering for
implementing it, using a component strategy (cf new V2 architecture).
WDYT?
Thanks
-Vincent
Hi,
I noticed that the i18n.java class in the core is not used anywhere
(at least I couldn't find any reference to it). Thus I'd like to
remove it. Ok with everyone?
Note: In addition it's badly named as a class in java should start
with an uppercase letter...
Thanks
-Vincent
Hi all,
I tried to use the xredirect functionnality on a confirm delete action
I would like the URL :
/xwiki/bin/delete/Plans/aaaa?confirm=1&xredirect=/xwiki/bin/view/Plans/bbbb
to delete the doc aaaa and then redirect to the doc bbbb
If I remove the confirmation (confirm=1) my redirect is OK but, as I
don't confirm deletion, my doc aaaa is still here.
I patched my own version of XWiki because I need it, but I would like to
know if this is volunteer (and so why ?) or if I should submit my patch.
Thanks
--
Arnaud Thimel
Société Code Lutin - http://www.codelutin.com
The XWiki development team team is pleased to announce the
availability of the 1.0 Beta 6 release.
Go grab it on http://www.xwiki.org/xwiki/bin/view/Main/Download
This release is the last before the 1.0 RC1, which gets us one step
closer to the 1.0 final release planned for mid/end April.
The focus for this release was still bug fixing but this release
brings other nice
improvements:
* XWiki skins have been renamed using bird names: the old xwiki10b1
is now albatross, the old default skin is now dodo and the old
xwiki10 skin is now finch
* New rename feature to rename pages and all backlinks leading the
page to rename.
* New check box interface for tags. The Tag feature now supports 3
interfaces: a list of tags separated by commas or pipes symbols, a
checkbox list of tags to select/unselect and point-and-click list of
tags to select/unselect.
* New Text Analyzer plugin.
* Upgraded to Velocity 1.5 final
* Improved PDF output
* GraphViz plugin is now off by default and needs to be enabled in
xwiki.cfg
* Added possibility to restrict the possible languages available on a
given wiki
* New Blog panel available that lists all blog categories
* New footnote macro. In addition the Albatross skin has been
modified to display automatically footnotes added with this macro.
See the full release notes on http://www.xwiki.org/xwiki/bin/view/
Main/ReleaseNotesXWiki10Beta6
Enjoy
-The XWiki development team
Hi everyone,
I've uploaded the 1.0 Beta 6 binaries on http://193.231.30.155/10b6/.
We need a few people to test it out and verify it works fine for
them. Then, once we get 3-4 positive answers, I'll do the official
release on ObjectWeb and announce the releases.
Here are the release notes for 1.0 Beta 6:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWiki10Beta6
In short:
* Lots of bugs fixed
* XWiki skins have been renamed using bird names: the old xwiki10b1
is now albatross, the old default skin is now dodo and the old
xwiki10 skin is now finch
* New rename feature to rename pages and all backlinks leading the
page to rename. There are some known limitations:
o backlinks have to be turned on (they are turned on by
default but if you have turned them off, rename will not rename
backlinks and you'll have to turn them on again to benefit from this
feature)
o backlinks in objects attached to pages are not currently
renamed
o backlinks are saved when a page is saved thus it may happen
with a clean XWiki database that backlinks are not saved. In this
special case, you can call the following in a page to refresh all
links (you'll need to be admin to do this):
$xwiki.refreshLinks()
* New check box interface for tags. The Tag feature now supports 3
interfaces: a list of tags separated by commas or pipes symbols, a
checkbox list of tags to select/unselect and point-and-click list of
tags to select/unselect.
* New Text Analyzer plugin.
* Upgraded to Velocity 1.5 final
* Improved PDF output
* Rename method renamed from Document.renameDocument() to
Document.rename()
* GraphViz plugin is now off by default and needs to be enabled in
xwiki.cfg
* Added possibility to restrict the possible languages available on a
given wiki
* New Blog panel available that lists all blog categories
* New footnote macro. In addition the Albatross skin has been
modified to display automatically footnotes added with this macro.
I've tested it on my side so here's my +1 for releasing it
Thanks everyone for your help
-Vincent
