xwiki-devs April 2010

xwiki-devs@xwiki.org

34 participants
77 discussions

[xwiki-devs] [PROPOSAL] Configuration based generic rendering cache

by Thomas Mortagne

Hi devs, I'm working on a generic rendering cache system base on configuration. You can see a first version on http://jira.xwiki.org/jira/browse/XWIKI-5110 (The reason why there is already a complete working POC is because it has been tested for a client need and now i'm writing this proposal to integrate it in standard). The idea is to be able to list pages to cache without touching them (that would be more cache macro in xwiki/2.0 syntax or $context.setCacheDuration in xwiki/1.0) and whatever the syntax. = Proposal = 1. The main configuration is a regexp patter based list of document full references (wiki:Space.Page). Here is an example of xwiki.properties configuration: core.renderingcache.documents=xwiki:Blog\..* core.renderingcache.documents=[0-9][0-9][0-9][0-9]_[0-9][0-9]_ The other proposed configuration for now are: is this feature enabled (disabled by default IMO), size of the cache (the size include the number of document and the number of panels for each document which are separated cache entries as well and different languages etc... so it's not the number of cached documents), time to live in the cache (the same for the whole cache, it's a pain to configure something for each document in a central configuration and i'm not sure we really need that). I plan to provide configuration at xwiki.properties and XWiki.XWikiPreference level so the configuration could be different by wiki. 2. Caching is done at XWikiDocument#getRenderedDocument methods level. Currently the POC I did also cache document panels (the result of the panels in the context of the listed document), problem is that at XWikiDocument#getRenderedDocument level it's very difficult to know what is the real current document. All existing way would be hacks since there is no official way to get the panel document from java. Note that you have the same result with $context.setCacheDuration: every rendering done after the call to $context.setCacheDuration is cached and panels are generally rendered after the document content. 3. When a document is modified the cache values related to this document are automatically invalidated. So you don't have to wait to see new content. 4. Each cache value is unique based on the following informations * current document reference * current action * current language * calling URL query string * source (that's how panels are supported, it's same informations except for the source) I insist on the fact that it does not cache the result of the html page but each rendered content. For example all skin and template related content is not cached (menu bar, comments UI, etc...). = Nice to have but not easy currently = a. Extends 2. to also support modifications on included documents. That would be definitely nice and it should be done at some point I think but currently we don't really have any clean generic way to get all documents included for sure (includes inside other macros are not listed by the existing API for example, that would need some refactoring). b. Separate document cache and panels cache. As I already witten that's would need important refactoring to not be a hack. = Side notes = I. This proposal comes with a generic document reference based cache component which take care of the event based cache invalidation system (3.) and support cache keys based on document reference and extensions (4.). We could reuse this component in other document reference based keys caches like image plugin. WDYT ? -- Thomas Mortagne

14 years, 4 months

[xwiki-devs] [PROPOSAL] Rendering l10n

by Thomas Mortagne

Hi devs, We need to support some way internationalization of everything in the rendering that appear in the UI, for now it's mainly related to macros. What I propose is to introduce the rule that any displayable String returned by the API (MacroDescriptor#getName, ParameterDescriptor#getDescription, etc.) could be a l10n key. Then the API user call the l10n component to get the final String. pros: - no need to touch the current API - it avoid having complex API to support l10n specifics and makes pretty much everything depends on l10n component. It's easier for macro author to write a quick macro with some description without having to create l10n resource and call the l10n component just for english for example. - the displayer can control how to get actual translations the way it wants - we need something like that for wiki macros anyway: XWiki does not support translations of objects yet (and for long I guess since the issue is at database level) and it would be a pain to have to copy the content of the macro by language since most of the time the script of the macro would not be related to the language cons: - it's more work for the API user to filter the String with the l10n component to get the actual final String One detail I'm not sure of is if we introduce some syntax to explicitly indicate it's a l10n key or if we just always give the String to the l10n component which will return it as it is if it can't find any matching key. Having an explicit way to indicate a String is a key would be better to track l10n keys bugs but introduce a syntax is always more complex (what chars to choose, how to escape, etc...). WDYT ? Thanks, -- Thomas Mortagne

14 years, 4 months

Re: [xwiki-devs] [xwiki-notifications] r28464 - platform/web/trunk/standard/src/main/webapp/templates

by Sergiu Dumitriu

On 04/20/2010 07:30 PM, dgervalle (SVN) wrote: > Author: dgervalle > Date: 2010-04-20 19:12:25 +0200 (Tue, 20 Apr 2010) > New Revision: 28464 > > Modified: > platform/web/trunk/standard/src/main/webapp/templates/edituser.vm > Log: > XWIKI-5126 Link to force editing a locked user is wrong in new UI > > Change applied as described > > > Modified: platform/web/trunk/standard/src/main/webapp/templates/edituser.vm > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/templates/edituser.vm 2010-04-20 14:07:08 UTC (rev 28463) > +++ platform/web/trunk/standard/src/main/webapp/templates/edituser.vm 2010-04-20 17:12:25 UTC (rev 28464) > @@ -6,7 +6,7 @@ > <div> > $msg.get("doclockedby") $xwiki.getLocalUserName($doc.getLockingUser()). > <br /> > -<a href="$doc.getURL("inline", "$!request.getQueryString()&force=1")">$msg.get("forcelock")</a> > +<a href="javascript:window.lb.lbLoadForm('$doc.getURL("inline", "$!request.getQueryString()&force=1")')">$msg.get("forcelock")</a> No, no, no! We don't allow javasript: in links. > </div> > #else > <div class="clear"> -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 4 months

[xwiki-devs] XWiki Logo Challenge, Round 2

by Sergiu Dumitriu

Hello XWiki Community, We're still looking for the new XWiki.org logo. First of all, many thanks to all those who submitted their ideas ( http://dev.xwiki.org/xwiki/bin/Community/LogoChallenge ). After the first round of votes (digest here: http://spreadsheets.google.com/ccc?key=0Ah6DqXzfHT2vdHV5Ty1LX3lKU3U5V3M4YmN…), we chose 6 "popular" proposals for the second round: http://dev.xwiki.org/xwiki/bin/Community/LogoChallengeRound2 . The authors of these proposals were asked to do the following, if not already done for round 1: * try to integrate any constructive feedback that came with the votes (a digest of the feedback from the emails is available for each proposal on http://dev.xwiki.org/xwiki/bin/Community/LogoChallengeRound2 ) * polish the design (if they consider it necessary) * provide the requested variations for .org, enterprise and office * provide samples for light and dark background * provide a black&white version * provide a 16X16 icon containing the logo or a representative part of the logo * provide a nice "Powered by XWiki" button that goes with the logo * provide a mockup/screenshot with the logo used in the current skin, colibri For most of the finalist logos, the _final_ versions were already uploaded here: http://dev.xwiki.org/xwiki/bin/Community/LogoChallengeRound2 . For those who were not updated, we will use the initial submissions for round 2 as well, and voters will have to use their imagination in case any of the required use cases is missing. VOTING: You can send your vote on the mailing list (devs(a)xwiki.org or users(a)xwiki.org), in reply to this email. No twitter votes this time. Each voter can grant a whole +1 to only one of the 6 finalists ( http://dev.xwiki.org/xwiki/bin/Community/LogoChallengeRound2#HFinalistpropo… ). IMPORTANT: Before choosing a logo based on your personal preference, please try to also ask yourself the following questions: * Is it distinctive? Note that it should not resemble other logos, including the XWiki SAS/xwiki.com logo. * Is it easy to remember and recognize? * Does it blend in smoothly with the Colibri skin? With the new XWiki.org skin? Note that adjustments to the skin is possible, in order to better integrate with the logo. * Is the design scalable? Could it (or parts of it) be successfully used in a 16X16 icon? Would it look good on a very large poster? * Can it be used (as it is, or adapted) on both light and dark backgrounds? * What would it look like in black and white (not just grayscale)? It's ok if some details are lost, but it needs to still look attractive and keep the main features. TIMELINE: 08/Apr/10 : Beginning of second round of votes on devs(a)xwiki.org, users(a)xwiki.org 11/Apr/10 : End of votes Thanks, -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 4 months

Re: [xwiki-devs] [xwiki-notifications] r28419 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web

by Vincent Massol

On Apr 17, 2010, at 3:47 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-04-17 03:47:52 +0200 (Sat, 17 Apr 2010) > New Revision: 28419 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java > Log: > XWIKI-5121: Weird behavior when deleting the head of the history of a renamed document > Fixed. > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java 2010-04-17 01:23:30 UTC (rev 28418) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java 2010-04-17 01:47:52 UTC (rev 28419) > @@ -73,6 +73,10 @@ > // If we delete the most recent (current) version, then rollback to latest undeleted version. > if (!tdoc.getRCSVersion().equals(archive.getLatestVersion())) { > XWikiDocument newdoc = archive.loadDocument(archive.getLatestVersion(), context); > + // Reset the document reference, since the one taken from the archive might be wrong (old name from > + // before a rename) > + newdoc.setDocumentReference(tdoc.getDocumentReference()); > + newdoc.setMetaDataDirty(false); > context.getWiki().getStore().saveXWikiDoc(newdoc, context); > context.setDoc(newdoc); > } hmmm... when a doc is renamed, if we restore a version before the rename, shouldn't we get back the old, not renamed, document? Thanks -Vincent

14 years, 4 months

[xwiki-devs] [Proposal] Add file access module to allow secure access to the filesystem.

by Caleb James DeLisle

Currently we have 109 instantiations of the File class spread over 40 java classes. Each one of these has as much access to the filesystem as the user. My proposal is to create a new module in the core which manages access to the filesystem. I would like the module to provide roles for read-only and read/write files or directories. ReadOnlyFile and ReadWriteFile would extend java.io.File and override getParentFile() which allows the owner of a single file to walk the directory tree. Imagine the following situation: A class called Alice needs to be able to read all files in ./skins/ and she needs to be able to write to ./work/alice.txt If we use the component system she might say: @Requirement("./skins/") ReadOnlyFile skinsDirectory; @Requirement("./work/alice.txt") ReadWriteFile workFile; Now suppose an attacker is able to completely compromise Alice and make her execute whatever bytecode he wants. Lets also suppose we have implemented a SecurityManager which prevents Alice from loading the File class or accessing Utils.getComponent. The attacker will be able to read the files in ./skins/ and will be able to read and write to /work/alice.txt but he won't be able to read other files or create new files because Alice has no references to the component manager and thus cannot access additional files. We can leverage the component system to easily provide security using principle of least permission. WDYT? Caleb

14 years, 4 months

[xwiki-devs] Fwd: [webdriver] New release made

by Vincent Massol

fyi -Vincent Begin forwarded message: > From: Simon Stewart <simon.m.stewart(a)gmail.com> > Date: April 19, 2010 11:32:45 AM GMT+02:00 > To: webdriver <webdriver(a)googlegroups.com>, selenium-developers <selenium-developers(a)googlegroups.com> > Subject: [webdriver] New release made > Reply-To: webdriver(a)googlegroups.com > > Hi, > > I've just uploaded the JARs for a new alpha of Selenium 2: selenium > 2a3. This contains bug fixes and enhancements including: > > * Better Firefox 3.6 support. > * HtmlUnit 2.7 added. > * The ability to return arrays from the JavascriptExecutor. > * New remote protocol implemented by all remote drivers, including Firefox. > * Better native event support for Firefox on Linux. > * Oodles of bug fixes. > > Note: because of the changes in the wire protocol, you must update the > remote server and the client jars at the same too. Also, the Firefox > driver is now using that same protocol. If you're having trouble > starting it up, then make sure that everything is up to date! > > Jari, Jim, Jason and Michael: could you please update the language > bindings and maven contents that you're so capably owning? > > Patrick, I write some release notes and put them up on the blog. > > Regards, > > Simon

14 years, 4 months

[xwiki-devs] Implementing the XWiki.org Redesign

by Silvia Rusu

Hi XWiki devs & users, So far we've been talking a lot about redesigning XWiki.org and all feedback was greatly appreciated. Now it's time we started implementing the redesign Caty was so kind to come up with based on our suggestions. Like the proposal stage this too will be a collaborative effort and we hope you'll join in building an even better site for XWiki.org. The following is a list of things that need to be implemented in order to get us started. It would be great if you'd volunteer for the implementation of the tasks at hand. Please add your name next to the issue you'd like to assign yourself too. Also feel free to add as many other issues you think should appear on the list and to volunteer for those issues as well. Here is the first list of tasks: * Set up the server for the new website (Alex? :) ) * Add the horizontal navigation to the new website * Implement the projects carousel for the homepage * Implement the panels for "Latest Releases", "Latest Extensions". "Latest News"(should display the latest 5 releases, extensions, news) Documentation/Projects * Implement the left navigation for documentation/projects * Implement the panel for the "Latest Documentation Updates" (should display the last 5 documents and their authors) Community page widgets and panels: * Implement the"Development Status" panel, if it's going to have dynamic content * Implement the "Top Committers" panel (show the committer's picture and number of commits) * Implement the "Latest Commits" section (should display an image of the committer, what (s)he commited, the name of the committer and the date the commit was made) * Implement the "Latest Issues" section (should have the latest Jira issues, the person who took an action with regard to the issue - e.g. create, close - and the time the action was taken) * Implement the "Latest Discussion" section (display the list, the topic discussed, the name of the person that added the latest reply and the time he added the answer) * Implement the "Latest Documentation" section (show the number of lines added/deleted, the name of the document, the author of the modification and the time (s)he made the changes) * Implement "Latest Extensions" section (display the extension name, the name of the person that added the extension, the time it was added and a short description) You may read what has already been discussed about the redesign on this page http://markmail.org/message/tfmrludhw2yh5tcn#query:+page:1+mid:h5bukrijteeu… See the latest redesign proposal here http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2 Thanks, Silvia

14 years, 4 months

[xwiki-devs] Contribution to the DatePicker application

by Raluca Stavro

Hello devs, I would like to contribute to the DatePicker application. Currently, the DatePicker stylesheet does not take in account the color theme. This is why I created a Jira issue (XCONTRIB-109) and I attached a patch to it. You will see some screenshots with the new styles applied on the DatePicker table. Can someone please give me the right to commit those styles? Raluca.

14 years, 4 months

[xwiki-devs] Should email invitation code be an application? How should it be put in sandbox?

by Caleb James DeLisle

I have a reasonably clean revision of the code for inviting friends to join the wiki. Should it be a separate application with it's own jira project? It's not very large but may grow. I can't imagine what other application it should be filed under. I'd like to put it in the sandbox so it can be subject to review and discussion but I don't know how that should be done. I guess that depends on whether it is going to be it's own application. Any thoughts? Caleb

14 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs April 2010