xwiki-devs January 2013

xwiki-devs@xwiki.org

27 participants
82 discussions

[xwiki-devs] [Contrib] Meeting and File Manager applications

by Thomas Delafosse

Hi devs, I'm currently working on two new applications : Meeting and File Manager. I've already published a first version of them on extensions.xwiki.org ( http://extensions.xwiki.org/xwiki/bin/view/Extension/Meeting+Applicationand http://extensions.xwiki.org/xwiki/bin/view/Extension/File+Manager+Applicati…), and now I would need a folder on github (my github user name is tdelafosse) and a maven groupID for each of them so I can release them with maven. Thanks, Thomas

11 years, 6 months

[xwiki-devs] JIRA cleanup for missing fixversion

by Vincent Massol

Hi guys, Can you help me fix all those issues that are missing fixfor? http://jira.xwiki.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=status… Thanks -Vincent

11 years, 6 months

[xwiki-devs] [VOTE] Skip tests while building a release

by Eduard Moraru

Hi devs, Well, the subject pretty much sums it up. I am proposing to skip any testing while building a release, since that is the job of the CI infrastructure and, it happened more than once for the build of the release to fail because of a flickering test. This is really annoying for a release manager that has to start over the entire build (since right now it's a real pain to alter the scripts to continue the build). Besides this, tests (specially the functional ones added into platform) uselessly delay the build, thus, the release. Note: We are already skipping tests for enterprise and manager. This vote is actually about skipping tests for commons, rendering and platform as well. Here's my +1. Thanks, Eduard

11 years, 7 months

[xwiki-devs] Provide translations in JAR extensions

by Thomas Mortagne

Hi devs, The last piece missing to the new localization framework for 4.x is to allow providing translations in a jar extension. Here are some ideas: 1) Continue with ApplicationResources_*.properties files but loads it from everywhere instead of taking the first one we find like now 2) Same that 1) but place it somewhere a bit "cleaner" like org/xwiki/localization/translation_*.properties 3) Completely different system. I looked a bit if any simple de facto standard was already existing but was not obvious. Keep in mind the localization framework allow providing any source so it's easy to move/add a new way to get translations in jar extensions later without touching the API so while it would be better to do something good it's mostly implementation details and whatever we choose we are not going to be stuck with it forever. WDYT ? I would go for 2) (I'm +0 for 1)) with org/xwiki/localization/translation_*.properties for 4.x and keep 3) for later when we have some time to work on it a bit more. -- Thomas Mortagne

11 years, 7 months

[xwiki-devs] Fwd: [xwiki-infra] vxwikiorgfarm: wiki is not responding!(real URL)

by Caleb James DeLisle

20 threads blocked on: at com.xpn.xwiki.render.DefaultVelocityManager.getVelocityEngine(DefaultVelocityManager.java:177) - waiting to lock <0x637cbe38> (a com.xpn.xwiki.render.DefaultVelocityManager) at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:105) https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi… The holder of this lock calls context.getWiki().getSkinFile("macros.vm", skin, context); and context.getWiki().exists(skin, context), both of which potentially access the database while holding a global lock. Looks like some delicious low hanging fruit to me. Thanks, Caleb Original message removed because it is too big for the list. See it here: https://ezcrypt.it/4H5n#8mjU1voDtZsANw9vsLa8WM8Y

11 years, 7 months

[xwiki-devs] [Contrib] xwiki-application-mailarchive

by Jeremie BOUSQUET

Dear community, I would like to request for a new contrib project to store the Mail Archive application I'm currently writing. Name: xwiki-application-mailarchive Description: A mailing-list archive application. - For now a GitHub project to store sources should be fine. My username on GitHub is "jbousque". - For Jira it might be useful to have a project once the application is released "officially", that is still not the case. Meanwhile the generic project is ok for me. - There is a specific page in Design space on xwiki.org : http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication , but for now no extension has been added. I would like if possible to test my extension (automatic install with dependencies) before publishing it The Design page also gives some info about the current state and progress, and some screenshots. There is many remaining work, but it begins to look like something usable. The bad side is the lack of unit tests most of all ... A question : the groupId "org.xwiki.contrib" is to be used, do I have to use this exact groupId or can there be sublevels if needed ? If so I would use org.xwiki.contrib.mailarchive as groupId. Thanks, Jeremie

11 years, 7 months

[xwiki-devs] [PROPOSAL] Include require.js in XWiki by default and make jQuery available through require.js.

by Caleb James DeLisle

Hi, I'd like to add require.js to XWiki to be included in every page just before prototype.js. I would also like to add jQuery to our resources directory but only make it available to scripts which "pull it in" using require(). I have come to the conclusion that jQuery is a de-facto standard and even if we don't port to it, we should make it available to our users. Require.js is an implementation of the Asynchronous Module Definition standard which will allow us to use both jQuery and prototype relatively harmoniously. I think it's obvious that if javascript rich webapps are going to scale, they need modularity and I've reviewed AMD and the main competitor CommonJS and concluded that AMD will provide the user with better page load time by asynchronously loading modules according to a dependency tree while CommonJS blocks on each call to require(). I would like to see us move away from prototype but it provides more functionality than jQuery including an OOP framework and while there are other libraries which show promise, I don't feel right proposing a best practice without first porting some code to it to see what issues arise so IMO we should begin using require.js but accept that prototype still has it's place. So I propose: Include require in the header vm. Include jQuery but only if a script "require()'s" it. Establish a best practice of using require() and define() instead of global variables but accept that prototype.js still has it's place. WDYT? Caleb miscellany: ------------------------------ require.js vital statistics: Dual licensed BSD and MIT. Latest Release: 2.1.2 1,993 lines before minification 24,621 lines in every .js file in the /tests/ directory. Used by: https://github.com/adobe/brackets/ https://github.com/ajaxorg/cloud9 (https://c9.io/) http://browserquest.mozilla.org/ http://www.bbc.co.uk/frameworks/barlesque/examples/global/requirejs http://www.officejs.org/ ----------------------------- Optimization: require.js comes with a tool for linting, compiling (using Closure Compiler), and linking AMD modules together based on their dependencies. Complex projects with many js files can be can be compiled into a single "statically linked" js file. It supports Rhino so it could be included in the maven build. ----------------------------- My experimentation with require.js: I use the require.js legacy shim to make jquery.sheet function as a require.js module without making any direct changes to jquery.sheet. I was able to move the code from XWiki to the filesystem (file:///) a total change of the directory structure and only needed to change the main example.html file. I was able to include the content in an iframe simply by defining a require.js plugin see: http://requirejs.org/docs/plugins.html for loading through an iframe and changing the require() call to require the iframe'd sheet. https://github.com/cjdelisle/jquery-sheet-amd

11 years, 7 months

[xwiki-devs] [Brainstorming] Sources of HTML and ability to use pre-made CSS like Bootstrap

by Denis Gervalle

Hi Devs, As you may have noted from a previous mail, I have given a try to skin XWiki differently, based on Bootstrap. There is certainly many ways to get it done, but IMO, building over any pre-made css solution requires an adaptation of the HTML generated. In the early days of XWiki, the were few places were we have HTML generated. Most of the html produce came from three major places: 1) .vm templates including macros.vm 2) java generated (#display()) 3) XWiki tech document While 2) and 3) either provide very basic markup or customizable one and are not so much, and 1) was fully customizable by skins, to work out a new skin was not too complex. Today however, the UI of XWiki has considerably increase its complexity, and the source of HTML has followed, added to the above 3: 4) XWiki and Java macros 5) JavaScript (ie: annotation UI, comments preview) Changing all these places has become really more painful. There is no central place, and a lot of hidden dependencies between UI components exists. Worse examples are those written in JS, that hook into the UI. I should admit that I have not a clear idea of the best way to improve that, but my feeling is that changing so much places simply to adapt our wiki skin to the "a la mode" skin solution (something that will happen again) is not nice. So this thread is now open for anyone to discuss the situation and for anyone interested to provide its input to the discussion. Looking at what I face building the UI with bootstrap, here is what I noticed: 1) Bootstrap customize standard tags, without any css class associated 2) Bootstrap provide standard css classes to skin a given kind of UI component 3) Bootstrap use these class and custom attribute to inject JS interactivity All these are really clean methods and work really well at building very simple html construct while providing nice looking and easy interface. Let's take a concrete example, to build a button, you may use either an a tag, an input tag, a button tag or whatever, and set it a 'btn' css class. You may complement it with additional 'btn-primary', 'btn-success', ... css classes, to choose the kind of button you really want. However, in our XWiki UI, there no single place where we construct buttons, we do so in some velocity macros of macros.vm, we do so in .vm of the UI, we also do so in javascript, and finally in some wiki documents, maybe we also generate some in a java component. All those buttons are usually built the same, with a very similar HTML, but there is no central place where the button markup is produced. And the same is true for most UI component. You may say we don't care, and CSS could solve them all, making any kind of markup look the way we want. But, we will loose the benefit of using existing CSS solution. And there are interesting benefit to that, since those solution gets customized, see BootsWatch for example. Therefore, it seems to me that we need something like an UI generator, so that when you build a application, you would simply says, I want a primary button here, a secondary button there, and it gets created both the way it should for your apps to use it, but also for the UI design we want to use. Defining a list of these UI component is not simple, but we may take Bootstrap as a starting point. There is in Bootstrap a large number of control already, that should cover many UI possibilities. How to provide that UI component to all the places we need it may be less obvious. For example, we need to create button from .vm, XWiki document, XWiki and java Macros, and even from javascript. Also defining how you could expect to interact with each control, from Javascript or from java on the server needs clarification. I have not yet googled, but there may be existing experience regarding these matters on other project. Not reinventing the wheel is always better. Your ideas are welcome. IMO, we really need that if we want our Skin 4.x to be really more usable for customization. WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

11 years, 7 months

[xwiki-devs] DW creates too many revisions?

by Vincent Massol

Hi devs, I've installed the UI of a wiki through DW and I've noticed that the Sandbox.WebHome page had 2 revisions instead of the 1 revision I was expecting. The first revision has a comment that says "Import: add attachment" and the second rev has a comment of "Import: final save". However, if I skip the DW and import the XAR, I'll get only 1 revision AFAIK. Is this discrepancy normal? Do we want it? Thanks -Vincent

11 years, 7 months

[xwiki-devs] [PROPOSAL] How to translate logs

by Thomas Mortagne

Hi devs, A missing peace of Extension Manager UI is the fact that the log associated to a task is not translatable right now. So I'm working on making easy to translation log in general since that's actually what EM is displaying: just plain standard slf4j log (see http://jira.xwiki.org/browse/XCOMMONS-304). = Possibilities = Here are several possibilities: 1) translate the message before giving it to the log event, so it's up to the log producer to translation its log based on the context language 2) provide an additional translation key along with what will now be the default message when logging 3) generate a translation key based on the default message Here is what I think of those: 1) is a bit better for the user than the current situation but not that much, instead of behind stuck with english he will be stuck with another language with stored logs. It also make anyone that produce log depends on many things to actually translate that message so it's a -1 for me 3) sounds very fragile = The actual proposal = Here is a detailed proposal for 2): The idea would be to pass the translation key using slf4j Marker API. We introduce a TranslationMarker which implements Marker and is passed with the log when you want to associated a translation key to a log. Here is an example: producer (for example the install job): "" logger.error(TranslationMarker.getMarker("some.translation.key"), "A default error message generally in english with a [{}]", "parameter", exception) "" displayer (for example the Extension Manager UI, should be a logging module UI element btw reused by Extension Manager ;)): "" #set($translationKey = $logEvent.marker.translationKey) "" WDYT ? -- Thomas Mortagne

11 years, 7 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 January 2013