The XWiki development team is proud to announce the availability of XWiki
7.1 Milestone 2.
This second milestone release brings a new and experimental flavors
mechanism and a new debug mode, together with various mail and job module
under-the-hood improvements.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki71M2
The following people have contributed code to this release:
Denis Gervalle, Eduard Moraru, Guillaume Delhumeau, Thomas Mortagne,
Vincent Massol
Thanks for your support
-The XWiki dev team
Hi devs,
For the record this is not a final/complete proposal. Lots of things would
still need to be decided/prototyped, but the purpose of this mail is to
iterate and gather feedback on these ideas.
This iteration is showcasing a menus/actions organization, integrated
inside a mobile-oriented skin.
Proposal:
http://design.xwiki.org/xwiki/bin/view/Proposal/MacawSkin
Thanks,
Caty
Hi guys,
I just noticed (while updating the screen shots for the Solr Search UI
documentation [1]) that searching for "blog" doesn't match "Blog.News"
from the category of BlogIntroduction any more as indicated in [2].
Debug mode view shows me that "Blog.News" is indexed as "blog.new"
which means the text is not split in "blog" and "news" as I would have
expected in this case.
After checking the Solr schema configuration I understood that this is
normal considering that we use the Standard Tokenizer [3] for English
text which has this exception:
"Periods (dots) that are not followed by whitespace are kept as part
of the token, including Internet domain names."
Further investigation showed that before 6.0M1 we used the Word
Delimiter Filter [4] for English text but I changed this with
XWIKI-8911 when upgrading to Solr 4.7.0.
I then noticed that the Solr schema has both text_en and
text_en_splitting types, the later with this comment:
A text field with defaults appropriate for English, plus aggressive
word-splitting and autophrase features enabled. This field is just
like text_en, except it adds WordDelimiterFilter to enable splitting
and matching of words on case-change, alpha numeric boundaries, and
non-alphanumeric chars. This means certain compound word cases will
work, for example query "wi fi" will match document "WiFi" or "wi-fi".
So in case someone wants to use this type instead for English text he
needs to change the type in:
<dynamicField name="*_en" type="text_en" indexed="true" stored="true"
multiValued="true" />
The question is whether we should use this type by default or not. As
explained in the comment above, there are downsides.
Thanks,
Marius
[1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Solr+Search+Application
[2] http://extensions.xwiki.org/xwiki/bin/download/Extension/Solr+Search+Applic…
[3] https://cwiki.apache.org/confluence/display/solr/Tokenizers#Tokenizers-Stan…
[4] https://cwiki.apache.org/confluence/display/solr/Filter+Descriptions#Filter…
Hi all,
some time ago we wrote about an idea of having an extensible API for
accessing structured data.
The final goal is to have a uniform API for accessing structured data
both on the client (Javascript+REST) and on the server.
We have written a little design document that I am submitting to the
list for comments:
http://design.xwiki.org/xwiki/bin/view/Proposal/ExtensibleAPIforaccessingst…
This idea is also related to other ones, like providing a way for
dynamically extending the REST API, and also to the integration with
client side frameworks like AngularJS.
Thanks,
Fabio
Dear XWiki devs
I recently wanted to refactor the usage of XWikiContext and XWikiDocument
in my code with DocumentAccessBridge and DocumentModelBridge.
I however was suprised that many methods in DocumentAccessBridge throw
java.lang.Exception. This is generally considered bad practice since it
forces all clients to catch java.lang.Exception and therefore also
unchecked Exceptions - from which the client potentially can't or shouldn't
recover.
For in depth arguments see e.g. Joshua Bloch's "Effective Java" where he
states to "use checked exceptions for recoverable conditions and runtime
exceptions for programming errors", "throw exceptions appropriate to the
abstraction" and "always declare checked exceptions individually".
Can somebody explain to me the reasoning behind throwing
java.lang.Exception in this interface? Are there any plans to deprecate and
replace it by an interface without this caveat?
Thanks
Marc
synventis GmbH
The XWiki development team is proud to announce the availability of
XWiki 7.1 Milestone 1.
This release improves the Solr Search UI by making it responsive on
small screens. The users can now sort, paginate and filter the search
results without a page reload. A summary has been added to the
extension diff view in order to ease the navigation of the local code
changes. The WatchList performance has been improved, especially for
the Realtime notification option. The developers can now trigger old
Prototype event listeners from jQuery. A new API is available to
escape wiki syntax. 49 bug fixes and 29 improvements complete this
release and make it worth trying.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki71M1
The following people have contributed code to this release:
Clemens Robbenhaar, Denis Gervalle, Ecaterina Moraru (Valica), Eduard
Moraru, Gabriela Smeria, Guillaume Delhumeau, Jean SIMARD, Manuel
Smeria, Marius Dumitru Florea, pabro, Petr Abrahamczik, Sergiu
Dumitriu, Thomas Mortagne, Victor Rachieru, Vincent Massol
Thanks for your support
-The XWiki dev team