Hi devs,
I'm currently working on documents we create from core/plugins or
those we bundle in XARs (xwiki/2.0 conversion, filling title field,
etc).
I'd like to take advantage of this to discuss about the author we use
in those documents. We currently have 2 different behaviors:
- classes created from the core usually have their author set to ""
- classes created from plugins (skinx, scheduler, etc) or bundled in
our XARs usually have their author set to "XWiki.Admin"
It lacks consistency and it can lead to security issues. If for some
reason the administrator of a wiki decide to delete the XWiki.Admin
account some can re-create it and gain the authorship -- thus the
right to delete -- plenty of XE documents.
We can decide to:
1) Only tackle the consistency problem and use "XWiki.Admin" everywhere
2) Solve the 2 problems by extending core policy to all our documents,
ie. use "" everywhere
3) Solve the 2 problems by using a special username everywhere, like "System".
Here's my +1 for 3), rationale:
- 1) is only a quick fix and core shouldn't be aware of a user that
comes with XE,
- 2) is fine except that not having an author seems unnatural from a user POV.
- In the future we could decide to have special handler for the
"System" user, like pointing to a page explaining that it is a
pseudo-user when we use $xwiki.getLocalUserName("System").
JV.
Hi XWiki Community,
I'm happy to share some good news for the XWiki Platform and Community
that we got today.
We (XWiki SAS) had responded to a French Government Call for Web 2.0
Projects in early July and we got the good news today that our project
was selected with 43 other projects (among 340 proposals) to receive
state funding.
In this project, where the research entity INRIA/ECOO and Open Source
company Mandriva are also participating, we have proposed to enhance
XWiki's social features and integrate Real-Time capabilities in XWiki
(both for editing information and viewing information in real-time).
We already worked with INRIA/ECOO on XWiki Concerto (offline and mobile
XWiki) which is the specialist in France and probably Europe of
Operational Transformation Technology (which is used in Google Wave for
real-time capabilities).
We'll talk more about the features this will bring to XWiki when we
formally launch the project. We don't know yet how fast it will go to
formalize the public funding and start the project (it usually takes at
least a few month).
It's great to be able to continue to work on innovative technologies in
the Wiki space, which is not that easy as we have already so much work
to package and polish all the great ideas and features that are already
in the XWiki platform.
It's also great to see the progress the XWiki software has made in the
last year, from XWiki 1.8 to XWiki 2.0 coming out soon. The new
rendering, new Wysiwyg editor, the Office Importer and now the new skin
are making XWiki do a lightyear of progress in just one year !
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi,
I'm working on http://jira.xwiki.org/jira/browse/XWIKI-4345 and in
order to implement the logic in contenview.vm I need to perform some
regex find() from velocity.
I'd like to propose introducing a new velocity tool for this:
#-# velocity.tools = regextool = org.xwiki.velocity.tools.RegexTool
Right now RegexTool has one method:
/**
* @param content the content to parse
* @param regex the regex to look for in the passed content
* @return empty list if the passed regex doesn't match the
content or several {@link RegexResult} objects
* containing the matched position and matched content
for all capturing groups, the first group
* representing the whole . The first object is
represents the entier pattern
*/
public List<RegexResult> find(String content, String regex)
{
List<RegexResult> result = new ArrayList<RegexResult>();
Matcher matcher = Pattern.compile(regex,
Pattern.MULTILINE).matcher(content);
if (matcher.find()) {
for (int i = 0; i < matcher.groupCount() + 1; i++) {
result.add(new RegexResult(matcher.start(i),
matcher.end(i), matcher.group(i)));
}
}
return result;
}
WDYT?
FYI here's what I currently have in contenview.vm:
##
----------------------------------------------------------------------------
## Remove the first rendered H1 or H2 if the following conditions are
met:
## - the document's title is set
## - the title compatibility flag is on
## - the title extracted from the rendered content is the same as the
set title
## We need to do this since we've changed how titles are used and we
need to
## ensure we don't break existing documents that have not yet migrated
to the
## new way.
##
-----------------------------------------------------------------------------
#set ($titleToDisplay = $tdoc.displayTitle)
#if ($cdoc.title && $cdoc.title.length() > 0)
## Look for first H1 or H2 either in lowercase or uppercase
#set ($regexResult = $regextool.find($renderedContent, "<[hH][12].*?
><span>(.*)</span></[hH][12]>"))
#if (!$regexResult.isEmpty() &&
$regexResult.get(1).group.equals($titleToDisplay))
#if ($regexResult.get(0).end <
$mathtool.sub($renderedContent.length(), 1))
#set ($renderedContent = "${renderedContent.substring(0,
$regexResult.get(0).start)}$
{renderedContent.substring($regexResult.get(0).end)}")
#else
#set ($renderedContent = $renderedContent.substring(0,
$regexResult.get(0).start))
#end
#end
#end
Note that the other option is to introduce yet another API in Document
for this but it doesn't look right to me.
Here's my +1
Thanks
-Vincent
Hi,
In multiple cases, we have heard the requirements to manage simple 2 or
3 column layouts in the Wysiwyg. This has come up with some users and is
a need in the Socracy project (http://www.socracy.org).
I've thought a bit more about this need and realized we could handle it
quite simply using our already available Table feature in the Wysiwyg.
For this the only thing we actually need would be to be able to edit the
"class" being assigned to a table.
I've made some CSS to show the results that we could have using such a
class:
http://incubator.myxwiki.org/xwiki/bin/view/Test/TestColumns
The only special thing that these tables have in the wiki syntax is a
class assigned:
(% class="columns2" %)
or
(% class="columns3" %)
The rest is CSS magic put in the skin.
The way I see it would be to have the possibility to choose between
different classes when creating or editing table properties. The list of
available classes could be a preference set in the Wiki, this way we
could extend the styles available for tables.
Not only we could handle columns this way but we could also have
additional styles for table (home page tables or table to show numbers,
etc..).
This is not too much work in the Wysiwyg and can provide quite some
benefits to make nice presentations in XWiki.
WDYT ?
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi,
Try editing http://localhost:8080/xwiki/bin/edit/Main/Dashboard
You'll get "Document in space null" and "Recent Changes for space null"
And you won't see any changes, etc.
There seems to be a context problem somewhere.
Thanks
-Vincent
Hi devs,
I upgraded the 2.1 branch to GWT 1.7 and I'm waiting for Hudson to run
the selenium tests. If everything goes well I'd like to upgrade the 2.0
branch too. The main reason for doing this is to improve the support for
IE8 (XWIKI3446 and XWIKI3448 for instance).
Note that I ran the unit tests in IE8 and I got the same results as in
IE6/7.
Here's my +1
Thanks,
Marius