June 2013 - xwiki-devs@xwiki.org

[xwiki-devs] Adding a customer plugin to the wysiwyg editor
by rhierlmeier 06 Dec '13

06 Dec '13

Hi, we studied the source code of the gwt wysiwyg editor but we found no official way to integrate an custom plugin. We have the impression that it should be relatively easy to establish a public API for registering customer plugins. The customer plugin would be delivered as javascript code with a global javascript function that implements PluginFactory interface. The WysiwygEditorConfigClass would have an addition property customerPlugins, containing a comma seperate list of strings of the PluginFactory method names. Do you think that this is doable? Regards Richard -- View this message in context: http://xwiki.475771.n2.nabble.com/Adding-a-customer-plugin-to-the-wysiwyg-e… Sent from the XWiki- Dev mailing list archive at Nabble.com.

4 14

[xwiki-devs] [Vote] Creation of a design wiki and it's purpose
by Ecaterina Moraru (Valica) 18 Nov '13

18 Nov '13

Hi, *Short version* for voting: *A*. Creation of a new wiki on xwiki.org farm that will hold development process details about a specific feature. This wiki will deprecate dev.xwiki.org:Design and incubator.myxwiki.org *B*. Vote on naming alternatives for this new wiki: design.xwiki.org incubator.xwiki.org *C*. UI on how a Proposal will be displayed in this new wiki (example AppWithinMinutes): http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgDesignWiki ------------------------------------------------ *Long version: * Right now development process activities are located in multiple places: - Analysis + Architecture: http://dev.xwiki.org/xwiki/bin/view/Design/ - Analysis + User Interface: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ - Other: http://xwiki.markmail.org/, http://jira.xwiki.org, chats, git comments, etc. This process can be hard to optimize and information is hard to track if you are looking for specific information. And the worst part of it is that is hard to automatize and lots of the items need manual gathering or search. *Part A. * This mail is about combining http://dev.xwiki.org/xwiki/bin/view/Design/and http://incubator.myxwiki.org/ work in a single place. This has already been discussed several times before ( http://xwiki.markmail.org/thread/kc32dufsf7nyyt6s and http://xwiki.markmail.org/thread/izj6aiyodwqia4vl) and the vote was favorable in this direction. The proposal was to create a new wiki called design.xwiki.org that will contain the combined information and that will target developers. The new wiki will be used to gather only proposal's development process information: requirements, architecture, solutions alternatives, user interface variants, planning, etc. for a specific feature/idea/improvement. After the proposal is implemented it will be properly documented in the right location for users (ex platform.xwiki.org) It is acceptable to have CSS + JS code on this wiki in order to demonstrate the functionality of the proposals, but we should not add experimental/dangerous code (groovy scripts, jars, etc.). For this case it is advisable to use a test machine, share your own instance or use the contrib.xwiki.org repository for hosting. The version upgrades will be handle by a community admin and the wiki gardening by me. The data from incubator.myxwiki.org and dev.xwiki.org:Design will be moved gradually after the new wiki is created. *Part B. * You should state your opinion regarding which name is better for the new wiki: - design.xwiki.org - incubator.xwiki.org - we accept other proposals. *Part C.* I've made a proposal on how a proposal page would look like: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgDesignWiki The proposal page will gather all the information related to it, making it easier to track it's progress. The entries will be separated depending on 4 categories: Analysis, Architecture, User Interface and Implementation, each category having it's own status, participants, jiras and timeframe. Categories are not mandatory for all proposals, smaller proposals will have just the related pages for certain areas. Each proposal will store it's data in a dedicated space. The implementation of the proposal will be handled by me. Let me know what you think. Thanks, Caty

9 23

[xwiki-devs] [Discussion] Should technical pages hide the bottom tabs?
by Sergiu Dumitriu 24 Oct '13

24 Oct '13

Hi devs, For content pages, the bottom tabs (comments, attachments, history, information) are very useful features. But does it make sense to keep those active for very technical pages? For example, when viewing details about a tag, (Main/Tags?do=viewTag), why should people be allowed to comment? They might wrongly think that they're commenting on a tag, but that's just one complex page that handles almost everything about tags, so a comment like "this tag has a typo" doesn't help at all. Other pages should have no bottom tabs as well: user directory, blog category management, the whole scheduler space, share by email... While the homepage is a technical page (by default), it does make sense to leave the comments active, since it's the entry point for every user (although I think that the messaging system is a better way to send global messages). IMO, the advantage is that we're hiding actions that are rarely useful, but could be misused. The disadvantage is that we're breaking the universality of the UI. I'm +1 for hiding, fewer mis-usable features is always better. -- Sergiu Dumitriu http://purl.org/net/sergiu/

7 11

[xwiki-devs] Unable to add user to group after Xwiki update
by echocoder 15 Oct '13

15 Oct '13

I am currently running Tomcat 7.0.39 as well the Xwiki 5.0.3 WAR. I imported the Xwiki database into MySQL from an older version of Xwiki which could be the cause of the problems below... When I enter "Administer Xwiki" and choose "Groups" I am sent to the following which lists the groups as expected. /xwiki/bin/admin/XWiki/XWikiPreferences?editor=globaladmin&section=Groups#|t=groupstable&p=1&l=10&wiki=local When I click on the "pencil icon" to add a user to a group the same page URL is refreshed and shows a lot of white space followed by a list of users in that group at the bottom of the page. There is no option to add the user to a group. So somewhere along the line I believe something became corrupt during my Xwiki update. I tried copying some VMs from the templates subdir back to my main webapp directory but that didn't work. Any suggestions on where to look? Screenshot attached. <http://xwiki.475771.n2.nabble.com/file/n7585667/part2.png> -- View this message in context: http://xwiki.475771.n2.nabble.com/Unable-to-add-user-to-group-after-Xwiki-u… Sent from the XWiki- Dev mailing list archive at Nabble.com.

3 6

[xwiki-devs] [VOTE] New rule: Put ScriptService implementations out of the internal package
by Vincent Massol 09 Oct '13

09 Oct '13

Hi devs, We need to solve http://jira.xwiki.org/browse/XWIKI-9157 I'm proposing to simply move all ScriptService implementations out of the internal package and make that a rule. These classes are used by introspection and as such as not used as components and thus they should not be in the internal package. Here's my +1 and I'm proposing to handle the move. I can't think of anything that would break except some users who would have had an import in a groovy script on some internal Script Service but that's ok IMO. Thanks -Vincent

5 12

[xwiki-devs] [Proposal] New xwiki-platform-wiki/xwiki-platform-wiki-descriptor module
by Vincent Massol 01 Oct '13

01 Oct '13

Hi devs, As you may have seen I've started working again on xwiki-platform-url module (http://jira.xwiki.org/browse/XWIKI-3951) and I now need to add wiki alias support for it. Right now wiki alias support is in oldcore and the url module must not depend on oldcore so I need to extract wiki alias support to a new module. I'm proposing to create a xwiki-platform-wiki module which should contain in the future all modules related to multi wiki handling for stuff not in the model (stuff in the model will go in xwiki-platform-model). Right now I'm proposing to have: xwiki-platform-wiki |_ xwiki-platform-wiki-descriptor where xwiki-platform-wiki-descriptor will implement description of wikis as xobjects in wiki pages (XWikiServerClass), i.e. what is currently in oldcore's XWiki#findServer. In the future the idea will be to rewrite xwiki-platform-wiki-manager and to move it to xwiki-platform-wiki/xwiki-platform-wiki-manager for example (or with another name). WDYT? Barring negative feedback I'll try to start working on this in the coming week. Thanks -Vincent

4 4

[xwiki-devs] [Proposal] Finding how many active instances of XWiki there are out there
by Vincent Massol 03 Sep '13

03 Sep '13

Hi devs, I think it would be great to have some indication of how many active instances of XWiki are out there in the wild. The idea is not so much to know the figure but to see how this figures evolves and thus to see if we're doing things right. It will also give us information about how quickly or slowly our user base upgrades from version to version. Here's my proposal: * When installing XWiki on a clean DB (ie first time install) generate a unique id and store it in the DB (similar to the version we're storing in the DB but using some UUID). Thus when an install is upgraded the same id is preserved. * When the Extension Manager is used and thus connects to extensions.xwiki.org (default extension repository), this unique ID is sent too. * In addition the version of XE is sent too * On extensions.xwiki.org side, we only log the unique ID/XE version **without** logging the IP or any other information thus ensuring that the ID remains completely anonymous * We display a counter on xwiki.org about the # of active instances of XE with a graph about XE versions used WDYT? Thanks -Vincent

5 8

[xwiki-devs] [Proposal] Add CLA for contributions + Foundation
by Vincent Massol 27 Aug '13

27 Aug '13

Hi devs, I'd like to propose the following: * That we start asking for a CLA for contributions (and also for current committers) * That we keep the process lightweight in order to not make it harder to contribute to the xwiki project. For this I propose to use http://www.clahub.com/ In order to understand why we need a CLA read: * http://www.oss-watch.ac.uk/resources/cla * http://en.wikipedia.org/wiki/Contributor_License_Agreement If we agree we then need to define our CLA. I think a good starting point could be the Node.js one: http://nodejs.org/cla.html Now I don't think the CLA will have any legal value if we cannot define "the XWiki project" as a legal entity. Thus I believe we need to start by joining some foundation or creating one. I'll list some easy possibilities: * SF Conservancy: http://sfconservancy.org/members/current/ * SPI: http://www.spi-inc.org/projects/ * Create our own Not for profit association Harder possibilities (need to change license, rename project, etc): * Join ASF * Join Eclipse (and be forced to use bugzilla as the issue tracker ;)) We also need to check if OW2 could offer that service of being a legal entity for XWiki. Personally I'm tempted more by our own association (it's quite easy to create one if we don't need to accept money and a bit more complex if we want to accept money but still doable). My second choice goes to SFC. WDYT? Thanks -Vincent

5 8

[xwiki-devs] Improving the XWiki Development environment for traditional Java/JS Developers
by Ludovic Dubost 24 Aug '13

24 Aug '13

While XWiki has many great advantages as a framework which takes car of persistence, forms, user management, content management and provides tons of APIs, when traditional developers want to extend XWiki there are facing a few difficulties: - they are lost in the myriad of XWiki APIs, and there is no completion - they don't get good visibility of the code available in their application - it is complicated to use editors which have syntax highlighting - they cannot use their favorite IDE On the framework side there are also some improvements which could make XWiki even more killer: - easier integration of advanced JS framework - advanced integration of a high level JS framework that has templating (maybe angular js) - better validation functions - easier way to add REST APIs - more XWiki and better documented javascript apis Here are some proposals to help fix the tools issues. Three approaches can be looked at: 1/ Live Sync between an XWiki Instance and and improved maven xar file structure, allowing to use any local IDE on XWiki code First it should be possible to use any IDE on the maven xar file structure, allowing to open the content and textarea fields of all XML files. For this XWiki XML files should externalize the content and textarea fields in separate files with extensions based on their content type. The maven xar format should be able to clean the maven structure to do this splitting and should also be able to build the XAR from all the files. Finally a program should allow to do a live sync between a local or remote wiki instance and the maven project. Any change in either the wiki or the file system should be replicated to the other party. So if you run "git pull" then your local or remote wiki would be updated. If a change is made in the wiki, the change would show up in the file system and your IDE would refresh it. The sync program would keep a state of the version in the wiki, in order to be able to merge changes if changes occur in both places between two sync. This tool could be easily launched with "mvn xar:sync" Syntax highlighting for XWiki Syntax+Velocity+Groovy would be developped for the most popular editors. When syncing the tool could show syntax checking error messages. 2/ Integration with Eclipse Based on XEclipse, we would build an Eclipse plugin to be able to connect to an XWiki instance and load a specified list of spaces. Then each space would be organized by the type of code in this space. Content and Textarea fields would be made visible as editable content in Eclipse. The plugin should detect the type of code in each of the content or textarea fields (velocity/html, groovy, javascript, css, translations, xwiki syntax) and use the appropriate editor. Finally a completion module could be provided by loading from the server a list of available APIs. The same plugin could also be able to organize the content from a local maven project (based on 1/) and provide completion to such a project. Live syntax checking could be provided. 3/ Integration of a WebIDE in XWiki Based on Javascript WebIDE and web code editor softwares (Orion, Cloud9, exoIDE, codemirror, etc..), we would provide a view on the code inside the XWiki instance. Code would be organized in the same way as in the Eclipse plugin and appropriate editors would be used depending on the code type. Completion could be provided in the velocity and groovy editors and eventually in Javascript Two views should be available, one for each AWM application, and one with all the code in the Wiki. Live syntax checking could be provided. Solution 1/ is very powerful because it let's the user decide which is his development environment, even if the tree structure won't be perfect. Still he can see all the code in the wiki and work on it, including searching. Committing is made very easy. There are some risks involved in the sync process, particularly of you have multiple developers syncing local code with the same dev server. User can switch from local sync (local wiki) to remove sync (remove shared wiki) and can therefore work offline more easily. Editing can be fully done offline. Providing syntax highlighting for many editors might prove difficult. Solution 2/ is providing a nice XWiki environment inside Eclipse, without the need for a local copy of the code. Committing would happen using the browser. Solution 3/ is the long term bet as the future is to have everything in the web. Content is only in one place which makes things a little easier. Development environment needs no setup. However this is more "new" for developers which need to adopt the platform. Live syntax checking is hard to provide but would be quite useful. Alternatively mvn xar:format could also provide syntax checking for XWiki syntax, velocity, groovy, js and css. WDYT ? Which approaches do you believe would be the most promising. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

8 23

[xwiki-devs] [Proposal] Add new API to ModelConfiguration to get the default syntax
by Vincent Massol 01 Aug '13

01 Aug '13

Hi, I'd like to add: public interface ModelConfiguration { … Syntax getDefaultSyntax(); } And the configuration key would be: model.defaultSyntax=xwiki/2.1 This also means deprecating CoreConfiguration.getDefaultDocumentSyntax() in oldcore The goal is to have a clean way for getting the default syntax for documents for example without having to use oldcore. I need this to fix http://jira.xwiki.org/browse/XWIKI-9074 for example. WDYT? Thanks -Vincent

4 4