Hi Everyone, Hi Marius,
Here is the code that I embeded in the Xwiki page, I just only include
js/xwiki/mail/mail.nocache.js
just once:
{{velocity}}
$xwiki.jsfx.use("js/xwiki/mail/mail.nocache.js", true)
{{html}}
<div id="DR_TreeView"></div>
{{/html}}
{{/velocity}}
or
{{velocity}}
$xwiki.jsfx.use("js/xwiki/mail/mail.nocache.js", true)
{{/velocity}}
{{html}}
<div id="DR_TreeView"></div>
{{/html}}
This will result at the top of the page that have the clickable Mail example
functioning well, at the bottom it follows two unclickable Mail example,
just like html displayed. And follows 6 xwe.onInjectionDone('xwe') sep . It
seems although I used $xwiki.jsfx.use, the JavaScript code still parsed as
wiki syntax and display as text. So what should I do?
You said "to include the JavaScript code so that it ends up in your HTML
page's head not body".
Hey Sergiu,
line 58 is failing checkstyle for being 2 characters too long.
* @return HTML code linking to the pulled resource (eg: <script type="text/javascript" src="/this/url.js"></script>)
Thanks again,
Caleb
sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2009-10-10 01:04:21 +0200 (Sat, 10 Oct 2009)
> New Revision: 24354
>
> Added:
> platform/xwiki-plugins/trunk/skinx/src/main/java/com/xpn/xwiki/plugin/skinx/AbstractResourceSkinExtensionPlugin.java
> Modified:
> platform/xwiki-plugins/trunk/skinx/src/main/java/com/xpn/xwiki/plugin/skinx/CssResourceSkinExtensionPlugin.java
> platform/xwiki-plugins/trunk/skinx/src/main/java/com/xpn/xwiki/plugin/skinx/JsResourceSkinExtensionPlugin.java
> Log:
> XSKINX-29: Refactor duplicate code
> Refactor JsResourceSkinExtensionPlugin and CssResourceSkinExtensionPlugin.
> Patch from Caleb James DeLisle, applied with several changes.
>
>
> Added: platform/xwiki-plugins/trunk/skinx/src/main/java/com/xpn/xwiki/plugin/skinx/AbstractResourceSkinExtensionPlugin.java
> ===================================================================
> --- platform/xwiki-plugins/trunk/skinx/src/main/java/com/xpn/xwiki/plugin/skinx/AbstractResourceSkinExtensionPlugin.java (rev 0)
> +++ platform/xwiki-plugins/trunk/skinx/src/main/java/com/xpn/xwiki/plugin/skinx/AbstractResourceSkinExtensionPlugin.java 2009-10-09 23:04:21 UTC (rev 24354)
> @@ -0,0 +1,102 @@
> +/*
> + * See the NOTICE file distributed with this work for additional
> + * information regarding copyright ownership.
> + *
> + * This is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU Lesser General Public License as
> + * published by the Free Software Foundation; either version 2.1 of
> + * the License, or (at your option) any later version.
> + *
> + * This software is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this software; if not, write to the Free
> + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> + * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
> + */
> +package com.xpn.xwiki.plugin.skinx;
> +
> +import java.util.Collections;
> +import java.util.Set;
> +
> +import com.xpn.xwiki.XWikiContext;
> +import com.xpn.xwiki.XWikiException;
> +
> +/**
> + * Skin Extension plugin to use extension files from JAR resources.
> + * @version $Id$
> + */
> +public abstract class AbstractResourceSkinExtensionPlugin extends AbstractSkinExtensionPlugin
> +{
> + /**
> + * XWiki plugin constructor.
> + *
> + * @param name The name of the plugin, which can be used for retrieving the plugin API from velocity. Unused.
> + * @param className The canonical classname of the plugin. Unused.
> + * @param context The current request context.
> + * @see com.xpn.xwiki.plugin.XWikiDefaultPlugin#XWikiDefaultPlugin(String,String,com.xpn.xwiki.XWikiContext)
> + */
> + public AbstractResourceSkinExtensionPlugin(String name, String className, XWikiContext context)
> + {
> + super(name, className, context);
> + }
> +
> + /**
> + * Get the action which the url should specify for calling this resource.
> + *
> + * @return String Action name.
> + */
> + protected abstract String getAction();
> +
> + /**
> + * Takes a URL string and outputs a link which will cause the browser to load the url.
> + *
> + * @param url String representation of the url to load (eg: "/this/url.js")
> + * @return HTML code linking to the pulled resource (eg: <script type="text/javascript" src="/this/url.js"></script>)
> + */
> + protected abstract String generateLink(String url);
> +
> + /**
> + * {@inheritDoc}
> + *
> + * @see AbstractSkinExtensionPlugin#getLink(String, XWikiContext)
> + */
> + public String getLink(String resourceName, XWikiContext context)
> + {
> + // If the current user has access to Main.WebHome, we will use this document in the URL
> + // to serve the resource. This way, the resource can be efficiently cached, since it has a
> + // common URL for any page.
> + try {
> + String page = context.getWiki().getDefaultWeb(context) + "." + context.getWiki().getDefaultPage(context);
> + if (!context.getWiki().getRightService().hasAccessLevel("view", context.getUser(), page, context)) {
> + page = context.getDoc().getFullName();
> + }
> + return generateLink(context.getWiki().getURL(page, getAction(),
> + "resource=" + resourceName + parametersAsQueryString(resourceName, context), context));
> + } catch (XWikiException e) {
> + // Do nothing here; we can't access the wiki, so don't link to this resource at all.
> + return "";
> + }
> + }
> +
> + /**
> + * {@inheritDoc}
> + * <p>
> + * There is no support for always used resource-based extensions yet.
> + * </p>
> + *
> + * @see AbstractSkinExtensionPlugin#getAlwaysUsedExtensions(XWikiContext)
> + */
> + @Override
> + public Set<String> getAlwaysUsedExtensions(XWikiContext context)
> + {
> + // There is no mean to define an always used extension for something else than a document extension now,
> + // so for resources-based extensions, we return an emtpy set.
> + // An idea for the future could be to have an API for plugins and components to register always used resources
> + // extensions.
> + return Collections.emptySet();
> + }
> +}
>
>
> Property changes on: platform/xwiki-plugins/trunk/skinx/src/main/java/com/xpn/xwiki/plugin/skinx/AbstractResourceSkinExtensionPlugin.java
> ___________________________________________________________________
> Name: svn:keywords
> + Id
> Name: svn:eol-style
> + native
>
> Modified: platform/xwiki-plugins/trunk/skinx/src/main/java/com/xpn/xwiki/plugin/skinx/CssResourceSkinExtensionPlugin.java
> ===================================================================
> --- platform/xwiki-plugins/trunk/skinx/src/main/java/com/xpn/xwiki/plugin/skinx/CssResourceSkinExtensionPlugin.java 2009-10-09 18:28:50 UTC (rev 24353)
> +++ platform/xwiki-plugins/trunk/skinx/src/main/java/com/xpn/xwiki/plugin/skinx/CssResourceSkinExtensionPlugin.java 2009-10-09 23:04:21 UTC (rev 24354)
> @@ -20,11 +20,7 @@
> */
> package com.xpn.xwiki.plugin.skinx;
>
> -import java.util.Collections;
> -import java.util.Set;
> -
> import com.xpn.xwiki.XWikiContext;
> -import com.xpn.xwiki.XWikiException;
>
> /**
> * Skin Extension plugin to use css files from JAR resources.
> @@ -32,7 +28,7 @@
> * @version $Id$
> * @since 1.3
> */
> -public class CssResourceSkinExtensionPlugin extends AbstractSkinExtensionPlugin
> +public class CssResourceSkinExtensionPlugin extends AbstractResourceSkinExtensionPlugin
> {
> /**
> * XWiki plugin constructor.
> @@ -45,7 +41,6 @@
> public CssResourceSkinExtensionPlugin(String name, String className, XWikiContext context)
> {
> super(name, className, context);
> - init(context);
> }
>
> /**
> @@ -61,47 +56,22 @@
>
> /**
> * {@inheritDoc}
> - *
> - * @see AbstractSkinExtensionPlugin#getLink(String, XWikiContext)
> + *
> + * @see AbstractSkinExtensionPlugin#getAction()
> */
> - @Override
> - public String getLink(String documentName, XWikiContext context)
> + protected String getAction()
> {
> - String result = "";
> - // If the current user has access to Main.WebHome, we will use this document in the URL
> - // to serve the css resource. This way, the resource can be efficiently cached, since it has a
> - // common URL for any page.
> - try {
> - String page = context.getWiki().getDefaultWeb(context) + "." + context.getWiki().getDefaultPage(context);
> - if (!context.getWiki().getRightService().hasAccessLevel("view", context.getUser(), page, context)) {
> - page = context.getDoc().getFullName();
> - }
> - String url =
> - context.getWiki().getURL(page, "ssx",
> - "resource=" + documentName + parametersAsQueryString(documentName, context), context);
> - result = "<link rel='stylesheet' type='text/css' href='" + url + "'/>";
> - } catch (XWikiException e) {
> - // Do nothing here; we can't access the wiki, so don't link to this resource at all.
> - }
> - return result;
> + return "ssx";
> }
>
> /**
> * {@inheritDoc}
> - * <p>
> - * There is no support for always used resource-based extensions yet.
> - * </p>
> - *
> - * @see AbstractSkinExtensionPlugin#getAlwaysUsedExtensions(XWikiContext)
> + *
> + * @see AbstractSkinExtensionPlugin#generateLink()
> */
> - @Override
> - public Set<String> getAlwaysUsedExtensions(XWikiContext context)
> + protected String generateLink(String url)
> {
> - // There is no mean to define an always used extension for something else than a document extension now,
> - // so for resources-based extensions, we return an emtpy set.
> - // An idea for the future could be to have an API for plugins and components to register always used resources
> - // extensions.
> - return Collections.emptySet();
> + return "<link rel='stylesheet' type='text/css' href='" + url + "'/>\n";
> }
>
> /**
>
> Modified: platform/xwiki-plugins/trunk/skinx/src/main/java/com/xpn/xwiki/plugin/skinx/JsResourceSkinExtensionPlugin.java
> ===================================================================
> --- platform/xwiki-plugins/trunk/skinx/src/main/java/com/xpn/xwiki/plugin/skinx/JsResourceSkinExtensionPlugin.java 2009-10-09 18:28:50 UTC (rev 24353)
> +++ platform/xwiki-plugins/trunk/skinx/src/main/java/com/xpn/xwiki/plugin/skinx/JsResourceSkinExtensionPlugin.java 2009-10-09 23:04:21 UTC (rev 24354)
> @@ -20,11 +20,7 @@
> */
> package com.xpn.xwiki.plugin.skinx;
>
> -import java.util.Collections;
> -import java.util.Set;
> -
> import com.xpn.xwiki.XWikiContext;
> -import com.xpn.xwiki.XWikiException;
>
> /**
> * Skin Extension plugin that allows pulling javascript files from JAR resources.
> @@ -32,7 +28,7 @@
> * @version $Id$
> * @since 1.3
> */
> -public class JsResourceSkinExtensionPlugin extends AbstractSkinExtensionPlugin
> +public class JsResourceSkinExtensionPlugin extends AbstractResourceSkinExtensionPlugin
> {
> /**
> * XWiki plugin constructor.
> @@ -44,57 +40,42 @@
> */
> public JsResourceSkinExtensionPlugin(String name, String className, XWikiContext context)
> {
> - super("jsrx", className, context);
> - init(context);
> + super(name, className, context);
> }
>
> /**
> * {@inheritDoc}
> *
> - * @see AbstractSkinExtensionPlugin#getLink(String, XWikiContext)
> + * @see com.xpn.xwiki.plugin.XWikiDefaultPlugin#getName()
> */
> @Override
> - public String getLink(String documentName, XWikiContext context)
> + public String getName()
> {
> - String result = "";
> - // If the current user has access to Main.WebHome, we will use this document in the URL
> - // to serve the js resource. This way, the resource can be efficiently cached, since it has a
> - // common URL for any page.
> - try {
> - String page = context.getWiki().getDefaultWeb(context) + "." + context.getWiki().getDefaultPage(context);
> - if (!context.getWiki().getRightService().hasAccessLevel("view", context.getUser(), page, context)) {
> - page = context.getDoc().getFullName();
> - }
> - String url =
> - context.getWiki().getURL(page, "jsx",
> - "resource=" + documentName + parametersAsQueryString(documentName, context), context);
> - result = "<script type=\"text/javascript\" src=\"" + url + "\"></script>";
> - } catch (XWikiException e) {
> - // Do nothing here; we can't access the wiki, so don't link to this resource at all.
> - }
> - return result;
> + return "jsrx";
> }
>
> /**
> * {@inheritDoc}
> - * <p>
> - * There is no support for always used resource-based extensions yet.
> - * </p>
> - *
> - * @see AbstractSkinExtensionPlugin#getAlwaysUsedExtensions(XWikiContext)
> + *
> + * @see AbstractSkinExtensionPlugin#getAction()
> */
> - @Override
> - public Set<String> getAlwaysUsedExtensions(XWikiContext context)
> + protected String getAction()
> {
> - // There is no mean to define an always used extension for something else than a document extension now,
> - // so for resources-based extensions, we return an emtpy set.
> - // An idea for the future could be to have an API for plugins and components to register always used resources
> - // extensions.
> - return Collections.emptySet();
> + return "jsx";
> }
>
> /**
> * {@inheritDoc}
> + *
> + * @see AbstractSkinExtensionPlugin#generateLink()
> + */
> + protected String generateLink(String url)
> + {
> + return "<script type=\"text/javascript\" src=\"" + url + "\"></script>\n";
> + }
> +
> + /**
> + * {@inheritDoc}
> * <p>
> * We must override this method since the plugin manager only calls it for classes that provide their own
> * implementation, and not an inherited one.
>
> _______________________________________________
> notifications mailing list
> notifications(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/notifications
>
Could we get this one in the paper cut list ?
http://jira.xwiki.org/jira/browse/XWIKI-831
The patch in this jira both fixes:
- the ability to add version instead of overriding (the current behavior
can result in data loss)
- the setting of contentAuthor (this is the paper cut as it forces to
resave all pages which require prog rights)
These bugs do lead to productivity loss. If I just sum the time it takes
to do the resaves I'm sure this amounts in days since the beginning of
the year
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi,
> > + /**
> > + * {@inheritDoc}
> > + */
> > + public String getSpace()
> > + {
> > + return config.getParameter("space", "Main");
> > + }
> > +
> > + /**
> > + * {@inheritDoc}
> > + */
> > + public String getWiki()
> > + {
> > + return config.getParameter("wiki", "xwiki");
> > + }
>
> Actually I don't see a good reason for which I made these functions public.
> We
> should make them protected.
>
+1, I'll do it.
>
> > +
> > + /**
> > + * {@inheritDoc}
> > + */
> > + protected String getFileHelpLabel()
> > + {
> > + return Strings.INSTANCE.importOfficeFileHelpLabel();
> > + }
> > +
> > + /**
> > + * {@inheritDoc}
> > + */
> > + protected void onAttachmentUploaded(Attachment attach, final
> AsyncCallback<Boolean> async)
> > + {
> > +
> > + String fullPageName = getSpace() + "." + getPage();
>
> you should use the ResourceName class to build wiki names, since it's the
> client
> wiki reference serializer/deserializer.
> > +
> WysiwygService.Singleton.getInstance().officeToXHTML(fullPageName,
> getHTMLCleaningParams(),
>
Actually this code will go away when I introduce the new
officeToXHTML(Attachment....) method.
> + // Display the error and avoid submit operation from
> continuing.
> > + displayError(thrown.getMessage());
> > + async.onSuccess(false);
>
> As a convention, we used the onFailure to signal an error on the server or
> in
> the server-client communication (like a GWT failure in the RPC call), while
> the
> submit async.onSuccess(false) is an "application error", a way in which a
> wizard
> step prevents the submit to be done because, for example, the user didn't
> insert
> valid data in the wizard form and another chance is being given to him.
>
> Now, which are the cases in which the importer service fails (throws
> exception)?
> is it correct to do this conversion here (from a server error / exception
> to a
> "validation" error)? or you should rather call async.onFailure()? this only
> depends on the logic of the service function failure.
>
Thanks. I will look into this and fix it.
> + */
> > + public EnumSet<NavigationDirection> getValidDirections()
> > + {
> > + return EnumSet.of(NavigationDirection.FINISH);
>
> We also return CANCEL here, even if a button for it is not displayed and
> it's
> always possible (through the dialog's close button), but in case we will
> ever
> want to display a button, or want to prevent the cancel in certain steps.
>
Ok, I will fix this.
>
> > + public void init(Object data, AsyncCallback< ?> cb)
> > + {
> > + textArea.setHTML("");
> > + textArea.setFocus(true);
>
> I seriously doubt this works, you should a FocusCommand(), look at its
> comment
> for reasons.
>
Ok.
>
> > + protected Map<String, String> getHTMLCleaningParams()
> > + {
> > + Map<String, String> params = new HashMap<String, String>();
> > + params.put("filterStyles", "strict");
> > + // For Office2007: Office2007 generates an xhtml document (when
> copied) which has attributes and tags of
> > + // several namespaces. But the document itself doesn't contain
> the namespace definitions, which causes
> > + // the HTMLCleaner (the DomSerializer) to fail while performing
> it's operations. As a workaround we
> > + // force HTMLCleaner to avoid parsing of namespace information.
> > + params.put("namespacesAware", Boolean.toString(false));
> > + return params;
> > + }
>
> Is this the same function as in the other class?
>
Yes, I am reluctant to introduce a super class or a utility class to wrap up
this functionality. Not sure if I should do it or not.
> + return requestedStep;
>
> Maybe we could create a super class for this, it's the same everywhere.
>
+1.
> Also,
>
> svn propset svn:keywords "Author Id Revision HeadURL" <new-file-path>
>
> for all new added files.
>
> check
>
> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HSubvers…
> for how to configure this for your svn client. Note that, even if correctly
> configured, the settings will not be considered by the eclipse plugin (I
> didn't
> manage to make them work), you'll have to do a command-line svn add for
> that to
> work right.
>
Ok, thanks for the tip.
- Asiri
Hi Marius,
Thank you for your help! I am quite touched you actually tried to load the
Mail example in Xwiki page. I followed your code in the 1.6 version. Here is
the screenshot link:
http://picasaweb.google.com/lh/sredir?uname=freeleons&target=PHOTO&id=53904…
It seems works on Firefox (It is clickable but still something broken
maybe it is the sizing not right) it does not work on Google Chrome at all.
At the top of the page Firefox can display it well Chrome will display
nothing. At the bottom of the page both on Chrome and Firefox will display
these:
//
xwe.onInjectionDone('xwe')
//
//
xwe.onInjectionDone('xwe')
//
//
xwe.onInjectionDone('xwe')
//
//
xwe.onInjectionDone('xwe')
//
Here is the screenshot:
http://picasaweb.google.com/lh/sredir?uname=freeleons&target=PHOTO&id=53904…
It completely broken and nothing clickable. Later I found the srollbar
disable because this line in the Mail source
code: Window.enableScrolling(false);
Thank you for your help so I can get this far. Do you know why the the Mail
appear both at the very top of the page and also at the very bottom of the
page, and the bottom is completely broken? The mail.nocache.js successfully
loaded according to firebug.
And here is my code:
public void onModuleLoad() {
loadingUI();
}
private void loadingUI(){
String hookId = "DR_TreeView";
Element hook = DOM.getElementById(hookId);
if (hook == null) {
return;
}
// Prepare the DOM
Element container = DOM.createDiv();
String containerId = hookId + "_container";
container.setId(containerId);
hook.getParentElement().replaceChild(container, hook);
DockPanel outer = initialUI();
RootPanel.get(containerId).add(outer);
// Call the window resized handler to get the initial sizes setup.
Doing
// this in a deferred command causes it to occur after all widgets'
sizes
// have been computed by the browser.
DeferredCommand.addCommand(new Command() {
public void execute() {
onWindowResized(Window.getClientWidth(),
Window.getClientHeight());
}
});
onWindowResized(Window.getClientWidth(), Window.getClientHeight());
}
Thank you a lot!
-Leon
Hi, there,
I'm running the sanity check script on mysql 5.0.54 and there are some
queries return results. To correct these problems, should I simply just
delete these results or I need to do something else before the deletion?
Take an example, for the following query:
select * from xwikiproperties,xwikilargestrings where
xwp_classtype='com.xpn.xwiki.objects.StringListProperty' and
xwp_name=xwl_name and xwp_id=xwl_id
+---------+-----------------+--------------------------------------+---------+-----------------+---------------------------------------------
| XWP_ID | XWP_NAME | XWP_CLASSTYPE | XWL_ID | XWL_NAME | XWL_VALUE
+---------+-----------------+--------------------------------------+---------+-----------------+---------------------------------------------
| -1877168607 | subscribedDocuments |
com.xpn.xwiki.objects.StringListProperty | -1877168607 | subscribedDocuments
| Main.WebSearch|Main.Categories
| 261169163 | subscribedDocuments | com.xpn.xwiki.objects.StringListProperty
| 261169163 | subscribedDocuments | Service
Measurements.WebHome|IMProcess.WebHome
| 683557787 | subscribedWebs | com.xpn.xwiki.objects.StringListProperty |
683557787 | subscribedWebs | Replication
| 683557787 | subscribedDocuments | com.xpn.xwiki.objects.StringListProperty
| 683557787 | subscribedDocuments | IIS.WebHome
I've got couple hundred lines of records like this. If I delete all these
records, what kind of impact will be to my content?
Thank you very much for your help
--
View this message in context: http://n2.nabble.com/Help-About-Sanity-Check-tp3670302p3670302.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
jvdrean (SVN) wrote:
> Author: jvdrean
> Date: 2009-08-25 15:03:08 +0200 (Tue, 25 Aug 2009)
> New Revision: 22900
>
> Added:
> 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/WatchListEventManager.java
> platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListEventType.java
> platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListJob.java
> platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListJobManager.java
> platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListNotifier.java
> platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListStore.java
> Removed:
> platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListJob.java
> Modified:
> platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties
> platform/xwiki-applications/trunk/watchlist/src/main/resources/XWiki/WatchListManager.xml
> platform/xwiki-applications/trunk/watchlist/src/main/resources/XWiki/WatchListMessage.xml
> platform/xwiki-plugins/trunk/watchlist/pom.xml
> platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListPlugin.java
> platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListPluginApi.java
> Log:
> XPWATCHLIST-55 : Make the watchlist plugin use the activitystream plugin to retrieve events
> XPWATCHLIST-23 : Put the classes and objects diffs in the emails.
> XPWATCHLIST-34 : Exception in log for user not having watch list data
> XPWATCHLIST-35 : Watch list should support registering for full wikis
> XPWATCHLIST-40 : Watch list should support any interval for its notifications
> XPWATCHLIST-27 : WatchList send an exception by mail
>
> Modified: platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties
> ===================================================================
> --- platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties 2009-08-25 12:55:58 UTC (rev 22899)
> +++ platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties 2009-08-25 13:03:08 UTC (rev 22900)
> @@ -837,6 +837,10 @@
> watchlist.delete.ko=An error occurred while removing {0} from watchlist
> watchlist.create.object=Created WatchList storage object
> watchlist.save.object=Updated WatchList
> +watchlist.event.create=On {0}, the document has been created by {1}
> +watchlist.event.delete=On {0}, the document has been deleted by {1}
> +watchlist.event.update=On {0}, the document has been modified by {1}
> +watchlist.event.update.multiple=Between {0} and {1}, the document has been modified {2} times, by {3} user(s): {4}
/\ /\ /\
Replaced user(s) with: user{3,choice,0#s|1#|2#s}.
> Added: 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 (rev 0)
> +++ platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListEvent.java 2009-08-25 13:03:08 UTC (rev 22900)
> @@ -0,0 +1,504 @@
Why do we need both prefixedSpace and prefixedFullName? Can't we obtain
the first from the latter?
> + /**
> + * Prefixed space in which the event happened.
> + */
> + private final String prefixedSpace;
> +
> + /**
> + * Prefixed document fullName in which the event happened.
> + */
> + private final String prefixedFullName;
I prefer enums for this. Is there a good reason why this is a String?
> + /**
> + * Type of the event (example: "update").
> + */
> + private String type;
> +
I don't like three lists that must be iterated in parallel. Why not a
single lists with a custom data object?
> +
> + /**
> + * List of versions affected by this event. It will contain only one entry if the event is not a composite event.
> + */
> + private List<String> versions;
> +
> + /**
> + * List of authors for this event. It will contain only one entry if the event is not a composite event.
> + */
> + private List<String> authors;
> +
> + /**
> + * List of dates for this event. It will contain only one entry if the event is not a composite event.
> + */
> + private List<Date> dates;
> +
> + /**
> + * Constructor.
> + *
> + * @param activityEvent activity stream event to wrap
> + */
> + public WatchListEvent(ActivityEvent activityEvent)
> + {
> + this.activityEvents.add(activityEvent);
> + type = activityEvent.getType();
> + prefixedSpace = activityEvent.getWiki() + WatchListStore.WIKI_SPACE_SEP + activityEvent.getSpace();
> + prefixedFullName = activityEvent.getWiki() + WatchListStore.WIKI_SPACE_SEP + activityEvent.getPage();
I'd move this piece of code in a separate method.
> + int hash = 3;
> + if (ActivityEventType.UPDATE.equals(activityEvent)) {
> + hashCode = 42 * hash + prefixedFullName.hashCode() + activityEvent.getType().hashCode();
> + } else {
> + hashCode =
> + 42 * hash + prefixedFullName.hashCode() + activityEvent.getType().hashCode()
> + + activityEvent.getDate().hashCode();
> + }
> + }
> +
> + /**
> + * Add another event associated to this event.
> + *
> + * @param event The event to add.
> + */
> + public void addEvent(WatchListEvent event)
> + {
> + if (ActivityEventType.DELETE.equals(event.getType())) {
> + // If the document has been deleted, reset this event
> + activityEvents.clear();
> + type = event.getType();
> + versions.clear();
> + versions = null;
> + authors.clear();
> + authors = null;
> + previousVersion = null;
> + htmlDiff = null;
> + } else if (ActivityEventType.UPDATE.equals(event.getType()) && ActivityEventType.DELETE.equals(getType())) {
> + // If an update event had been fired before a delete, discard it
> + return;
> + }
> +
> + activityEvents.add(event.getActivityEvent());
> + }
The following methods are not threadsafe at all. Should they be?
Why don't we build these lists as we add events? The current usage
patterns probably don't add new events after retrieving the list of
dates/authors, but this code has a dependency on the order in which
methods are called, which is not good.
> + /**
> + * @return Get all the dates of a composite event, if this event is not a composite this list will contain single
> + * entry.
> + */
> + public List<Date> getDates()
> + {
> + if (dates == null) {
> + dates = new ArrayList<Date>();
I don't think this is needed, since isComposite simply checks the size
of the list. It brings a marginal performance gain with the cost of
increased code complexity.
> + if (!isComposite()) {
> + dates.add(getDate());
> + } else {
> + for (ActivityEvent event : activityEvents) {
> + dates.add(event.getDate());
> + }
> + }
> + }
> +
> + return dates;
> + }
> +
> + public List<String> getAuthors()
> +
> + public List<String> getVersions()
> +
> +
> + /**
> + * @param classAttr The class of the div to create
> + * @return a HTML div element
> + */
> + private Div createDiffDiv(String classAttr)
> + {
Oh no, please don't use jakarta-ecs. It's a dead project.
> + Div div = new Div();
> + div.setClass(classAttr);
> + div.setStyle(HTML_STYLE_PLACEHOLDER_PREFIX + classAttr);
> +
> + return div;
> + }
> +
> +
> + /**
> + * Overriding of the default equals method.
> + *
> + * @param obj the ActivityEvent to be compared with
> + * @return True if the two events have been generated by the same document and are equals or conflicting
> + */
> + @Override
> + public boolean equals(Object obj)
> + {
> + if (this == obj) {
> + return true;
> + }
> +
> + if (!(obj instanceof WatchListEvent)) {
> + return false;
> + }
This is not correct, any implementation of equals must be commutative:
this.equals(event) must return the same as event.equals(this).
> + // At first this method was returning true when the documents were the same and the events were the same type.
> + // Since we don't want to keep update events for documents that have been deleted this method has been modified
> + // to a point were it performs something different from a equals(), it returns true when obj is a delete event
> + // and 'this' is an update event. See WatchListEventManager#WatchListEventManager(Date, XWikiContext).
> + // TODO: refactoring.
> + WatchListEvent event = ((WatchListEvent) obj);
> + return prefixedFullName.equals(event.getPrefixedFullName()) && WatchListEventType.UPDATE.equals(getType())
> + && (WatchListEventType.UPDATE.equals(event.getType()) || WatchListEventType.DELETE.equals(event.getType()));
> + }
> +}
> Added: platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListJob.java
> ===================================================================
> --- platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListJob.java (rev 0)
> +++ platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListJob.java 2009-08-25 13:03:08 UTC (rev 22900)
> @@ -0,0 +1,257 @@
> +
> +/**
Why "abstract"? The documentation does not provide any information, the
fact that it implements a Job can be seen from the list of implements.
> + * WatchList abstract implementation of Quartz's Job.
> + *
> + * @version $Id$
> + */
> +public class WatchListJob extends AbstractJob implements Job
> +{
These two methods are pretty generic, they should be moved somewhere
else, in the core.
> + /**
> + * Initialize container context.
> + *
> + * @param context The XWiki context.
> + * @throws ServletException If the container initialization fails.
> + */
> + protected void initializeComponents(XWikiContext context) throws ServletException
> +
> + /**
> + * Clean the container context.
> + */
> + protected void cleanupComponents()
> Modified: platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListPluginApi.java
> ===================================================================
> --- platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListPluginApi.java 2009-08-25 12:55:58 UTC (rev 22899)
> +++ platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListPluginApi.java 2009-08-25 13:03:08 UTC (rev 22900)
> @@ -22,6 +22,7 @@
This change:
> -public class WatchListPluginApi extends PluginApi
> +public class WatchListPluginApi extends PluginApi<WatchListPlugin>
> {
means that we don't need getWatchlistPlugin anymore, but getProtectedPlugin.
> - return getWatchListPlugin().getWatchedSpaces(getXWikiContext().getUser(),
> - getXWikiContext()).contains(context.getDatabase() + ":" + context.getDoc().getSpace());
> + return getWatchListPlugin().getStore().getWatchedElements(context.getUser(), ElementType.SPACE, context)
> + .contains(context.getDatabase() + WatchListStore.WIKI_SPACE_SEP + context.getDoc().getSpace());
> }
> Added: platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListStore.java
> ===================================================================
> --- platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListStore.java (rev 0)
> +++ platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListStore.java 2009-08-25 13:03:08 UTC (rev 22900)
> @@ -0,0 +1,621 @@
@SuppressWarnings should only be used when there's no other way. It's
better to fix the warning.
> +@SuppressWarnings("serial")
> +public class WatchListStore implements EventListener
> +{
These two are very generic, I think they should be defined in the XWiki
Syntax.
> + /**
> + * Character used to separated wiki and space in XWiki model.
> + */
> + public static final String WIKI_SPACE_SEP = ":";
> +
> + /**
> + * Character used to separated space and page in XWiki model.
> + */
> + public static final String SPACE_PAGE_SEP = ".";
Enums are supposed to elliminate (or at least reduce) elseif
programming. This could go in a method of the enum.
> + private String getWatchListClassPropertyForType(ElementType type)
> + {
> + if (ElementType.WIKI.equals(type)) {
> + return WATCHLIST_CLASS_WIKIS_PROP;
> + } else if (ElementType.SPACE.equals(type)) {
> + return WATCHLIST_CLASS_SPACES_PROP;
> + } else if (ElementType.DOCUMENT.equals(type)) {
> + return WATCHLIST_CLASS_DOCUMENTS_PROP;
> + } else {
> + return StringUtils.EMPTY;
> + }
> + }
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi all,
The subject has been discussed already, see for example
http://markmail.org/message/h5e2qinrhsf2slww
The idea is to create a new top level project for modules (modules in
the sense of everything applications, macros, components, plugins, skin
extensions, etc.) that are not part of any products (or the platform)
and that are not necessarily contributed by the XWiki development team.
The difference with the sandbox is that sandbox is a place for modules
being incubated, and that are not in a finished state. Thus, I think one
of the rule for introducing new modules in the xlet repository would be
that a functional version of the module should be released and available
for download (for example on code.xwiki.org).
The name "xlet" is the name we've use historically to talk about this
repository, this is open for discussion. (personally I like the name -
we have to agree this is how we want to name a XWiki "pluggable module"
in the large sense).
Here is my +1 for the above
I would also like to propose that we create a new category of JIRA
projects : "XWiki Contributed Xlets" (or equivalent name) for such
projects that desire to track issues for their released module, and have
the tracker hosted by XWiki.org. I believe this will make easier to have
real release cycles for such modules (for example, we can link to the
JIRA project from the code.xwiki.org "module" page so that users can
report issues instead of using the comments, we can use JIRAs changelog
for release notes on the download page, etc.)
And my +1 for this second proposal
Please, let me know what you think
Jerome.
Hi,
In order to fix issue http://jira.xwiki.org/jira/browse/XWIKI-4428
I've had to dive very deep and fix Sun's URLClassLoader which has a
large number of problems. To do so I had to rewrite several classes
and I've taken sources from Emory Utilities (http://dcl.mathcs.emory.edu/php/loadPage.php?content=util/features.html#cla…
) and modified them slightly (since they were missing the ability to
support custom URL Stream handlers).
So I have a new URIClassLoader that extends URLClassLoader + a set of
associated classes (stream handlers and url connection implementations).
I'd like to commit this in a new xwiki-classloader module, dedicated
to classloading code (same as we have xwiki-xml for ex).
Let me know if you need more details.
Here's my +1
Thanks
-Vincent