xwiki-devs March 2012

xwiki-devs@xwiki.org

38 participants
87 discussions

[xwiki-devs] XWiki WebDAV for MSOffice read-write mode

by bouderbala＠nearbee.com

Hello all, I would like to use XWiki WebDAV for editing MSOffice documents online To do this in read-write mode, we must configure XWiki WebDav on ROOT. Instead of opening the document from: http://myserver.test/xwiki/webdav/spaces/test/msoffice/Bonjour.docx we must open it from: http://myserver.test/spaces/test/msoffice/Bonjour.docx This is what I did: - I am running Tomcat 7 / XWiki Enterprise V2.6 - I renamed the ROOT context xwiki - I changed the servlet-mapping like this <servlet-mapping> <servlet-name>webdav</ servlet-name> <url-pattern>/*</ url-pattern> </ servlet-mapping> Now I can't even request the document http://myserver.test/spaces/test/msoffice/Bonjour.docx I have response: HTTP Status 400 - Bad Request Is there any solution XWiki WebDAV to open MSOffice in read-write mode ? Thanks in advance

12 years, 5 months

[xwiki-devs] Pretty Time library

by Vincent Massol

Could be useful: http://ocpsoft.com/prettytime/ Idea of usage: For ex we could use that to show the last modified document dates for dates in the past week (for ex): "Document created 2 days ago" It's in the maven central repo and it's under LGPL -Vincent

12 years, 5 months

[xwiki-devs] [VOTE] Improving documentation and automating our Release Notes when doing releases

by Vincent Massol

Hi devs, Sergiu has started a script to fully automate a release (more to come - Sergiu will document what it does soon). The only part not automated are the Release Notes. IMO we can "automate" it by a process which I propose to be: * An issue can only be closed if it's documented on xwiki.org and on the release notes page for the upcoming release. * We collectively enforce this by reopening issues if someone doesn't do the first point, asking him/her to do it This will have some nice effects: * xwiki.org will be more up to date than it is now * it's up to the developer to document what they do (I don't think it's good to push this to someone else) which is good since they have the most knowledge (side note: it doesn't mean we don't need a technical writer to improve on the documentation done by developers but it would be about style and not about content) * the release notes will be ready for the release, as we progress and the burden of writing the release notes will not fall on the shoulders of the Release Manager (there's no reason it should) * the whole release process will almost be a joy to do * with a fully automated release process it means we'll be able to perform a lot more bugfix releases which is good for our users Here's my +1 Thanks -Vincent

12 years, 7 months

[xwiki-devs] [GSoc] Advanced Email Integration

by Vincent Massol

Hi everyone/Jerem, I've seen that we've added the following GSOC project: http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/AdvancedEmailIntegra… This looks quite similar to what Jerem is working on. Jerem, maybe you could tell us a bit more about your project and how it's similar/different than this GSOC. Jerem, any timeframe for a first version of your project to be visible? Is this something you're developing for yourself or do you plan to give it to the community or even to the XWiki project? I'd like to clarify this to know how to best organize this project to not duplicate efforts too much and instead to combine synergies. Thanks -Vincent

12 years, 7 months

[xwiki-devs] [PROPOSAL] Use relative URLs instead of external URLs with sendRedirect

by Thomas Mortagne

Hi devs, In HTTP specifications a redirect is always absolute URL which is probably why we use absolute URL with sendRedirect. However sendRedirect does not produce direct HTTP response but allows relative URL and delegate to the application server the job of producing proper absolute URL. IMO XWiki should always use relative URL everywhere it can so I propose to change our practice to use relative URL instead of absolute URL with HttpSevletResponse#sendRedirect when possible. The only reasons I see to use external URLs are: * interwiki URL in a domain based multiwiki * html/pdf export for links pointing on not exported pages or non view actions WDYT ? Here is my +1. We very often fix bugs in the way to produce external URL and it's still not OK (see http://jira.xwiki.org/browse/XWIKI-7632) so lets reduce the scope for this need as much as possible. -- Thomas Mortagne

12 years, 7 months

[xwiki-devs] Simple Mobile Skin

by Ludovic Dubost

Hi, I've been working a while ago on a Mobile Skin which principle is the following: 1/ Light UI adapted to mobile devices, both phones and tablet (with a particular attention to tablets), giving most of the screen real estate to the page content 2/ Support all Javascript normally supported in the XWiki skin in order for any code inside pages that would use this Javascript to still work 3/ Automatic detection of mobile devices to make them switch to the mobile skin 4/ Ability to switch from mobile to normal skin 5/ compatibility with color themes I believe this approach is the right one, as XWiki instances do have significant Javascript and in order to make sure these pages work, we need to be able to accept this javascript. Of course some other improvements could be done, for example to have a mobile friendly dashboard or livetable. Now this work has had a few iterations with particularly some relooking work from Caty. The work is published here: http://extensions.xwiki.org/xwiki/bin/view/Extension/SimpleMobileSkin And the code is available here in both XAR and File-System version (for XEM): https://github.com/ldubost/xwiki-mobileskin The skin can be tested on the incubator (although there is not the automated switch) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/34Proposal?skin=XW… I've also worked on integrating this in the platform. The commit is available in a fork on github: https://github.com/ldubost/xwiki-platform/commit/064baeb017b35e08a526029381… I'd like some comments and discussion so that we can bring this into the platform. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

12 years, 8 months

[xwiki-devs] [Proposal] Changes to Page Creation needed for Application Within Minutes

by Marius Dumitru Florea

Hi devs, For the upcoming Application Within Minutes I need to enhance the XWiki platform with the ability to generate the page name automatically when creating a new wiki page. For some applications it doesn't make sense to have two creation steps: (1) specify the wiki page name (i.e. the location) and then (2) edit the new wiki page with the specified name. Let me give you two examples: * It would be cool to be able to create a new blog post in a single step. The blog post name could be generated from the blog post title specified in the edit form. * An application that manages holiday requests doesn't need meaningful page names (i.e. free text, like a blog post would have) but something like Request_XYZ, where XYZ is a unique counter/identifier. These applications should be able to create new wiki pages with automatically generated names without writing their custom create forms. Since 3.2RC1 was planed for today and these changes are in the 3.2 roadmap, here's a proposal that I think I can implement quickly and safely: (1) Introduce two new components: // Used to generate a document name that doesn't have to be unique (e.g. by cleaning the document title). DocumentReferenceGenerator#generate(DocumentModelBridge):DocumentReference // Used to make a document name unique (by suffixing an unique counter/identifier) DocumentReferenceDifferentiator#differentiate(DocumentReference):DocumentReference (2) Modify editinline.vm to store "documentReferenceGenerator" and "documentReferenceDifferentiator" request parameters in two hidden input fields so that they are passed to the save action. Obviously, these are component hints. (3) Modify editactions.vm to replace "Save & View" + "Save & Continue" with "Create" when "documentReferenceGenerator" or "documentReferenceDifferentiator" (or both) request parameters are set. (4) Modify SaveAction to take into account these two request parameters (only if they are specified). Something along these lines: generateDocumentReference(doc) synchronize(lock) { doc.copyDocument(differentiate(generatedDocumentReference)).save(); } I'm not sure where to place the two components from (1) though. WDYT? Thanks, Marius

12 years, 8 months

[xwiki-devs] [VOTE] Creation of xwiki-platform-uiextension module

by Vincent Massol

Hi devs, I'm implementing the LinkChecker UI and I want to be able to add a Tab in AllDocs. Right now I've coded it with a hardcoded #if but I really hate this. So here's my proposal: * Create the following modules: xwiki-platform-uiextension/ |_ xwiki-platform-uiextension-ui/ |_ xwiki-platform-uiextension-api/ where: * xwiki-platform-uiextension-ui/: contains XWiki.UIExtensionClass page * xwiki-platform-uiextension-api/: contains a ScriptService to get UIExtension data + contains an EventListener that refreshes the UI Extension Cache when an UIExtensionClass object is modified (this is for performance reasons) To start with I'm proposing to have the following fields for UIExtensionClass: * type: String, represents the type of the extension (for example for the AllDocs needs, I'll use a "IndexTab" type (or "AllDocsTab" type) * id: String, the technical name of the extension, which can be used for example as suffix for HTML class or ids. * name: String, the name of the extension, which can be used for displaying. For example for the AllDocs needs, it would be used as the name of the Tab * content: Textarea: the content of the extension. For example for the AllDocs needs, it would be used as the content to display when clicking on a tab I'd like to implement this ASAP and thus stop hardcoding UI Extensions from now on. Here's my +1 Thanks -Vincent PS: If you find a better than "uiextension" I'm all ears. A name without "extension" would be great to not confuse it with our Extensions (and with xwiki-platform-extension).

12 years, 8 months

[xwiki-devs] XWiki on cloud environments

by Fabio Mancinelli

Hi everybody, at XWiki we are participating in different research activities, many of them focused on cloud computing. As a part of this research efforts we've build this project that allows you to deploy XWiki in different cloud environments. In the current state, it allows to build an XWiki distribution that can be deployed on Amazon Beanstalk (http://aws.amazon.com/elasticbeanstalk/) and can also take advantage of the Amazon S3 Blobstore (http://aws.amazon.com/s3/) for storing attachments. The project is extensible, so other environments could be supported (e.g., Openstack SWIFT blobstore, http://swift.openstack.org/) and also deployment that are dynamically configured when started in virtual machines that are started up in other platforms. If you want to have a look you can find it here: https://github.com/fmancinelli/xwiki-platform-cloud For the moment I've put it on my personal GitHub account but I'll move it to XWiki contrib as soon as possible. Thanks, Fabio P.S.: If you want to experiment with it, Amazon provides a free usage tier (http://aws.amazon.com/free/)

12 years, 8 months

[xwiki-devs] monitoring the cache: how to get the eviction rate?

by Paul Libbrecht

Hello developers, I have been doing a nifty little cache monitor on www.curriki.org which is still running xwiki 1.5.4. It can show the entries and capacity of the two xwiki caches, pageExistCache and the document cache which sound pretty central. Not surprisingly, they're both full on our production server. name entries capacity pageExistCache 10000 10000 cache 3000 3000 The caches are using OSCache (through "OSCacheCache"). I've been trying to get a real statistical count but there I kind of failed thus far. I can use the StatisticListenerImpl which gives fairly high numbers: > StatisticListenerImpl: Hit = 9583563 / 1320251374, stale hit = 0 / 538, miss = 8541 / 17175236, flush = 27348, entries (added, removed, updates) = 25457741, 0, 7678101 these numbers are integers, and might actually be too small for the 2billions limit of an int, they are static (so count "all the OSCache instances"). What I would like to get is the "eviction rate" but I do not know how to compute it. That is, I wish to read the number of cache-entries which are thrown away because the cache is full and others come in. Once I can have it, I can start tuning (cache size, less greedy algorithms, ...) and measure the effect of such tuning. We have plenty of RAM space to accommodate the cache but we should use this well. The big annoyance with this process is that it can only run on our production server. So thus far I did not dare register a CacheListener in groovy fearing it would suddenly be slow. Has anyone used a different strategy or tool? I'm happy to post my little monitor script. thanks in advance. paul

12 years, 8 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs March 2012