Hi,
Im trying to fix http://jira.xwiki.org/jira/browse/XWIKI-4274
Basically if you do $xwiki.getDocument("someDoc").getRenderedContent()
it'll get executed in the context of the current doc which I believe
is wrong especially since other signatures of getRenderedContent()
execute in the target document's context.
I have fixed this locally but found that admin.vm for example is
assuming that getRenderedContent() will get executed in the context of
the calling doc (i.e. XWiki.Import when doing an import for example).
FYI the chain flow is admin.vm -- getRenderedContent() -->
XWiki.AdminSheet --> XWiki.AdminImportSheet --> importinline.vm, which
requires the current doc to be XWiki.Import (to get/put attachments
from/to it).
I can fix this easily using a new getRenderedContent signature I've
introduced.
However I'm wondering if we have other places that incorrectly use
getRenderedContent() and assume it won't be rendered in the context of
the target document.
Is this change too dangerous to make? If not know, we'll need to it
quickly (2.1M1?) since it's an important bug IMO.
WDYT?
Thanks
-Vincent
Could be useful:
http://ocpsoft.com/prettytime/
Idea of usage: For ex we could use that to show the last modified
document dates for dates in the past week (for ex):
"Document created 2 days ago"
It's in the maven central repo and it's under LGPL
-Vincent
Hi Everyone!
I have read this document "Writing GWT applications in XWiki" (
http://dev.xwiki.org/xwiki/bin/view/Drafts/WritingGWTApplicationsInXWiki)
And I know how to develop GWT module for xwiki now. I also have read the
document "WYSIWYG Editor Module" (
http://code.xwiki.org/xwiki/bin/view/Modules/WysiwygEditorModule). I
followed the instruction which tried to integrate the WYSIWYG editor(GWT
application) in wiki pages, and I put the following code in my wiki editor:
"{{html}}
<script type="text/javascript" src="XWikiWysiwyg.js"> alert('WYSIWYG code is
loaded!'); </script> <textarea id="demo"></textarea> <script
type="text/javascript"> Wysiwyg.onModuleLoad(function() { new
WysiwygEditor({hookId:'demo'}); alert('WYSIWYG code is loaded!'); });
Wysiwyg.onModuleLoad(function() { editor = new WysiwygEditor({hookId:
'demo'}); }); }); </script> {{/html}}"
After saved, it only display a blank text area without any sign of WYSIWYG
editor, also there is no alart 'WYSIWYG code is loaded!' popup. Can you help
me figure it out what is wrong with it?
I am planing to develop a tree view using GWT to display Design Rationale
Element. Could you give me some ideas of after my development, how can I
embeded the GWT application into Xwiki pages and interact with the GWT
application?
Thank you very much!
Leon
Hi Devs,
I'd like to introduce a new configuration property that would define
at which level users should be handled in a farm.
See the proposition about the new entry in xwiki.properties, it should
be self-explanatory:
--------------------------------8<--------------------------------
#-# [Since 2.5M1]
#-# Define at which level users and groups should be handled in the
farm. Available modes:
#-#
#-# mixed (default):
#-# - user registration available in the main wiki and local wikis
#-# - users from the current wiki and the main wiki will be displayed
in the rights interface and user suggests
#-# - user administration is present in all the wikis
#-#
#-# local:
#-# - user registration available in the main wiki and local wikis
#-# - only users from the current wiki will be displayed in the rights
interface and user suggests
#-# - user administration is present in all the wikis
#-#
#-# global:
#-# - user registration available in the main wiki only, the register
link in local wikis will point to the main wiki
#-# - only users from the main wiki will be displayed in the rights
interface and user suggests
#-# - user administration is present in the main wiki only
core.virtual.users=mixed
-------------------------------->8--------------------------------
More details are available here:
http://dev.xwiki.org/xwiki/bin/view/Design/UsersModule
WDYT ?
Thanks,
JV.
Sergiu,
You are in charge of the email this page feature for 2.6. Is there a
design page for it ? I wanted to suggest some additional functionnality
to that feature if you have time for it.
When sending the page or when saving (the email this page feature could
be just under the save button), the user would have the ability to ask
for an automatic email this page on every change (content and comments).
The user would be able to say:
[ ] All Contributors
Additional users or groups: [ ]
Additional manual emails: [ ]
[ ] email all changes
Then automatically the email this page would be activated on each change.
A required feature would be an exclude list and a way for the user to
unsubscribe.
Finally we could add an email box so that we can load comments sent as a
reply to an email sent by the wiki.
The rationale for this feature is that when working on a document that
requires some discussion and validation, the email discussion is not
captured and the changes in the wiki are not triggering a fast enough
reaction thus slowing down the discussion around the document (I know
the Watch List exists, but since it requires manual subscription, most
participants won't do it and the speed of notification of the watch list
is not fast enough for discussion).
WDYT ?
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi devs,
I've been working on http://jira.xwiki.org/jira/browse/XE-721 and it's
done on my local. This is the recent changes macro based on the current
implementation (not the activity stream one), but the idea is that we'll
rewrite it to display recent activity in the future. I will commit it
for the moment, in the 2.6 trunk, as is, but I would like to discuss
here the name of the macro and its parameters:
Macro name:
recentchanges, changes, activity, recentactivity
Parameters:
* rss link should be shown at the bottom of the changes table (boolean):
showRss, rss
* minor changes are shown or not (boolean, default false): showMinor, minor
* shows "see modifications" link next to entries (boolean, default
true): showDiff, showDifferences, diff, differences
* number of changes to show (number, 0 means "all", defaults to 30):
changesNb, changesCount, number, count, limit
* tags of documents to show chages for (comma separated list): tag, tags
* spaces of documents to show changes for (comma separated list): space,
spaces
* authors of documents to show changes for (comma separated list):
author, authors
Note that the types cannot be enforced since it's a wiki macro, I put
them there just for orientation.
I'd go for
activity rss minor diff count tags spaces authors .
WDYT?
Thanks,
Anca
In light of the need for better attachment handling, I spent the past few days working on the basic
framework for a new module to support large objects. The code can be viewed here:
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-blob/src/main/java…
Use case #1: Multiple methods of storing content and the ability to define more.
Use case #2: Thread safe locking to prevent concurrent modifications from damaging content.
Use case #3: ACID commit/rollback protection.
The API user has 2 access points.
BinaryObject is a thread safe interface with ACID and option of using OutputStream or InputStream to
set and get data.
StorageItem is a simplistic interface modeled after a small subset of the methods in java.io.File.
If you create a component which implements StorageItem, BinaryObjectProvider will allow you to
access a BinaryObject which uses your StorageItem for persistent storage.
Example:
@Requirement
private BinaryObjectProvider provider;
private BinaryObject binaryObj;
public void initialize()
{
this.binaryObj = this.provider.get("myImpl");
}
"myImpl" is the hint for the StorageItem which you may define.
The next step is of course to add versioning support but I think this will provide a solid
foundation to build that on.
WDYT?
Caleb
On Oct 31, 2010, at 5:48 AM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2010-10-31 05:48:50 +0100 (Sun, 31 Oct 2010)
> New Revision: 32285
>
> Modified:
> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/pdf/impl/PdfExportImpl.java
> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/pdf/impl/PdfURLFactory.java
> Log:
> XWIKI-5639: PDF export doesn't contain images if the document name contains non-ASCII characters
> Fixed.
[snip]
> - for (int i = 0; i < filelist.length; i++) {
> - filelist[i].delete();
> + try {
> + FileUtils.deleteDirectory(tempdir);
> + } catch (IOException ex) {
> + // Should not happen, but it's nothing serious, just that temporary files are left on the disk.
> + log.warn("Failed to cleanup temporary files after a PDF export", ex);
I thought our strategy was to not display stack trace unless the log was about an error? (at least this is the strategy I've always followed since a stack trace takes up a lot of space, draws the eye, etc). What I do usually is just display the nested message without the stack trace. Note: It might be good to have a utility method somewhere to extract all messages from all nested exceptions without the stack trace.
WDYT?
Thanks
-Vincent
[snip]
Hello devs,
I installed the latest stable version of XWiki (2.5) and I found out
that the document information panel does not include a parent field.
Therefore, I tried to include that field, as in the older version I
had (2.4.3) but saving the document does not save the parent in the
database.
Is this a bug or was there a change in the way we say what is the
parent page of a given document?
I tried to search for known issues in Jira but had no success on this one.
Best,
Paulo Zenida