- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [VOTE] Integrate Bootstrap framework inside platform

by Ecaterina Moraru (Valica)

Hi, In order to implement Flamingo skin ( http://jira.xwiki.org/browse/XWIKI-10093 ) we need to integrate the Bootstrap framework inside platform http://getbootstrap.com/ In this mail we should vote if you agree to integrate Bootstrap inside platform (or provide problems or alternatives). Here is my +1. Then I will ask you to help me find the best solution for this integration, read http://jira.xwiki.org/browse/XWIKI-10094 Thanks, Caty

11 years, 6 months

6
9
0 0

[xwiki-devs] Presentation about XWiki SAS and the xwiki.org open source project

by vincent＠massol.net

Hi everyone, FYI I gave a 10 minutes talk yesterday at Human Talk Paris (http://www.meetup.com/HumanTalks-Paris/events/168226002/) about XWiki SAS (http://xwiki.com) and the relationship with the xwiki open source project. I thought this could be interesting to some of you: http://www.slideshare.net/vmassol/xwiki-sas-an-open-source-company See also: http://www.xwiki.org/xwiki/bin/view/FAQ/What+is+the+relationship+between+XW… Thanks -Vincent

11 years, 6 months

1
0
0 0

[xwiki-devs] [Proposal] Add the notion of "Isolated wiki" in the Wiki descriptor and Wiki creation wizard

by vincent＠massol.net

Hi devs, Currently when we create a subwiki there are 3 choices for users: 1- Only global users are available in the wiki 2- Only local users are available in the wiki 3- Both global and local users are available in the wiki Based on the choice we enable different modes: - “workspace” mode for choice 1 - “farm” mode for choices 2 and 3 For example if you choose 2 or 3 you don’t get the HOME menu. I’d like to propose to add another option: “Should the wiki be isolated or not”. If the answer is “no” (the default), the behavior would be: - Display the “Home” menu - Display the breadcrumb on the subwiki home page to lead to the main wiki by default (if the user has defined a parent on the main subwiki home page) WDYT? Thanks -Vincent

11 years, 6 months

3
2
0 0

[xwiki-devs] [Brainstorming] Avoiding user errors when installing XWiki through the standalone distribution and changing the DB

by vincent＠massol.net

Hi devs, Some users are making the following mistake: - download the zip/exe and install our standalone distribution (jetty/hsqldb) - then they configure xwiki to point to another DB (mysql or postgresql typically) - then they start XWiki and they get an empty page and no DW The problem is that they don’t/can’t understand that in the standalone distribution the data/ directory already has a DW status.xml file that says the DW has already been executed and thus do not need to be executed again… We need to find some strategy to avoid this potential error. Any idea? Some ideas: - Idea 1: Improve documentation to explain the need to remove the data/ directory if you change DB - Idea 2: In the status.xml, store the DW status along with the DB id so that if the DB changes, the DW can kick in again. - other? I personally like idea 2. WDYT? Thanks -Vincent

11 years, 6 months

4
6
0 0

Re: [xwiki-devs] 6.x performances work

by Oana Tabaranu

Hello, As a member of the XWiki SAS client services team I have been working with the XWiki platform for more then 5 years now (the first jira ticket I opened was in 2008 for the 1.7 version of the platform:http://jira.xwiki.org/browse/XWIKI-2998 <http://jira.xwiki.org/browse/XWIKI-2998>) and I have seen a significant growth of the quality of its features (wysiwyg, rendering, skin, color themes, AWM, Distribution Wizard, etc), but also of the XWiki ecosystem (the community has build a really nice list of applications). However, this growth seems to have had also an impact on the performance of the platform. Here is some feedback regarding some of the things I and other members of the XWiki SAS client team have noticed, while working on projects based on XWiki: On 2/7/14 2:30 PM, Thomas Mortagne wrote: > Hi devs, > > Here is a mail to talk about what I plan to do during 6.x related to > performances. I don't have detailed plan for 6.0 yet, I still have > work to do on unfinished 5.x stuff and my priority will goes to that > but before working on it lets present what I already have in mind > about performances and gather some other ideas. I did not really made > much new reseachs yet, it's mostly things I have in mind since some > time for most of them. > > First thing first: having good performance is everyone's work, don't > expect me to review everything you do and do all the thinking about > how to design each feature so that it has good performances. My main > job is do things we always puh back because we don't have time so here > it is. > > = Automated speed report with history > > I plan to write a build dedicated to test performances (of XE for now) > and provide stored and compared reports about it. > > My plan is to combine the following tools: > * JMeter and more precisely some jmeter Maven plugin (probably > https://github.com/Ronnie76er/jmeter-maven-plugin/) > * Jenkins Performance Plugin > (https://wiki.jenkins-ci.org/display/JENKINS/Performance+Plugin) to > put a nice UI around that > > And probably run that build something like once a day on master branch > for example. > > The first step is to report it, second will probably be to set a > maximum timeout (that we ideally reduce over time ;)) to fail the > build when it become too slow (but that will be only after we actually > improved it). > > I hope to finish this in 6.0. It would be interesting to have a global view regarding the parallel requests since often small things add up: what is the impact of combining the velocity page generation, PDF export, UI resources, Solr indexing, activity stream, Office conversion, ... > = Spot worst places > > I plan to do hand testing with a profiler (probably YourKit) and write > detailed reports in jira issues for the slowest parts or our code > during a request (and not only for view, save is a realy a pain > sometimes) and what seems weird so that we find solutions (or not) for > each one. > > Same, I think I should have moved forward on it during 6.0 timeframe. How about http://jira.xwiki.org/browse/XWIKI-8910? > = Things we already know but for which I don't have yet a definitive solution > > == Too much database requests > > Loading a single document generate tons of requests. The document > cache hide this a little. > > Maybe start include some lazy loading of objects in document or things > like this but it's hard since we don't have any real clean interface > and only XWikiDocument to work on it. Since the documents are cached this point seems less important then the other items. > == The UI is very expensive > > Loading a page with /get/ action for example is a lot quicker (often > more than 5 times quicker) than loading it with the full UI (/view/ > action) even a page with lots of content including content we > generally consider very slow like code macro. We could use profiling tools like Yslow and PageSpeed to analyze the font end performance (improve the grades and especially the number of requests made to the server). This could have a great impact on the user experience. > = Some ideas of refactoring or new features I already have in mind > (not specifically done by me, it's just ideas of things to look at) > > == Async events > > I don't think there is much related issues in view but we are doing > way too much blocking stuff when modifying a document so I plan to > allow a listener to declare that it's ok for it to receive > asynchronous events (events sent in a different thread than the one > who actually saved the document) and review the listeners that could > use that (the first one I have in mind is user cleaner but I'm also > thinking about wiki extension module which execute several requests at > each save for example and all the code responsible for parsing and > storing backlinks in modified documents). We could also consider using more Ajax to load different parts of the UI. > == Activity stream UI > > This is nothing new and a project of it's own, the UI of Activity > Stream is super slow and probably require a complete analysis and > rewrite by a dedicated developer. The activity stream is very often removed from the homepage and the user profile because it slows down the wiki. > <put other ideas here ;)> > We can also consider JavaMelody since it offers some nice graphs and details for the spend and time (queries, active requests, CPU, memory, etc). We could offer the possibility of creating code pages without history because huge xwikircs table has an impact on performance (for example Scheduler / Watchlist activity shouldn't add a version to the page). The statistics module is too often deactivated due to performance issues or replaced by Piwik which does not offer good user level stats. Maybe we could also take a look at the performance of search for wikis with a lot of structured content. -- Oana Tabaranu Client Support Manager XWiki SAS

11 years, 6 months

2
1
0 0

[xwiki-devs] [VOTE] Stop using UI Extension Points and deprecate this concept

by vincent＠massol.net

Hi devs, I know this will come as a bomb. It came as a bomb for me too when I thought about it this morning :) Issue ===== So the question is: why do we need UIX when we already have a system to provide extensibility in XWiki called XClass and XObjects? Let’s take the example of the AddApplication extension point (http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/AddApplicationUIX) used in the Applications Panel. The UIExtensionClass xobjects for it don’t use the “content” field but they use the “parameters" textarea field, which defines 3 parameters: “label", “target", “icon". This is actually not very nice because the parameters are untyped and it’s up to the extension point user to parse the value (for example if the value is a list, it’ll need to tokenize the value to extract the different parts). A better way to implement this would be to have an ApplicationEntryClass with 3 typed fields: “label", “target" and "icon". And the “target" field could even be of type Page and when an XObject of that XClass is editer we would get auto suggest for it... This is the XWiki way... And with UIExtension we’ve suddenly introduced non-typed versions of XClasses... and this is IMO anti-xwiki! So, with an ApplicationEntryClass all the Application Panels needs to do, is use XWQL to find all xobjects (or introduce some script service to do that in the same as we have a script service for UIX). Some Q&A ======== Q: How to support scope with XClass as we have in UIExtension? A: - For “user" scope, this can be achieved by setting a Rights xobject on the page containing the XObject. - For “global” scope, this can be achieved by putting all global XObjects on the main wiki. Q: UIX could be implemented as components, we would loose that! A: Yes but look at it, UIX are for user interface and the best place to define the user interface is in wiki pages since that’s the place where the UI can be most easily modified by the user to fit his needs. If need be, we can have Java code that creates XObjects. Q: Right now it’s possible to use velocity for the parameters of property values in the “parameters” textarea of UIExtensionClass A: Several possibilities: Use a textarea field type, modify xwiki to add optional support for applying velocity on a String property, apply velocity at the place of usage through #evaluate. Way forward =========== * Deprecate the UIExtension notion, i.e. move the code to a legacy module (still bundle it in XE with other legacy modules) * Introduce specific XClass(s) to replace existing UIX (see http://platform.xwiki.org/xwiki/bin/view/ExtensionPoint/WebHome for the full list) * Revert Panel display code (leftpanels.vm, rightpanels.vm) to before the introduce of the UIExtension module. * In order to be backward-compatible, if the $services.uix script service exist, also look for UIX. For example in the Application Panel. Note: I believe this the main and probably only UIX really used at the moment. Here’s my +1 Thank you -Vincent

11 years, 6 months

4
4
0 0

[xwiki-devs] [Reminder] Improvement Closing Day #1

by vincent＠massol.net

Hi devs, I forgot to send some email to decide about what XWiki Day we’re going to do today. I propose to have an “Improvement Closing Day”. I hope this is fine with everyone. I also propose to try each type of day before deciding which ones we want to do more often. The goal is to close as many improvement JIRAs as possible and thus to take small and easy ones. Same goals as for BFD but for improvements. This is the filter for the day: http://jira.xwiki.org/issues/?filter=12890 When you close an improvement you should label it with “improvementfixingday” to be counted. Enjoy this XWiki Day! Thanks -Vincent

11 years, 6 months

1
1
0 0

[xwiki-devs] [Contrib] Request repository for integration between XWiki and Activiti

by Sorin Burjan

Hello, Last year I worked for my master thesis on a integration between XWiki and Activiti. Activiti is a popular open-source workflow execution engine. ( http://activiti.org/) I'd like to commit my work so others can use and improve it. For this, I'd like a repository called application-activiti for the source code, and also a JIRA project called Activiti Application with the key ACTIVITI. Thanks in advance, Sorin B.

11 years, 6 months

6
11
0 0

[xwiki-devs] Release the authenticator-jasig-cas project

by Petr Abrahamczik

Hi, I commited Jasig CAS authenticator project to the GitHub https://github.com/xwiki-contrib/authenticator-jasig-cas and I would like to release it in maven repository, so I need a Nexus account. Can anybody help me with it? Thanks Petr Abrahamczik

11 years, 6 months

3
6
0 0

Re: [xwiki-devs] devs Digest, Vol 81, Issue 4

by firmusoft.xwiki

Thanks! That Worked! On Tue, Mar 4, 2014 at 5:30 PM, <devs-request(a)xwiki.org> wrote: > Send devs mailing list submissions to > devs(a)xwiki.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xwiki.org/mailman/listinfo/devs > or, via email, send a message with subject or body 'help' to > devs-request(a)xwiki.org > > You can reach the person managing the list at > devs-owner(a)xwiki.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of devs digest..." > > > Today's Topics: > > 1. How can we add multiple values to a dbList property using > velocity (firmusoft.xwiki) > 2. Re: How can we add multiple values to a dbList property using > velocity (Sofiane Baloul) > 3. (no subject) (Sofiane Baloul) > 4. Requesting rights on xwiki-contrib (Sofiane Baloul) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 3 Mar 2014 20:04:44 +0530 > From: "firmusoft.xwiki" <firmusoft.xwiki(a)gmail.com> > To: devs(a)xwiki.org > Subject: [xwiki-devs] How can we add multiple values to a dbList > property using velocity > Message-ID: > < > CAFNvsku8cE60bhbDJd+1YB1WN26ObKm8QAO2013QHDxGUSWHcA(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > I have used $obj.set to update a dbList property value. But it selected > only the value I paased in the set method. All the previously selected > values were unselected. Can you help me to add/update the dbList property > retaining the previous selections. > > Thanks, > Firmusoft > > > ------------------------------ > > Message: 2 > Date: Mon, 3 Mar 2014 17:52:57 +0100 > From: Sofiane Baloul <sofiane.baloul(a)xwiki.com> > To: XWiki Developers <devs(a)xwiki.org> > Subject: Re: [xwiki-devs] How can we add multiple values to a dbList > property using velocity > Message-ID: > < > CAGgD37buBaAUMqXa3w3SV9hhBS1V+i+zj2gaBQFCSKfj9etxgw(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Firmusoft, > > First thing you should know is : if you want to save multiple values in the > DBList field, you have to check the property "Multiple Select" of the > DBList field in the XWikiClass (http://screencast.com/t/Jqpehv1K). > > If you want to save multiple values using velocity you should to set a > java.util.List object, example : > #set($values = ['one', 'two', 'three']) ## $values is an instance of > java.util.List > $obj.set('dblist', $values) > > to retrieve all values : > #set($value =$obj.getProperty('dblist').value) ## you get a list of all > values > but be careful : $obj.get('dblist') return a String containing all values > contcatenated with the separator (' ' space is the default separator) > > to add new values to a DBList field you shoud use (an update) : > #set($values =$obj.getProperty('dblist').value) > $values.add('four') ## you should check whether $values is null or not null > before. > $values.add('five') > $obj.set('dblist', $values) > > I hope this help :) and sorry for my bad English. > > Good luck. > > -- > Sofiane Baloul > XWiki Developer > > 2014-03-03 15:34 GMT+01:00 firmusoft.xwiki <firmusoft.xwiki(a)gmail.com>: > > > Hi, > > > > I have used $obj.set to update a dbList property value. But it selected > > only the value I paased in the set method. All the previously selected > > values were unselected. Can you help me to add/update the dbList property > > retaining the previous selections. > > > > Thanks, > > Firmusoft > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > ------------------------------ > > Message: 3 > Date: Tue, 4 Mar 2014 10:53:27 +0100 > From: Sofiane Baloul <sofiane.baloul(a)xwiki.com> > To: XWiki Developers <devs(a)xwiki.org> > Subject: [xwiki-devs] (no subject) > Message-ID: > <CAGgD37YKaBv2ZONXp-x7Tm9VEMwEr= > dr8VVqkFiZBP2vRXN8sg(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi dev community. > > I'm Sofiane Baloul, I have some experience in developing on XWiki > plateform, I would express my interest in contributing and bringing some > help on some XWiki projects especially on collaborative applications ( > https://github.com/xwiki-contrib ) at the begining. > > I've registered on jira.xwiki.org and I'm going to assigne to me some > tasks > related to XWiki Contributed Projects. > > Best regards. > > > ------------------------------ > > Message: 4 > Date: Tue, 4 Mar 2014 12:37:07 +0100 > From: Sofiane Baloul <sofiane.baloul(a)xwiki.com> > To: XWiki Developers <devs(a)xwiki.org> > Subject: [xwiki-devs] Requesting rights on xwiki-contrib > Message-ID: > < > CALCkubfpYCpX3gn4c+PaQLuV5Bayi99Ro7W7hQc4tPRocMcvcw(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Sorry, I've forgot to put an email subject and to give my github ID. > > My github ID : sbaloul. > > Thank you in advance. > > > On Tue, Mar 4, 2014 at 10:53 AM, Sofiane Baloul <sofiane.baloul(a)xwiki.com > >wrote: > > > Hi dev community. > > > > I'm Sofiane Baloul, I have some experience in developing on XWiki > > plateform, I would express my interest in contributing and bringing some > > help on some XWiki projects especially on collaborative applications ( > > https://github.com/xwiki-contrib ) at the begining. > > > > I've registered on jira.xwiki.org and I'm going to assigne to me some > > tasks > > related to XWiki Contributed Projects. > > > > Best regards. > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > > > ------------------------------ > > End of devs Digest, Vol 81, Issue 4 > *********************************** >

11 years, 6 months

1
0
0 0

[xwiki-devs] Requesting rights on xwiki-contrib

by Sofiane Baloul

Sorry, I've forgot to put an email subject and to give my github ID. My github ID : sbaloul. Thank you in advance. On Tue, Mar 4, 2014 at 10:53 AM, Sofiane Baloul <sofiane.baloul(a)xwiki.com>wrote: > Hi dev community. > > I'm Sofiane Baloul, I have some experience in developing on XWiki > plateform, I would express my interest in contributing and bringing some > help on some XWiki projects especially on collaborative applications ( > https://github.com/xwiki-contrib ) at the begining. > > I've registered on jira.xwiki.org and I'm going to assigne to me some > tasks > related to XWiki Contributed Projects. > > Best regards. > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >

11 years, 6 months

2
2
0 0

[xwiki-devs] (no subject)

by Sofiane Baloul

Hi dev community. I'm Sofiane Baloul, I have some experience in developing on XWiki plateform, I would express my interest in contributing and bringing some help on some XWiki projects especially on collaborative applications ( https://github.com/xwiki-contrib ) at the begining. I've registered on jira.xwiki.org and I'm going to assigne to me some tasks related to XWiki Contributed Projects. Best regards.

11 years, 6 months

1
0
0 0

[xwiki-devs] How can we add multiple values to a dbList property using velocity

by firmusoft.xwiki

Hi, I have used $obj.set to update a dbList property value. But it selected only the value I paased in the set method. All the previously selected values were unselected. Can you help me to add/update the dbList property retaining the previous selections. Thanks, Firmusoft

11 years, 6 months

2
1
0 0

[xwiki-devs] Maven-based naming best practices

by coldserenity

Hello, Does XWiki have conventions documented regarding * directory layout and naming * groupId name * artifactId name * project name (briefly scanned http://dev.xwiki.org and did not find anything) Regards, Roman -- View this message in context: http://xwiki.475771.n2.nabble.com/Maven-based-naming-best-practices-tp75892… Sent from the XWiki- Dev mailing list archive at Nabble.com.

11 years, 6 months

4
3
0 0

[xwiki-devs] Duplicate deps in build leading for failing build

by vincent＠massol.net

Hi guys, Several of you have been updating deps on master for the past days/weeks and this has lead to the enterprise build failing because we’re now packaging duplicate classes! See http://ci.xwiki.org/job/xwiki-enterprise/10740/consoleFull and search for "maven-duplicate-finder-plugin” Some dups: [WARNING] Found duplicate classes in [asm:asm:3.1,org.ow2.asm:asm:4.1] [WARNING] Found duplicate classes in [jdom:jdom:1.0,org.jdom:jdom:1.1.3] : [WARNING] Found duplicate classes in [org.bouncycastle:bcmail-jdk15:1.45,org.bouncycastle:bcmail-jdk15on:1.49] : [WARNING] Found duplicate classes in [org.bouncycastle:bcmail-jdk15:1.45,org.bouncycastle:bcpkix-jdk15on:1.49] : [WARNING] Found duplicate classes in [org.bouncycastle:bcpkix-jdk15on:1.49,org.bouncycastle:bcprov-jdk15:1.45] : [WARNING] Found duplicate classes in [org.bouncycastle:bcprov-jdk15:1.45,org.bouncycastle:bcprov-jdk15on:1.49] : [WARNING] Found duplicate classes in [org.codehaus.woodstox:stax2-api:3.1.1,org.codehaus.woodstox:wstx-asl:3.2.7] : [WARNING] Found duplicate classes in [org.codehaus.woodstox:woodstox-core-asl:4.1.4,org.codehaus.woodstox:wstx-asl:3.2.7] : [WARNING] Found duplicate classes in [org.restlet.jee:org.restlet:2.1.1,org.restlet.jse:org.restlet:2.0.14] : Thanks for helping fix this. -Vincent

11 years, 6 months

2
1
0 0

[xwiki-devs] [Reminder] BFD#56

by vincent＠massol.net

Hi devs, Today is Bug Fixing Day #56. We're currently at -27 bugs for the 1600 days period (we were at -23 two weeks ago): http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#56 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12093 Happy BFD! -Vincent

11 years, 6 months

1
1
0 0

[xwiki-devs] [Restrospective] Deprecation Fixing Day #2 issues...

by vincent＠massol.net

Guys, Last week we’ve had a deprecation-fixing day. I was worried about one thing and it seems it happened unfortunately. My worry was about breaking the build and introducing regressions. I’ve just started testing XE very quickly and I’ve noticed in the course of few minutes 2 regressions already :( * Regression 1: CSRF issue leading to a NPE when you execute XE. This wasn’t noticed for a full week! Correction was done today by GuillaumeD after I reported it (see https://github.com/xwiki/xwiki-platform/commit/bd007f28ee8c079d481c49455ceb…). Caused by https://github.com/xwiki/xwiki-platform/commit/77ebad8c6390dc4389d2de690ab5… * Regression 2: Incude macro doesn’t work anymore when using the “document” parameter. The problem is that we’re still using that.. For example in Panels.NewPage: {{include document="Panels.PanelSheet"/}}. I’ve just fixed it in https://github.com/xwiki/xwiki-platform/compare/09528b3e668a...4c2da3bf843b and https://github.com/xwiki/xwiki-enterprise/compare/96b63c62a637...7e8188d568… . Caused by https://github.com/xwiki/xwiki-platform/commit/ade4046 (caused by me!! yuck!). There are possibly more issues that we haven’t discovered yet. Thus IMO we have 2 problems here: * Fixing deprecation is something dangerous and if we don’t have automated tests for them we won’t notice regressions * We’re all not monitoring the build enough since this breakage has been lasting for 1 week. However this may be a consequence of the jenkins stability issue we’re currently experiencing. I’m not sure what we can to mitigate the risks but we need to think about something for the next time we’ll a Deprecation Fixing Day. Maybe we should only issue Pull Requests for that day and force that a committer doesn’t push the change himself and instead some other dev would need to review the code before pushing it? Any idea? Thanks -Vincent PS: Obviously the real solution is to have a stronger automated test suite but that doesn’t happen overnight and we currently don’t have a strategy for catching up with missing tests...

11 years, 6 months

3
3
0 0

[xwiki-devs] [ANN] XWiki 5.4.2 released

by Guillaume "Louis-Marie" Delhumeau

The XWiki development team is proud to announce the availability of XWiki 5.4.2. This is a bugfix release. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki542 Thanks -The XWiki dev team

11 years, 6 months

1
0
0 0

[xwiki-devs] [Vote] Deprecation of Prototype.js and the usage of JQuery as our default JS framework

by Ecaterina Moraru (Valica)

Hi devs, This has been brought into discussion several times so this thread is intended for this particular topic. Thanks, Caty

11 years, 6 months

8
17
0 0

[xwiki-devs] A problem of secret with jobs

by Jeremie BOUSQUET

Hello, I use the Job Module [1] for an extension, and discovered something that could be a concern ... Logs of job execution are stored in permanent directory, which is good. But when using the "{}" notation for writing logs as recommended, the following is output in the "status.xml" file: <org.xwiki.logging.event.LogEvent> <level>DEBUG</level> <message>blablabla</message> <argumentArray> [[ dump of arguments ]] <argumentArray> Inside <ArgumentArray>, all attributes of the object passed as argument to the logger method seem to be dumped - not just a toString(). Currently, in my case sometimes the object I pass contain a password ... I thought I prevented this password from being output in logs by taking care of printing "***" in the related toString, but in fact this way it gets in clear in the status.xml ... I see those possibilities: a- store this password encrypted and decrypt it only when used b- have a possibility to filter what is output in this <argumentArray> (blacklist some attributes) c- only pass individual attributes as parameter and not my full object Obviously a- is the best solution in terms of security. Would xwiki bring me some helpful methods to implement it (server side) ? c- is the short term efficient workaround of course, but I would still be interested to know if there are some crypto tools provided by xwiki (well, most problematic would be to know where/how to store the secret needed for encryption/decryption in an extension, if I want to do more than some scrambling). WDYT ? Thanks, Jeremie [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Job+Module

11 years, 6 months

3
6
0 0

[xwiki-devs] [Vote][Skin] Keep Colibri look or have another look for 6.x

by Ecaterina Moraru (Valica)

Hi, As part of the 6.0 Roadmap we have as entry the creation/integration of a new Skin inside XWiki. Currently there are 2 proposals for the new skin: Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin = Similarities = * Both skins have been done using the Twitter's Bootstrap framework ( http://getbootstrap.com) * Both skin are thus responsive = Differences = * Flamingo is just a proposal, while Junco is an extension. The difference is that while for Flamingo I have just a prototype, Junco is functional and installable (with some integration problems/dependencies discussed in another thread). The difference matter just from a development time perspective (if we choose Flamingo it will take longer to implement). * Flamingo provides a new look while Junco offers 'Themes', one of themes being very similar to Colibri, see http://extensions.xwiki.org/xwiki/bin/view/Extension/Junco+Skin#HTheme:Coli… This vote mail is about this difference. What to consider: A. Freshness Advantages of Flamingo is that its interface is centered around Applications (it has a new left panel used for navigation). It will provide a visual difference from Colibri and looks more similar to current applications found in the wild. Advantages of Junco is that it provides Themes. Junco's Themes are very similar to our current ColorThemes, the difference is that they can change also the font used, the colors and can also add some esthetic effects (gradients, borders, shadows, etc. - CSS effects) to Bootstrap's components (buttons, navbars, alerts, tables, etc.). But except minor changes, the layout is similar to Colibri. Improvement consist in using refreshed style for font, forms, buttons, messages, etc. B. Extensions Integration One of the reasons I choose to make Junco similar to Colibri was extensions integration. The advantage of XWiki is that you can extend it how you like. The problem is that because the extensions are developed by our community (and not by a single entity) each application is providing it's own style. On extensions.xwiki.org we have applications that provide an unique style, while others are build around and for Colibri. Adding a new skin with a different style (like Flamingo) will make current extensions not look unitary. This problem is more general than just this Colibri/Junco/Flamingo discussion and it the problem of having extensions that adapt to the skin used (without creating special versions for each skin). Junco was created to look similar to Colibri (preserving layout, style, colors) while updating the 'back-end' (created on Bootstrap, it will put at developer's disposal the Bootstrap's guide style and components). One of the reasons we are having this extensions 'incompatibility' is because we are lacking visual standards and guides (maybe using the ones provided by Bootstrap can improve this area - I will send a separate mail about the CSS Framework selection). So from the style standards perspective having Junco integrated first could represent a transition step between our current Colibri and a new skin with a different look, because the developers might use Bootstrap style/structure guides in their extension development (not guaranteed). C. Parallel skin support Another advantage of Junco is that (by having the same layout) is using the same templates as Colibri. Having just a set of templates to maintain is very important from a development perspective especially if your development resources are limited. This is one of the reasons XWiki is not supporting multiple default skins. Flamingo will need some templates changed, so important from a development time and maintenance perspective. So this vote is about: 1. Keep Colibri's current look which is supported by the Junco skin, or 2. Have another look for 6.x which is proposed in the Flamingo skin Thanks, Caty

11 years, 6 months

4
8
0 0

[xwiki-devs] [Contrib] Requesting a project for CAS authentication

by Petr Abrahamczik

Hello, I would like to request for a project that adds Jasig CAS (http://www.jasig.org/cas) authentication support to the XWiki. We started using XWiki in our organization and we are using a CAS authentication. So I developed CAS authentication module to the XWiki and I would like to share it on XWiki Contrib. I would like to request for GitHub access. My GitHub user name is pabro. Name: XWiki Authenticator CAS Description: XWiki authenticator based on Jasig CAS. It supports CAS 2.0 and SAML 1.1 protocol. SAML protocol can be used for attributes and group membership synchronization. Petr Abrahamczik

11 years, 6 months

2
1
0 0

[xwiki-devs] [Discussion][Skin] Less vs. Sass vs. Velocity

by Ecaterina Moraru (Valica)

Hi, As part of the 6.0 Roadmap we have as entry the creation/integration of a new Skin inside XWiki. Currently there are 2 proposals for the new skin: Flamingo http://design.xwiki.org/xwiki/bin/view/Improvements/Skin4x Junco http://design.xwiki.org/xwiki/bin/view/Proposal/JuncoSkin Both proposals are done using Twitter's Bootstrap framework ( http://getbootstrap.com). Bootstrap officially is written using Less ( http://www.lesscss.org/ ) and is the default pre-processor they support. There is also a Sass ( http://sass-lang.com/ ) version for Bootstrap ( https://github.com/twbs/bootstrap-sass ) so the idea is that the preprocessor variant is not limiting us in integrating Bootstrap. The question we discuss in this thread is what preprocessor we should integrate in platform when we integrate Bootstrap (that in the case we integrate either of these tools). Currently Junco's extension is done with Bootstrap + Less. My decision to use this combination was done after a light research and mostly based on a personal preference of the Less language. We are having this preprocessors discussion so late (they appeared in 2007-2009) because we didn't really need a preprocessor until now. The base functionality they add we solved by using Velocity (we have CSS3 prefix macros defined in macro.vm that are similar to the compatibility mixins provided by Bootstrap, we have also a ColorThemes variables solution for reusing color values and because we can have Velocity code inside our stylesheets we cover most of the functions&operations need). The only downside for us using Velocity to do these kind of things is that the functionality we cover is very basic and was done only if we had a certain need. This is not necessarily a bad thing but it's kind of a limitation for external developers that might want to make more complex things. Less and Sass community members are very active and they make sure their functionality is tested and covers most of the cases. Also there are some features (like extends, etc.) that would be hard for us to duplicate in Velocity. Just as a note, adding Less doesn't mean we are replacing Velocity. We are just replacing the CSS things done in Velocity with Less functionality. Replacing Velocity with another templating engine should be the topic for another thread (in case we are considering this). If we integrate Less, what is currently done with CSS+Velocity will be done using Less(CSS)+Velocity(less code). If we integrate Sass (because Sass also has control directives) we transform CSS+Velocity in Sass(CSS)+Velocity(even less code) but the API calls will still need to be added with Velocity (so still we will not have just Sass). One of the problems with the preprocessors is that they depend on Javascript or Ruby (there are some versions also on Java in case of Sass, but not officially maintained). So first we need to find a solution to compile Less/Scss files into CSS, inside our platform. If you make a Google search you'll see that there are much more 'recommendations' to pick Sass over Less. One remark regarding this is that we need to understand that right now Sass is used on a different technologies stack (mostly for Ruby applications). Sass is very attractive because of its power. But what we need to ask ourselves is if we need the full power of Sass (because some of it is already covered by Velocity). Personally I prefer Less, but that's because of the separation of concerns (structure, presentation, behavior). I prefer the limitations Less has (regarding control structure) in order to not be tempted to write logic with a language that is not supposed to do that (even though it can). Preprocessors should be used exclusively to write CSS and especially to write it more rapid (nesting, mixins). Also Less syntax is more close to default CSS syntax, which IMO is a big plus. But because of its power, Sass could be in the future the new 'JQuery', since right now it has a bigger community. One of the advantages of picking a technology later is that at least you see some clear candidates (and we don't need to consider other preprocessors like Stylus, etc.). Let me know what you think. Thanks, Caty

11 years, 6 months

3
5
0 0

[xwiki-devs] [XWiki Day] Deprecation Fixing Day #2

by vincent＠massol.net

Hi devs, Today is an exciting day, we’re starting something new for the 6.x cycle. Note that we had a first deprecation fixing day in the past: http://www.xwiki.org/xwiki/bin/view/Blog/DeprecationFixingDay1 Also note that we were at 1681 deprecation calls after that first DFD and as of now we are at the following numbers (see http://t.co/lKsIKcqqlX): * platform: 2015 * commons: 39 * rendering: 3 TOTAL: 2057 So this means that since April 2012 we’ve increased deprecated calls by 376. That’s what we need to fight! :) The rules are: * Goal #1: reduce to the maximum the number of deprecated calls. * Goal #2: move the maximum of deprecated apis into legacy modules. * When you fix deprecation or move some API to legacy, edit this blog post to add your score: http://www.xwiki.org/xwiki/bin/view/Blog/Deprecation+Fixing+Day+2 Have a good XWiki Day! :) Thanks -Vincent

11 years, 6 months

3
16
0 0

[xwiki-devs] App dev best practice - Update

by vincent＠massol.net

Hi guys FYI I’ve added a rule to http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… “ Put an XClass definition in a document by itself and refrain from having both the XClass and an XObject using it in the page. It's makes for better separation of concern but also helps for upgrades and solves some dark magic issue (a.k.a bug emoticon_smile) with XWiki import which could import the XObject before the XClass and cause some havoc… “ Let me know if you don’t agree. Also feel free to edit to improve the reasoning ;) Thanks -Vincent

11 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs