Vincent Massol writes: document name) It might only be under 1.2 - but if someone downloads an attachment created by a different user, updates it & then uploads the file under the same name, it does not appear as a version of the prior document - it's a new document. To get around this we had to have folks doing updates to authenticate under the same username (for one particular document). Yes, but No :-) I mean with the same show/wide-in-a-box functionality. When creating large pages, this becomes very important - and the toc macro needs a nice wrapper around it ... like mediawiki has ;-) It can definitely wait until 1.5 or later - I was only wishing. How should we best do this? Show the code here (or devs)? The last time I played with xwiki.org, I got slapped :-) (and rightfully so!)

Jean-Vincent Drean wrote: I am not able to reproduce it with 1.2.0 or 1.2.2, and as far as I know nobody ever reported a similar problem, and there never were any code that considered the user name when uploading files. Also, if the files have the same name, it is impossible to store them separately, as they are put in a table indexed (unique key constraint) by a hash function on the attachment + wiki document name. -- Sergiu Dumitriu http://purl.org/net/sergiu/

On Mar 13, 2008, at 3:41 AM, Sergiu Dumitriu wrote: We'll have three solutions after that: 1) Put it on the code zone 2) Put it in the "xlet" SVN that we want to create to people wanting a place to store their xwiki-related projects 3) Integrate it in the Core/Platform Thanks -Vincent

Vincent Massol wrote: Not on this, we're working on SkinExtensions, which is much simpler to implement. The code is mostly done, with the following problems: - We're still trying to decide if YUICompressor is the best choice. It seems to be a good choice when comparing features and functionality, but on the inside it is UGLY! It looks like some quick and dirty C code, although it is at version 2.3.5 (they just removed System.exit as a failure mechanism in 2.3.0!). Unfortunately there is nothing else that does variable minimization, so the choice is whether we use YUICompressor or use something with less compression. - We're still trying to find a place where to do the hook replacement. At first Plugin#endRendering looked like a good option, but it seems that it is not called when parsing templates, so the choice is between writing some custom code in the parse method, or make the plugins also be called for that parsing process, or to call the RenderingEngine#interpret method instead of the current shortcut, which is to call directly VelocityRenderingEngine. So, if we find some time to address these points, we'll have it ready for usage this weekend. I think that I'll have to review the whole parsing/rendering process and fix all those Programming Rights leaks on the way, too, as this is needed for Template Extensions (draft proposal sitting on my computer). As for Interface Extensions, I'll have to modify the proposal to include some of the observations Vincent made, then I'll start working on it. -- Sergiu Dumitriu http://purl.org/net/sergiu/

On Tue, Mar 11, 2008 at 7:05 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: They were not, thanks for the recommendation, I've put the shortcuts in the application resources under core.shortcuts.*. I've commited the feature, suggestions and comments are welcome (see also http://platform.xwiki.org/xwiki/bin/view/Features/KeyboardShortcuts). JV.