Hi devs,
I recently wrote a small servlet that receives GWT requests, calls the
component that matches the request and sends back the result. It works
fine with components that don't use the XWikiContext. For those
components that use it, like DocumentAccessBridge, I need to initialize
the XWikiContext. I looked in XWikiServiceImpl (web-gwt) and XWikiAction
(xwiki-core) to see how it's done. Most of the initialization code is
duplicated and since I don't want to increase the redundancy I was
wondering if we could have a servlet filter to do the (generic)
initialization instead. WDYT?
Thanks,
Marius
Hi,
Since I'm rewriting the new Rendering component
(see http://dev.xwiki.org/xwiki/bin/view/Design/NewRenderingArchitecture)
, we need to finalize the new syntax we want to have.
Right now I'v planned to use the same wiki syntax as now
(http://platform.xwiki.org/xwiki/bin/view/Main/
XWikiSyntax#HTextStyles) with only one change: all macros now need to
be closed.
For example: {macro}...{/macro} and {macro:text|param=value|.../}
Is that ok with everyone or do we want to make changes?
Thanks
-Vincent
On Oct 27, 2009, at 12:31 PM, jvdrean (SVN) wrote:
> Author: jvdrean
> Date: 2009-10-27 12:31:28 +0100 (Tue, 27 Oct 2009)
> New Revision: 24726
>
> Modified:
> platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/
> plugin/watchlist/WatchListEvent.java
> Log:
> XPWATCHLIST-91 : Hide email fields in notifications
>
> Properties named "email" are now obfuscated.
>
> Modified: platform/xwiki-plugins/trunk/watchlist/src/main/java/com/
> xpn/xwiki/plugin/watchlist/WatchListEvent.java
> ===================================================================
> --- platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/
> xwiki/plugin/watchlist/WatchListEvent.java 2009-10-26 16:45:15 UTC
> (rev 24725)
> +++ platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/
> xwiki/plugin/watchlist/WatchListEvent.java 2009-10-27 11:31:28 UTC
> (rev 24726)
> @@ -78,6 +78,16 @@
> private static final String PREINITIAL_DOCUMENT_VERSION = "1.0";
>
> /**
> + * Value to display in diffs for hidden properties (email,
> password, etc).
> + */
> + private static final String HIDDEN_PROPERTIES_OBFUSCATED_VALUE
> = "******************";
> +
> + /**
> + * Name of email property.
> + */
> + private static final String EMAIL_PROPERTY_NAME = "email";
> +
If you wanted to make this generic you'd need to provide a callback
(an interface called) so that applications can have a say in how their
data is displayed. There would be default displayers but apps would be
able to override them. Then the User application (or the admin app if
users are considered inside the admin app) would override the display
for XWikiUsers properties named email.
That said, it's probably a good idea to obsfucate all email properties
by default so an email property type would be a good thing too.
Just some ideas for the future and for improved comments in the source
code (so that we remember).
Thanks
-Vincent
> + /**
> * Event hashcode.
> */
> private final int hashCode;
> @@ -437,9 +447,10 @@
>
> diff.getDifferencesAsHTML(objectDiff.getPrevValue().toString(),
> objectDiff.getNewValue().toString(),
> false);
>
> - if
> (objectDiff
> .getPropType
> ().equals
> (StringUtils.substringAfterLast(PasswordClass.class.getName(), "."))
> - && !StringUtils.isBlank(propDiff)) {
> - propDiff = "******************";
> + // We hide PasswordClass properties and properties named
> "email" from notifications for security reasons.
> + if
> ((objectDiff
> .getPropType
> ().equals
> (StringUtils.substringAfterLast(PasswordClass.class.getName(), "."))
> + ||
> objectDiff.getPropName().equals(EMAIL_PROPERTY_NAME)) && !
> StringUtils.isBlank(propDiff)) {
> + propDiff = HIDDEN_PROPERTIES_OBFUSCATED_VALUE;
> }
>
> return propDiff;
Hi Marius,
I have change it to $wnd["wysiwyg_editor"], so now it looks like:
native void setBackgroudColor(String color)
/*-{
$wnd["wysiwyg_editor"].getCommandManager().execute('backcolor', color);
alert($wnd["wysiwyg_editor"].getCommandManager().getValue('backcolor'));
}-*/;
And this time the error says:"$wnd[ab].getCommandManager is not a function"
Please see the screenshot:
http://picasaweb.google.com/lh/photo/wLOJbhbvl0xZe1ZWshA5wg?feat=directlink
I was wondering is it because the Java code setBackgroudColor("yellow"); and
in native JavaScript do not accept double quoted string only single quoted
string? I do deleted all xwiki web 2.0 jar files in lib and replaced with
2.02 jar files.
I have no idea what went wrong. Any advise?
Thank you, Marius!
-Leon
Hi Marius,
I successfully load the tree panel in the WYSIWYG editing model. Thank you
so much! :-)
I put the compiled xwiki-web-gwt, xwiki-web-wysiwyg and xwiki-webdav 2.02
jar file to the lib folder. After the tree loaded, I found there 2 errors
using firebug (thank you for recommendation), one is saying "isc is not
defined" in overwritesc.js(), one is saying "isc is not defined" in
overwritesc.js(). Here is the screenshot:
http://picasaweb.google.com/lh/photo/BxK7IksttDQFB4KtJAJOvg?feat=directlink.
Here is what I did, first I modify the template/macros.vm file:
Wysiwyg.onModuleLoad(function() {
window["wysiwyg_editor"] = new WysiwygEditor($jsVarName);
$jsVarName = undefined;
});
In the GWT file:
native void setBackgroudColor(String color)
/*-{
wysiwyg_editor.getCommandManager().execute('backcolor', 'yellow');
alert(wysiwyg_editor.getCommandManager().getValue('backcolor') );
}-*/;
/**
* This is the entry point method.
*/
@SuppressWarnings("unchecked")
public void onModuleLoad() {
Tree tree = new Tree();
tree.setAnimationEnabled(true);
TreeItem outerRoot = new TreeItem("DR Tag Tree");
outerRoot.addItem("Alternative");
outerRoot.addItem("Assumption");
outerRoot.addItem("Argument");
outerRoot.addItem("Claim");
outerRoot.addItem("Decision");
outerRoot.addItem("Requirement");
tree.addItem(outerRoot);
tree.addSelectionHandler(new SelectionHandler() {
public void onSelection(SelectionEvent event) {
if (((TreeItem) event.getSelectedItem()).getText().equals(
"Alternative")) {
setBackgroudColor("yellow");
} else if (((TreeItem) event.getSelectedItem()).getText()
.equals("Requirement")) {
setBackgroudColor("blue");
} else if (((TreeItem) event.getSelectedItem()).getText()
.equals("Decision")) {
setBackgroudColor("green");
}
Window.alert(((TreeItem) event.getSelectedItem()).getText());
}
});
Could you give me some ideas what is wrong? Or what I missed?
Thank you, Marius!
-Leon
Hi devs,
We want to display macros parameters pretty names in the WYSIWYG.
For that we need to provide it in the WYSIWYG. The current
ParameterDescriptor#getName actually return the parameter
identifier/technical name.
So I see two solutions:
1) the general rule in new XWiki architecture is to use id/name
instead of name/prettyname so i propose to break ParameterDescriptor
and PropertyDescriptor to follow this rule.
2) add a getDisplayName method and let getName for the identifier
WDYT ?
+1 for 1). I never like to break an API but doubt this API is used a
lots yet except by us internally and it would like we use the same
rule everywhere as much as possible.
--
Thomas Mortagne
I'm upgrading our top level POM.
Thanks
-Vincent
Begin forwarded message:
> From: Vincent Siveton <vsiveton(a)apache.org>
> Date: October 26, 2009 4:36:01 PM CEST
> To: announce(a)maven.apache.org, users(a)maven.apache.org
> Subject: [ANN] Maven Javadoc Plugin 2.6.1 Released
> Reply-To: "Maven Users List" <users(a)maven.apache.org>
>
> The Maven team is pleased to announce the release of the Maven Javadoc
> Plugin, version 2.6.1
>
> This plugin uses the javadoc tool for generating javadocs for the
> specified project.
>
> http://maven.apache.org/plugins/maven-javadoc-plugin/
>
> You should specify the version in your project's plugin configuration:
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
> <version>2.6.1</version>
> </plugin>
>
>
> Release Notes - Maven 2.x Javadoc Plugin - Version 2.6.1
>
> ** Bug
> * [MJAVADOC-244] - Javadoc plugin: java files under
> src/main/javadoc and doc-files directory are being compiled
> * [MJAVADOC-246] - ExceptionInInitializerError with
> maven-site-plugin:2.1-SNAPSHOT and mvn > 2.1
> * [MJAVADOC-251] - Configuration of javadoc:javadoc fails with NPE
> upon disadvantageous order of config injection
> * [MJAVADOC-252] - javadoc link : nonproxyhosts not used
> * [MJAVADOC-257] - maven-javadoc-plugin 2.5, 2.6 and mojo: Error
> extracting plugin descriptor
> * [MJAVADOC-259] - Resource copying from javadoc dir is incomplete
> * [MJAVADOC-262] - Parameters like sourcepath depend on system
> path separator (colon/semicolon)
> * [MJAVADOC-268] - performance problem in
> AbstractJavadocMojo.getModulesLinks()
>
> ** Improvement
> * [MJAVADOC-258] - Grouping example could show multiple packages
> per group
> * [MJAVADOC-266] - META-INF directory copied from resource
> artifacts
> * [MJAVADOC-267] - Allow changing the reportOutputDirectory from
> the commandline
>
>
> ** Task
> * [MJAVADOC-248] - Site 'Usage' page references 2.5 version of m-
> javadoc-p
>
> Enjoy,
>
> -The Maven team
Hi everyone,
I've just started a Testimonial page on xwiki.org at
http://www.xwiki.org/xwiki/bin/view/References/Testimonials
If you want to give a testimony feel free to edit the page or add a
comment to it.
If you find existing testimonies please help me move them there.
Thanks
-Vincent
On Mon, Oct 26, 2009 at 10:50 AM, Emilie Ogez <Emilie.Ogez(a)xwiki.com> wrote:
> Hi!
>
> XWiki SAS is interestred to gather testimonials about XWiki Enterprise
> and propose an original way to get them. Tell us why you love this
> solution, why you find it interesting, innovating... in less than 140
> characters on Twitter (by sending a tweet to @xwiki
> <http://www.twitter.com/xwiki>). All the tweets will be listed on
> http://xwiki.com and http://www.xwiki.org
>
> "You can also help the project by creating a page on
> http://www.xwiki.org/xwiki/bin/view/References/ that explains how you
> use XWiki."
>
> Many Thanks, in advance, for your participation.
>
> Emilie Ogez
Hi,
I am using xwiki for my organization.
In some cases the date format is appearing wrong, like the month filed
is displaying "36".
How can it be possible and what should i do to correct this.
Warm Regards
Jasvent Singh
Eperium Business Solutions India Pvt Ltd
2nd/3rd Floor, NSIC-STP Extension,
Administrative Block, NTSC Okhla Phase III,
New Delhi - 110020
Email : jasvent.singh(a)eperiumindia.com
Ph. No.(Off) : 91-11-46583900
Mob. No. : 91- 9015781898
Web : http://www.eperiumindia.com
<http://www.eperiumindia.com/>
eperium. e-commerce unlimited
This message may contain confidential or legally privileged information.
In the event of any error in transmission, unauthorized recipients are
requested to contact the sender immediately and not to disclose or make
use of this information. No warranties or assurance are made or given as
to the accuracy of the information given or in relation to the safety of
this e-mail and any attachments. No liability whatsoever is accepted for
any consequences arising from this e-mail.
Hi!
XWiki SAS is interestred to gather testimonials about XWiki Enterprise
and propose an original way to get them. Tell us why you love this
solution, why you find it interesting, innovating... in less than 140
characters on Twitter (by sending a tweet to @xwiki
<http://www.twitter.com/xwiki>). All the tweets will be listed on
http://xwiki.com and http://www.xwiki.org
"You can also help the project by creating a page on
http://www.xwiki.org/xwiki/bin/view/References/ that explains how you
use XWiki."
Many Thanks, in advance, for your participation.
Emilie Ogez
--
Marketing & Communication Manager
Mob. : +33( 0)623414368
Email : Emilie.Ogez(a)xwiki.com
http://www.xwiki.comhttp://www.twitter.com/eogez
Hi Everyone,
I met some problem with adding my personal edit panel to the panels
displayed in the WYSIWYG editing mode and Wiki editing mode. Here is what I
did:
I imitate the script of Class Switcher and Rights Help. Here is what I
wrote:
Name: DesignRationale
Type:edit
Category: Information
Content:
#largepanelheader($msg.get('Design Rationale'))
$xwiki.jsfx.use("js/xwiki/treeview/treeview.nocache.js", true) <div
id="DR_TreeView"></div> #panelfooter()
When I specify its type is "view", it can display in the right panel.
Then I modify the template file: editpanelsvars.vm . I add
"Panels.DesignRationale"
to both $editorPanelsWysiwyg and $editorPanelsWysiwyg . Here is the result:
#set($editorPanelsWiki =
"Panels.DocumentInformation,Panels.EditTranslations,Panels.SyntaxHelp, Panels.
DesignRationale")
#set($editorPanelsWysiwyg =
"Panels.DocumentInformation,Panels.EditTranslations,Panels.SyntaxHelp,Panels.
DesignRationale")
I reload the Tomcat and refresh the Xwiki page in WYSIWYG editing or Wiki
editing page. My customized panel did not appear.
Even I modify these two line like this:
#set($editorPanelsWiki = "Panels.DocumentInformation")
#set($editorPanelsWysiwyg = "Panels.DocumentInformation")
After I reload Tomcat, the other edit panel like SyntaxHelp
and EditTranslations would not disappear.
Could anyone Guru give me some idea what I missed? I do found out that
in editpanelsvars.vm there one line comment: ## Define variables containing
the list of edit panels for the Albatross skin
Does it mean it only take effect on albatross skin?
Big thanks in advance! :-)
Hi Marius,
Thank you for creating the API!
I am still trying to figure out how to display the gwt tree edit panel in
the WYSIWYG editing mode.
Is it correct that I use the new api like last time you told me? Please see
the code below:
native void setBackgroudColor(String color)
/*-{
editorJSReference.execute('backcolor', color);
}-*/;
and
if
(((TreeItem)event.getSelectedItem()).getText().equals("Alternative"))
{
setBackgroudColor("yellow");
}
What do you think? Do you think that will work?
Thank you! Hope I could get it done before meeting in the coming week.
Otherwise, my advisors will give me unhappy look again =_=
If there are anything I could help free feel to let me know, like
documenting how to use your new background API. Remember you have to create
the page for me first.
Leon
Hi devs,
Following the previous mail with the desired improvements for the annotation
feature, I would like to discuss some options for implementing the first of the
enhancements, namely the ability to configure easily the type of added
annotation. (see
http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HFeaturesimpro…
for details).
Two alternatives for this would be:
A) to preserve the current architecture of the annotations plugin and only add a
map of "extra fields" to the annotation type. The type of the annotation would
be known by the js client through the configuration of an XWiki class and the js
client would create a "generic" form for any such type.
See more details about this solution at
http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HSolution1extr…
.
Pros: preserves the current annotations architecture, creates an easy way to
plug an annotation storage service
Cons: the Annotation class would be nothing else but a "BaseCollection" the same
as a generic XWiki object, and we would be reimplementing view, save, edit,
delete of this type (already implemented through the xwiki action) from the web
forms level (editing and displaying an annotation), through the controller (REST
this time instead of actions in the standard wiki servlet), to the storage level
(XWikiIOService will only transform a map (the Annotation class) to another map
(the XWikiObject in the xwiki document)).
B) to make an XWiki object model based implementation where the js client, to
create the UI, would just asynchronously fetch standard actions in XWiki (edit,
view, save). In this case, where all is handled exclusively through the XWiki
model, Scribo would be plugged as an external service performing periodic
updates between the XWiki instance and its RDF store.
See more details about this solution at:
http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HSolution2XWik…
Pros: uses the xwiki object model 100%, there's no reimplementing of the whole
process of saving, editing objects, etc, the forms and views are light
customizations of standard XWiki mechanisms
Cons: the annotation mapping to document source cannot be implemented
straightforward (there are changes needed in the architecture and algorithm),
Scribo (or any other storage model different from XWiki) would need to duplicate
data, and it would not be 100% real time (since it would be a periodical
synchronizer)
The current implementation is illustrated in the
http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HCurrentImplem…
section.
I like the elegance of the first solution more, for the way a different storage
can be easily plugged, but I don't like that we're reimplementing a lot of XWiki
objects manipulation (which is why 2 would be a better solution).
WDYT?
Thanks,
Anca
Hi Marius,
I tried the the first way, "i) access the editor in Java (GWT) code by
writing a simple native getter", the dependency is killing me. I can not
compile it use eclipse the dependency is the way too complicated. I tried
use maven to build it, but I tried for a whole afternoon and I really don't
know how to write the correct pom to compile them together.
Could you please extend the native JavaScript API so that I can write
something like:
native void setBackgroudColor(String color)
/*-{
editorJSReference.execute('backcolor', color);
}-*/;
Could you please also tell me what you did to extend the native JavaScript
API, so I can learn about how to save the location of highlighted sentence
to help software maintainer easily trace back to the high lighted document.
If you want I can collect your reply and write document for you for this
one too.
Here is another problem, please see the screenshot:
http://picasaweb.google.com/freeleons/Xwiki#5394862411574232850 in the
WYSIWYG edit mode, the customized sidebar are disappeared, which means that
I can not use the GWT tree to interact with the WYSIWYG editor. Is there
anyway to keep the customized toolbar?
I have finished the document writeup here is the url:
http://dev.xwiki.org/xwiki/bin/view/Drafts/LoadingGWTApplicationsInXWik
You are literally saving my life. Thank you so much!
I've done a nice experiment with SocialCalc and I'm pretty happy of the
results:
It allows to edit a spreadsheet stored in a Wiki Page. It lacks a
server-side transformation of the spreadsheet to a Wiki table for
rendering, printing and pdfs, but it's already interesting.
http://incubator.myxwiki.org/xwiki/bin/view/Test/Calc
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hello Devs,
As I understand, If a wiki macro supports inline mode and is executed as an
inline macro, it must be true that the output generated by the macro does
not contain block elements (otherwise the result will not be inline). From
the wiki macro bridge code we have the following check:
<code>
List<Block> result = xdom.getChildren();
// If in inline mode remove any top level paragraph.
if (context.isInline()) {
this.parserUtils.removeTopLevelParagraph(result);
}
</code>
This only removes the top-level paragraph block. It's possible that inside
the content there are more block level elements, I think this is where we
need the inline parser.
Another problem i discovered is if i have a wiki macro with macro code:
<code>
{{velocity}}
.....
{{/velocity}}
</code>
This makes the {{velocity}} macro behave in a non-inline fashion regardless
of the wiki macro's intentions. Further more, the paragraph block generated
by the {{velocity}} macro is not stripped by the check I mentioned above.
This is because the paragraph block resides inside a MacroMarkerBlock (so it
is not a top-level paragraph).
A workaround I found for this problem is to have something like:
<code>
{{html}}{{/html}}{{velocity}}
.....
{{/velocity}}
</code>
This is only a hack to force the {{velocity}} macro ro behave in an inline
fashion.
Now I'm wondering if we should wait for the inline parser to be available to
fix this or do some custom hacking to get rid of the block elements
generated while executing in inline mode. wdyt?
Thanks.
- Asiri
Hi,
The XWiki project is now fully set up on Nemo here:
http://nemo.sonarsource.org/components/index/XWIKI
Comments:
* Since our junit test no longer fail with memory issue they've added
back test coverage stats. Link to platform: http://nemo.sonarsource.org/project/index/178319
* They've just added the "Commented LOC" stat feature which shows the
number of lines of commented code. We shouldn't have any commented out
code so we'll need to gradually reduce this too.
* The test coverage don't count integration and functional tests, i.e.
if a unit tests tests code from another module the coverage is not
taken into account. Thus all our rendering tests in xwiki-rendering-
tests are not taken into account (they cover 90% of the rendering api
code...).
* Since they've added the unit tests the tech debt has gone down a
lot. I'll ask them why.
Thanks
-Vincent