xwiki-devs

xwiki-devs@xwiki.org

9399 discussions

by Volker.Lapczynski

I tried the Mindmap Sitemap extension in 5.1/2 without luck. It is working in 5.x? It is possible to have a auto-update feature for the Sitemap to make a UpToDate-Sitemap- page? Thanks, Volker from Norway -- View this message in context: http://xwiki.475771.n2.nabble.com/Mindmap-Sitemap-extension-tp7586672.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

12 years

[xwiki-devs] JavaScript dependency... git-module and maven?

by Paul Libbrecht

Hello fellow developers, At Curriki we are about to take over a new JS library for some assessment specific pages. The library is a GitHub repository which we would like to fork and include in Curriki's webapp. Our intent is to do the following but I would like to know if there is a danger of doing so or if it is indeed best practice. - we fork the GitHub repository - part of the adaptation includes creating a maven project; it would build a (partial) web-application - Curriki's web project depends on that webapp(-part) and thus includes the resources - so as to ensure that recipients of Curriki can also build with it, we make the repository a sub-module (somewhat equivalent to an svn:external) in Git and in maven Thanks in advance for your comments, hints as to possible advantages or dangers. Paul

12 years

[xwiki-devs] Improving the XWiki Development environment for traditional Java/JS Developers

by Ludovic Dubost

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

12 years

[xwiki-devs] [Reminder] BFD#32

by Marius Dumitru Florea

Hi everyone, Today is BFD 32. Our goal is to have more bugs closed than created for the past 1400 days! http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 As of now we're 41 bugs behind! Let's close the gap! Here's the BFD#32 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11690 Thanks Marius

12 years

[xwiki-devs] XWiki5 and IE8 support

by Clemens Klein-Robbenhaar

I am wondering about the support for IE 8 in XWiki5.x There are a few layout bugs in XWiki5 (actually been there in XWiki4 as much as I can remember) that do not directly hamper functionality but simply look ugly, like: - scrollbars around the outer frame of the Editor - tabs for comments, etc at the bottom of the page are stacked on top of each other instead of displayed left to right I am thinking of patching things for my instance so they look better in IE8, and I am wondering if IE 8 is still officially supported, and if yes, if patches for such layout glitches are of any interest. Cheers, Clemens

12 years

[xwiki-devs] [vote] release XEclipse 2.0M1

by Ludovic Dubost

Hi, We've never released XEclipse 1.2 (it is stil RC1) and we never release XEclipse 2.0 which uses the REST api to connect to XWiki. Additionally to the REST work, a few bugs have been fixed and the following changes have been implemented: - syntax coloring refactoring to support more langues (xwiki syntax, velocity and groovy) - code folding implementation for xwiki macros and velocity - indentation for velocity (macro, foreach, if blocks) I propose to release this work as XEclipse 2.0M1 in order to have developers start using it and provide feedback. In the mean time it would be nice to wire the auto-completion feature (developped in 1.2 but outdates in terms of APIs) to the server auto-completion module implemented by Vincent and Edy. Here is my +1 for an immediate release Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

12 years

[xwiki-devs] [ANN] XWiki 5.2 Milestone 1 Released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki 5.2 Milestone 1. This release brings a lot of bug fixes (63) and a few improvements (20), notably the ability to toggle email address obfuscation and a better-looking user profile menu. 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/ReleaseNotesXWiki52M1 Thanks -The XWiki dev team

12 years, 1 month

[xwiki-devs] [Idea] Explorer Application

by Ecaterina Moraru (Valica)

Hi devs, This is an idea for an Explorer application that would be used to navigate step-by-step inside the wiki by following the wiki/space/page/objects hierarchy. You can see some mockups and comparison at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ExplorerApp Thanks, Caty

12 years, 1 month

[xwiki-devs] FW: Jasper Reporting macro

by Jones, Dan

Would you guys be interested in a macro that would generate a Jasper report, using an attached jasper compiled file, and a jndi database string? With this, you can have extremely complex reports, images/charts, etc. by just attaching a jasper report to a page and referencing it along with the database jndi name, like "UserDb". Just wondering, I'm already doing it anyway. Someone here would like to use their reports for their dashboard. Dan Jones AAA D2000 phone: 407-444-7042 ________________________________ This communication (including all attachments) is intended solely for the use of the person(s) to whom it is addressed and should be treated as a confidential AAA communication. If you are not the intended recipient, any use, distribution, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately delete it from your system and notify the originator. Your cooperation is appreciated.

12 years, 1 month

[xwiki-devs] [Reminder] BFD#31

by Vincent Massol

Hi everyone, Tomorrow is BFD 31. Current status: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 We're only 1 bug behind! :) That should be easy… too easy! I propose to define a new target: Options: * Increase to 1400 days, that's 49 more bugs to close (roughly 4 BFDs) * Increase to 1500 days, that's 148 more bugs to close (roughly 11 BFDs) * Increase to 1600 days, that's 171 more bugs to close (roughly 15 BFDs) Note 1: 4 years is 1460 days. Note 2: Cycle 5.x is ending around January 2014 so we have roughly 20 more BFDs till the end of the cycle WDYT? Personally I find 148 bugs a bit large so I'd go for 1400 days to start with and later on increase to 1500 days. Here's the BFD#31 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11610 Thanks -Vincent

12 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs