This could be an interesting way to select media (images, video/audio,
documents) in xwiki:
http://www.simile-widgets.org/runway/
> This widget lets you display images in a rich interactive visualization
> similar to that of Apple iTunes known as Cover Flow. It is a Flash-based
> implementation ... The Flash widget can fire events to update the web page's
> Javascript. .... The web page's Javascript can change the Flash widget on
> the fly. Documentation<http://code.google.com/p/simile-widgets/wiki/Runway>
> Mailing List <http://groups.google.com/group/simile-widgets> (for
> technical support, etc.) Code<http://code.google.com/p/simile-widgets/source/browse/#svn/runway/trunk>(open source, BSD license)...
>
I think it would be useful in the anchor/link wizard in the wysiwyg editor,
lending an itunes style album-cover-flipping style interface to process of
link and image. selection in xwiki. It would be great if we could render
semi-readable scaled-down thumbnails of existing xwiki documents in the
cover-flow browser.
Yet another GSOC project... though I bet the basic interface to 'runway' is
pretty trivial in xwiki ... (e.g. of similar complexity and
interface-ability is the youtube chromeless player:
http://nielsmayer.com/xwiki/bin/view/Todo/YoutubeChromelessPlayer then again
... I can't figure out why my example doesn't work in IE, yet fine in
safari&firefox -- probably because having a menagerie-a-trois of languages
to deal with by adding flash to the picture always leads to trouble...)
Niels
http://nielsmayer.com
Hello Devs,
I'm starting to think about the integration of JCaptcha 2.0
(http://forge.octo.com/jcaptcha/confluence/display/general/Simple+Servlet+In…)
that would deprecated our current Captcha plugin.
I think we need it as a component, for example xwiki-captcha
We can have a CaptchaedRequestValidator component interface that
declares the following method :
boolean validateCaptcha(HttpServletRequest request);
which would be called from the register action, comment add action, etc.
(anywhere a captcha is needed - we could even expose a velocity API if
we need it)
WDYT ?
Regards,
Jerome.
Hi Sergiu,
On Mar 13, 2009, at 12:38 AM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2009-03-13 00:38:08 +0100 (Fri, 13 Mar 2009)
> New Revision: 17602
>
> Modified:
> platform/core/trunk/xwiki-cache/xwiki-cache-tests/src/main/java/
> org/xwiki/cache/tests/AbstractTestCache.java
> platform/core/trunk/xwiki-containers/xwiki-container-api/src/main/
> java/org/xwiki/container/ApplicationContext.java
> platform/core/trunk/xwiki-containers/xwiki-container-portlet/src/
> main/java/org/xwiki/container/portlet/PortletApplicationContext.java
> platform/core/trunk/xwiki-containers/xwiki-container-servlet/src/
> main/java/org/xwiki/container/servlet/ServletApplicationContext.java
> platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/test/
> TestApplicationContext.java
> Log:
> XWIKI-3312: Add a getTemporaryDirectory() method to ApplicationContext
> Done.
> Patch submitted by Dan Miron, enhanced and extended.
>
>
> Modified: platform/core/trunk/xwiki-cache/xwiki-cache-tests/src/main/
> java/org/xwiki/cache/tests/AbstractTestCache.java
> ===================================================================
> --- platform/core/trunk/xwiki-cache/xwiki-cache-tests/src/main/java/
> org/xwiki/cache/tests/AbstractTestCache.java 2009-03-12 23:03:56 UTC
> (rev 17601)
> +++ platform/core/trunk/xwiki-cache/xwiki-cache-tests/src/main/java/
> org/xwiki/cache/tests/AbstractTestCache.java 2009-03-12 23:38:08 UTC
> (rev 17602)
> @@ -19,6 +19,7 @@
> */
> package org.xwiki.cache.tests;
>
> +import java.io.File;
> import java.io.InputStream;
> import java.net.MalformedURLException;
> import java.net.URL;
> @@ -130,6 +131,21 @@
> }
>
> /**
> + * {@inheritDoc}
> + *
> + * @see
> org.xwiki.container.ApplicationContext#getTemporaryDirectory()
> + */
> + public File getTemporaryDirectory()
> + {
> + try {
> + // The system temporary directory is a good place for
> temporary test data.
> + return new File(System.getProperty("java.io.tmpdir"));
> + } catch (SecurityException e) {
> + return new File(".");
> + }
> + }
I don't understand why you had to modify the cache module.
> +
> + /**
> * @return a instance of the cache factory.
> * @throws Exception error when searching for cache factory
> component.
> */
>
> Modified: platform/core/trunk/xwiki-containers/xwiki-container-api/
> src/main/java/org/xwiki/container/ApplicationContext.java
> ===================================================================
> --- platform/core/trunk/xwiki-containers/xwiki-container-api/src/
> main/java/org/xwiki/container/ApplicationContext.java 2009-03-12
> 23:03:56 UTC (rev 17601)
> +++ platform/core/trunk/xwiki-containers/xwiki-container-api/src/
> main/java/org/xwiki/container/ApplicationContext.java 2009-03-12
> 23:38:08 UTC (rev 17602)
> @@ -20,6 +20,7 @@
> */
> package org.xwiki.container;
>
> +import java.io.File;
> import java.io.InputStream;
> import java.net.MalformedURLException;
> import java.net.URL;
> @@ -27,5 +28,15 @@
> public interface ApplicationContext
> {
> InputStream getResourceAsStream(String resourceName);
> +
> URL getResource(String resourceName) throws MalformedURLException;
> +
> + /**
> + * Gets the directory which the container must provide for
> storing temporary data. The contents of this directory
> + * may be deleted between container restarts (<em>temporary</
> em>, as the name implies), so it is not a safe place to
> + * store permanent/important data.
> + *
> + * @return a {@link File} object pointing to a directory that
> the application can use for storing temporary files
> + */
> + File getTemporaryDirectory();
I don't like this too much but it's ok for now. However I don't think
this is a good generic solution for the future. I think it would be
better to implement a temporary storage that uses the same storage api
as the other storages (main storage, version storage, attachment
storage, etc). The pb with returning a File is that 1) it ties us to a
disk storage which might not be available in all environments for
various reasons and 2) it's not extensible and you cannot swap another
implementation (like it you want to use a memory storage for example).
For this we need the new storage/model of course which is why it's ok
to have this now.
WDYT?
Thanks
-Vincent
Dear all,
Restlet uses as its logging system the Java Logging System provided
with the JDK.
So in order to vary its verbosity it's needed to configure that system
by providing a logging.properties like the one located in the JRE/lib.
This properties file is ether passed as a system property through a -D
parameter to the JVM, or explicitly loaded and set using
LogManager.getLogManager().readConfiguration();
In order load this configuration file I did the following: I placed a
logging.properties file in WEB-INF and loaded it in the init() method
of a subclass of the Restlet Servlet.
Now there are several possibilities wrt to where to place the
logging.properties and how to actually name it.
1) WEB-INF/logging.properties
2) The resources of the REST module
3) XWiki Core.
I am +1 for 1 (maybe we can call it java-logging.properties)
WDYT?
Cheers,
Fabio
Hi Devs,
I have a requirement to customize XWiki to integrate with Communities in
a Social Networking Site that I am developing. Members of a Community
should be able to view/edit documents created by other members of the
same community but they should not be able to view/edit documents
created by members of other communities. Essentially, we want to
introduce a 'Community Scope' in XWiki.
The number of communities and members grows with time, obviously.
I think such a feature is not available out of the box. I am planning to
do some customization on the Groups feature of XWiki to achieve this
requirement.
Here is an outline of the approach.
1. When a new community gets created in the social site, create a new
Group of corresponding name in XWiki programatically. (need to know what
API to call).
2. When a user joins a community, automatically add the user to the
XWiki group associated to that community.
3. When a user creates a new document in the community's XWiki, gives
rights to the associated community's Group to that document.
The Rights module of XWiki will automatically take care of the
authorization when that document is requested by any user.
The challenge seems to be identifying the right places in code to make
changes for 1 and 3. (#2 I can try to achieve by overriding
XWikiUser.isUserInGroup() to plugin my custom implementation).
Any pointer in this regard will be greatly appreciated. If there is an
alternative approach to what I am planning, that would be great too.
Thanks,
Rupinder
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
Hello,
What's the current status with:
1) Captcha support on registration?
2) Captcha support on anonymous comments?
(And by captcha I mean something more complicated than "what's 2 + 2?")
3) Sending e-mails with "thanks for registering, click link-here to
activate your account"?
4) Ability to set a SMTP server which requires username+password?
Please, there are many systems where an open smtp, even on localhost,
simply can't / won't be allowed.
5) Ability to delete all comments from a specific user?
6) ... specific IP?
7) ... specific IP range?
8) ... all anonymous comments from a page?
I saw "xwiki.plugin.captcha=" option in xwiki.cfg but it doesn't seem to
do anything?
I really can't see how XWiki can be run in "public mode" without all or
most of the above :/ , preferably enabled out-of-the-box.
Greetings, Lilianne