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,
In order to get more community help and to open up our xwiki.org infrastructure to the community we could introduce an infra(a)xwiki.org mailing list which would be the place to:
- talk about infrastructure. By infra I mean machines and their configuration + xwiki.org + myxwiki.org
- receive emails from xwiki.org and myxwiki.org when XE/XEM restarts (there's a script to restart them automatically when an instance doesn't respond within 30 seconds for ex). These emails contains thread dump + other information useful to debug and understand why the instance wasn't responding.
WDYT?
Thanks
-Vincent
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.
Hi,
Just a notice that I'll remove the following branches from jira since we (open source xwiki developers) only support 2 branches (trunk + latest stable):
• xwiki-core-1.5-curriki/
• xwiki-core-1.8/
• xwiki-core-1.9/
• xwiki-core-2.1/
• xwiki-core-2.2/
• xwiki-core-2.3/
• xwiki-core-2.4/
Please shout quickly if you have a good reason to keep one of these (also note that they'll always be in the svn history).
Thanks
-Vincent
Hello,
>Sergiu Dumitriu wrote:
>
>>Silvia Rusu wrote:
>>
>>Hi devs,
>>
>>I propose we make "Edit this attachment" in the "Attachments" tab an advanced feature in the advanced edit mode.
>>
>>When trying to use "Edit this attachment": - in IE you get the following message: "Could not initialize a required ActiveX object" - in FF 3.5.2 installing the extension delivers the following message:"FoxWiki 1.0b could not be installed because it is not compatible with Firefox 3.5.2". - installing the extension on an older version of FF requires additional configuration, which the average user may not know how to perform.
>>
Under the above circumstances I think "Edit this attachment" will
cause confusion for the average user instead of providing a useful
tool.
>>
>>WDYT?
>>
>
>Agreed to remove the edit button if the FF extension is not already installed and configured.
The edit button is still there and the Firefox extension can't be
installed because it is not compatible with newer Firefox versions.
I really think that we should remove this button as soon as possible
because this is a non-functionality at this point.
Raluca.