Hi Everyone, Hi Marius,
I have successfully load my GWT tree on to the Xwiki page. I met a new
problem which is that I cannot add the background color button to the
toolbar of WYSIWYG editor. I have read the document:
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/WysiwygEditor#HXWikiPre…
and I tried two ways, first is to edit templates/macros.vm I edited this
line: toolbar: '$xwiki.getXWikiPreference("wysiwyg.toolbar", "bold italic
underline strikethrough backcolor teletype | subscript superscript |
unorderedlist orderedlist | outdent indent | undo redo | format fontname
fontsize forecolor backcolor | hr symbol | link unlink | importer")', No
matter where I put "backcolor forecolor" it just would not show up.
Second I added wysiwyg.toolbar as String property to Xwiki.preferences
class, and edit the Xwiki.preferences in the object editor and I put bold
italic underline strikethrough teletype | subscript superscript |
justifyleft justifycenter justifyright justifyfull | unorderedlist
orderedlist | outdent indent | undo redo | format | fontname fontsize
forecolor backcolor | hr removeformat symbol as value of wysiwyg.toolbar,
please see the screenshot for what I did:
http://picasaweb.google.com/lh/photo/yi-zwcDtr4ibfePckJ56tg?feat=directlink
After that the background colorWYSIWYG editor still does not appear. please
see the screen shot:
http://picasaweb.google.com/lh/photo/I1ALHBmG7YjGanyDT8i3kw?feat=directlink
Could
you give me some ideas what was wrong?
I successfully load my GWT tree view to Xwiki right side pannel(Thank you,
Marius.) I want to make it interact with WYSIWYG editor. For example, if
user highlighted one sentence from a document in the WYSIWYG editor and
clicked on one node of the GWT tree say "Argument", then it will set the
highlighted sentence's background yellow(or blue). Could you give me some
ideas how can I make the tree interact with WYSIWYG editor like that?
Thank you for your help! Really appreciate it!
Hi,
Is there a way to register a Wiki Macro through scripting. When I import
a Wiki Macro it does not seem to get registered and when I do
$doc.save() on it it does not register it either.
I suppose it's because we intercept the save at a different level
(probably on the save action).
How can I workaround that ?
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi,
Since we need 65MB of perm size and since Sun's JVMs have it set to 32
(client) or 64MB (server) by default I propose to modify our default
shell script that start xwiki with:
JAVA_OPTS="-Xmx300m -XX:MaxPermSize=64m"
WDYT?
Note that strangely for me, I get 64m+32m=96mb of non heap space with
this setting. If I use MaxPermSize=96m then I get 128mb. I still
haven't figured this out.
Could it be that MaxPermSize is the additional memory from the default
(32m for client)?
Thanks
-Vincent
Hi Devs,
Inspired by the newly launched W3C website, I'd like to introduce the
possibility to choose the display mode: desktop (the current UI),
print (the current print preview UI) and mobile (a 1-column,
margin-free layout). I'd like to group these options in a new action
menu entry, named DISPLAY (or VIEW) and placed between EDIT and EXPORT
(I can't find a good position, suggestions welcome). In the same menu
we can reintroduce the View Wiki Source feature (
http://jira.xwiki.org/jira/browse/XSCOLIBRI-122 ).
So basically, the menu changes are:
- new DISPLAY menu, with the options: Desktop, Mobile, Print, Wiki Source
- the chosen display mode (except wiki source) is sticky, meaning that
it will continue to be used for the following page views
- Print Preview disappears from ACTIONS
Any objections/comments?
--
http://purl.org/net/sergiu
The XWiki development team is (not so) pleased to announce the release
of XWiki Enterprise Manager 2.0.1.1.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This release fix one critical bug found in XWiki Enterprise Manager 2.0.1.
* XAWM-106 - NullPointer Exception on WikiManager.CreateNewWiki page
For more information see the Release notes at
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM2011.
Thanks
-The XWiki dev team
On 10/14/2009 06:59 PM, notifications(a)xwiki.org wrote:
> Hello Developers,
>
> This message is sent by XWiki. Here are the documents in your watchlist
> that have been modified since the last notification:
> XWiki.flavius
>
>
> Between 2009/10/12 15:15 and 2009/10/12 15:17, the document has
> been modified 2 times, by 2 user(s): Flavius Olaru, Jerome Velociter
>
> XWiki.XWikiUsers
> password:
> hash:SHA-512:ee26b0dd4af7e749aa1a8ee3c10ae9923f618980772e473f8819a5d4940e0db27ac185f8a0e1d5f84f88bc887fd67b143732c304cc5fa9ad8e6f57f50028a8ffhash:SHA-512:01ee4ab961b2f3f35fce8412d7facc44cd68782ed1b1810e849f21420583df04bee183d2b740d33417584e14fbc0dfc9d6232d2ce814012146840a69fdb2f31f
> author: XWiki.jvelociter > XWiki.flavius
^^^
This is not right.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi Devs,
This time I'm looking for an experienced XWiki developer in Spain :-)
Ideally I'm looking for a Web / Java developer who speaks both Spanish and
(English OR French) fluently and would be interested in a consulting gig
working on XWiki.
Any pointers?
Guillaume
--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
On 10/12/2009 03:48 PM, tmortagne (SVN) wrote:
> Author: tmortagne
> Date: 2009-10-12 15:48:22 +0200 (Mon, 12 Oct 2009)
> New Revision: 24360
>
> Modified:
> platform/core/trunk/xwiki-cache/xwiki-cache-jbosscache/src/main/java/org/xwiki/cache/jbosscache/internal/JBossCacheCacheConfiguration.java
> Log:
> XWIKI-4452: Upgrade to last JbossCache 3.x version
> * fix maximum time to live new handling in LRU (used to be 0 for infinite, it's now -1)
Isn't there a constant that can be used instead of a direct number?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
Following our roadmap definition (now on http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap)
here are some date proposals for XE 2.1:
* 2.1 M1: 26 Oct (that's 4 weeks after the 2.0 release)
* 2.1 M2: 16 Nov
* 2.1 RC1: 30 Nov
* 2.1 Final: 7 Dec
Here's my +1 to commit to this schedule.
Note that I propose a not too long release (2 months and 2 weeks)
since 2.1 is meant to be a stabilization release with not many new
things. The new things should be for 2.2 in 2010.
Thanks
-Vincent
Hi Devs,
I've been refactoring OfficeImporter code base to make it more modular and
maintainable. With these refactorings I believe we can improve the main
OfficeImporter API. Currently OfficeImporter component interface exposes
following two methods:
<code>
void importStream(InputStream documentStream, String documentFormat, String
targetWikiDocument, Map<String, String> params) throws
OfficeImporterException;
String importAttachment(String documentName, String attachmentName,
Map<String, String> params) throws OfficeImporterException;
</code>
Problems with these two methods are;
* Loosely typed (params)
* Both of them perform almost the same task.
There is also a problem with how customizations to the normal import process
is implemented.
So, I propose we deprecate these two methods and introduce following
methods:
<code>
XHTMLOfficeDocument officeToXHTML(byte[] officeFileData, String
referenceDocument, boolean filterStyles) throws OfficeImporterException;
XDOMOfficeDocument xhtmlToXDOM(XHTMLOfficeDocument xhtmlOfficeDocument)
throws OfficeImporterException;
XDOMOfficeDocument officeToXDOM(byte[] officeFileData, String
referenceDocument, boolean filterStyles) throws OfficeImporterException;
XDOMOfficeDocument buildPresentation(byte[] officeFileData) throws
OfficeImporterException;
Map<TargetPageDescriptor, XDOMOfficeDocument> splitXDOM(XDOMOfficeDocument
xdomOfficeDocument, int[] headingLevelsToSplit, String namingCriterionHint,
String baseDocumentName) throws OfficeImporterException;
</code>
As you can see, these methods are more granular and the responsibilities are
well defined. Customizing the import process can be done from the client
code. For an example:
1. Make the initial import from office to XHTMLOfficeDocument.
2. Perform customizations on the XHTMLOfficeDocument (w3c DOM).
3. Import the XHTMLOfficeDocument into XDOMOfficeDocument.
4. Perform customizations on the XDOMOfficeDocument (XDOM).
5. Split the XDOMOfficeDocument into multiple XDOMOfficeDocument instances.
6. Perform customizations on these child XDOMOfficeDocument instances.
7. Render the XDOMOfficeDocument instances & save them into wiki pages.
(saving can be done in client code)
I think this interface will make it easy to extend & maintain officeimporter
functionality in the future. For an example, a preview function can be
implemented with above methods (which is not possible with the previous
interface).
WDYT?
Here's my +1.
Thanks.
- Asiri
Hi,
I've played a bit with Yourkit and a default XE to see the memory
requirements. Here are some preliminary results (more tests needed):
* After home page loaded: 38MB non-heap, 6377 classes
* After code macro execution: 38 --> 52MB non heap, 8629 classes <---
a lot
* After groovy macro execution: 52 --> 56MB, 9920 classes
* After treeview + opened top level nodes: 56MB --> 63MB, 10960
classes <-- a lot
* After Import: 63MB --> 65MB, 13036 classes
* After Export: no change
* After navigating a bit everywhere at random: heap memory needed:
155MB (used: 132MB), non heap: 65MB, classes: 13078
* After adding attachment of 1.1MB: almost no change
* After deletion of 1.1MB attachment: used memory from 98MB to
132MB !! But still within the 155MB allocated heap memory
Conclusion so far:
==============
* We need around < 80MB non heap memory and < 200MB heap memory for
the default XE pages and if the user manipulates attachments less than
1MB.
* The default permgen size is 64MB so we're just above it (65MB).
That's why some users have reported permgen issues I believe. Jython
is eating a lot of it (14MB)
* After adding a 7.3MB attachment: heap memory max from 155 to 261
(=>110MB!)
* After removing it, need 297MB heap (even more)
Second conclusion:
==============
* Apart from attachments the memory needs seem reasonable IMO (< 255MB).
* I'd still need to make sure I test all features of the wiki to be sure
What more should I test? What should we do to reduce our permgen
needs? Should we reduce it?
Thanks
-Vincent
Hi XWikiers,
XWiki has been selected among a set of other candidates to create a video
describing what the product does. Winners get a chance to present on stage
at the Enterprise 2.0 Conference in San Francisco next November. Please vote
for the video at:
*http://launchpad.e2conf.com/vote-now/* (XWiki is the last video, at the
bottom of the list)
and help give XWiki a chance to present on stage at the Enterprise 2.0
Conference !
RT appreciated ;-)
Many thanks in advance,
Guillaume
--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
Hi Everyone, Hi Marius,
Sorry, last message I have not finished and I pressed the space key
mistakenly and it have been sent.
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?
Marius, you said "to include the JavaScript code so that it ends up in your
HTML page's head not body". Could you explain a little what do you mean by
page's body and head?" by head do you mean on the top of the page.
Thank you for your help!
Leon
Hi Everyone, Hi Marius,
Maybe the last three of unclickable mail html is generated before and saved
in the page. I will farther look into this. Thank you.
Here is the last email that I sent:
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?
Marius, you said "to include the JavaScript code so that it ends up in your
HTML page's head not body". Could you explain a little what do you mean by
page's body and head?" by head do you mean on the top of the page.
Thank you.
Leon
http://code.google.com/p/gruple/ <-- seems potentially useful for use w/
xwiki; distributed/replicated wikis, realtime-collaboration wikis and other
future work... This will become more useful once "future release" allows
coordinating across processes, not just threads:
> A concurrent programming library written in Groovy, providing simple
> programming models for complex multi-threaded tasks.
Introduction
At its core, Gruple provides an in-process tuplespace abstraction to enable
a JavaSpaces-style programming model for communication and coordination
among threads. (A remote implementation allowing coordination among
processes is planned for a future release.)
Getting Started
The current release implements an in-memory tuplespace, with basic
operations (put, get, and take.) See the
Overview<http://code.google.com/p/gruple/wiki/Overview> page
for an introduction to the project, and the
TuplespaceUsage<http://code.google.com/p/gruple/wiki/TuplespaceUsage>
page
for documentation. Also be sure to try the
Demos<http://code.google.com/p/gruple/wiki/Demos>
See the Project Roadmap <http://code.google.com/p/gruple/wiki/Roadmap> for
other planned features.
Niels
http://nielsmayer.com
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