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,
I'm getting this error when running the tests for xwiki-observation-remote:
Caused by: java.lang.RuntimeException: the type of the stack (IPv6) and the user supplied addresses (IPv4) don't match: localhost/127.0.0.1.
Use system props java.net.preferIPv4Stack or java.net.preferIPv6Addresses to pick the correct stack
at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:108)
at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:54)
at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:453)
at org.jgroups.JChannel.init(JChannel.java:1702)
This thread explains the problem:
http://old.nabble.com/Protocol-stack-issue-on-dual-stack-(IPv4-and-v6)-mach…
This issue has been created to track the problem:
https://jira.jboss.org/browse/JGRP-1152
I've tested with jgroups 2.10.0.Beta2 and it works fine.
I've seen on http://jira.xwiki.org/jira/browse/XWIKI-4917 that jgroups 2.9 and above require JDK 6+.
What do we do?
Should we set the jgroups property to force ipv4 or ipv6?
Thanks
-Vincent
Hi devs,
We've been working on improving the editors (content, class, object),
and now I have some pretty important UI changes to commit, but not
everybody seems to agree with them, so I bring up a vote.
The whole improvements can be seen on
http://incubator.myxwiki.org/xwiki/bin/Improvements/ImprovedEdit
Here are the individual voted points:
0 Remove all panels in edit mode
1a Parent and title above the content in wiki/wysiwyg mode
1b The same style in edit mode as in view mode for the parent/title fields
1c AJAX Suggest for the parent field
2a New label for the content textarea ("Content")
2b List of included documents after the Content label
3a Syntax switcher in the top right corner of the content
3b Syntax help in the top right corner of the content
3c Syntax help and switcher only in the wiki editor
4 Better label for the version comment
5a Right float the Minor edit field
5b Put the Minor edit label after the checkbox
6 Move autosave in line with the submit buttons
7 Introduce new AJAX-powered Add Object
i) above the objects
ii) bellow the objects
8 Introduce new AJAX-powered Add Object from this class
i) at the top of the list of existing objects
ii) at the end of the list
9 Move the class switcher in the top right corner
9b Remove the class switcher
10 Introduce new AJAX-powered Add Property
i) at the top of the list of properties
ii) at the end of the list
I vote +1 for all of the above, except 9b (-0), and with options 7i),
8ii), and 10ii)
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
Our goal is to develop a wysisyg macro allowing to :
- Insert an Image stored on Alfresco
- Insert a link to a document stored on Alfresco
To do this; we have develop a small browser on Alfresco in order to choose
the image to insert (img src) or the file to link (a href).
After selecting the Alfresco file; we need to generate a macro like :
[[Lien vers le doc
toto>>http://alfresco.airfrance.fr/alfresco/.../toto.doc||rel="__blank"
title="Ouvrir le doc toto..."]]
or
[[image:http://alfresco.airfrance.fr/alfresco/..../image.jpg]]
Using the wiki editor and the old Wysiwyg editor; we had no problem to do
this. (Openning popup and populate les link field with alfresco file path.)
With the new editor; I can't find the way to do this.
In fact my problem could be resume to add a picto in the 'link' and 'image'
macro GUI allowing to open my alfresco browser in order to populate the path
!
Any idea to do this ?
Thanks,
Julien
--
View this message in context: http://xwiki.475771.n2.nabble.com/Wysiwyg-editor-and-macro-accessing-to-Alf…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
It seems that currently there is no good way to manipulate XWiki objects
and properties in documents without depending on old core.
DocumentAccessBridge defines some methods for changing properties, but
they are very limited, in particular, there is no way to:
* add a new property (except the first one)
* set a property of n-th object (getting it is possible)
* remove an object
* get the number of objects
Therefore I propose to add the following methods to DocumentAccessBridge:
// returns index of the new object
int addObject(ObjectReference obj) throws Exception;
// returns false if there was no object, throws on access error
boolean removeObject(ObjectReference obj, int index) throws Exception;
// number of objects of the given class
int getObjectCount(ObjectReference obj);
// returns index of the object that was modified, adds a new object if
// index is out of range
int setProperty(ObjectReference obj, int idx, String prop, Object val)
throws Exception;
// just to have all needed methods taking object reference
Object getProperty(ObjectReference obj, int index, String propertyName);
I've chosen ObjectReference because it contains (almost) all needed
information, including class name and document reference. It would be
better to have the object index stored in the reference too, like in
org.xwiki.annotation.reference.IndexedObjectReference, but this class is
annotation-specific.
I need those methods to store certificates in user profile, see
https://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-signedscripts
WDYT?
Thanks,
Alex
Hello XWikiers!
If you have used syntax highlighter (
http://code.google.com/p/syntaxhighlighter/) in wordpress, blogger etc. you
are going to like this one:
http://asiri.rathnayake.org/xwiki/bin/view/Macro/MCode
Now because of the flexibility of XWiki SSX and JSX, you can easily
customize this macro (if you wish to extend it). There are few things I wish
if I could improve (implementation details) but I hope this would be useful
the way it is now :)
Let me know if it looks good.
Thanks.
- Asiri