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