xwiki-devs October 2013

xwiki-devs@xwiki.org

23 participants
62 discussions

[xwiki-devs] [VOTE] Remove all duplicated information from folders names on git repositories

by Thomas Mortagne

Reviving http://markmail.org/message/hlnqke3igkbec332 for as an official vote. We have waited way too long and I think we really need to find a solution even if none of the committers use Windows since a long time. Every time a Windows dev even think of contributing he is very quickly discouraged... As a reminder the issue is that working on XWiki source code is a pain for MS Windows developers because of the (impossible to understand I agree) limitation on path size. So the idea is to find a new logical rule to drastically shorten our paths and Sergiu proposed the following: remove duplicated information from our paths to maven modules. Here is an example: xwiki-platform-core/xwiki-platform-rendering/xwiki-platform-rendering-transformations/xwiki-platform-rendering-transformation-macro (131 chars) would become core/rendering/transformations/macro (36 chars) So WDYT ? Here is my +1 I also find it nicer when navigating using cd and tab in a unix shell anyway. Planning to do it in 5.1 if everyone agree. -- Thomas Mortagne

10 years, 5 months

[xwiki-devs] [VOTE] Create reference to macros

by Denis Gervalle

Hi devs, While building the new signed script solution with Thomas, we have the need to create a new kind of entity references for macros. This will allow us to keep reference to signed macros. Those references will have entityReference as parent, since macros may be contained in document, but also in object properties. Currently we do not need a syntax for those references, since these will only exists as objects. So, no string serializer is planned. So, we need to agree on creating macroReference that will have at this point a unique identifier (to be discussed later) and a parent that could be either a documentReference or an objectPropertyReference. Here is my +1, -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

10 years, 5 months

[xwiki-devs] [Proposal] WebJar integration in XWiki

by Vincent Massol

Hi devs, I'd like to make it easy in XWiki to use javascript frameworks required by extensions. I've found the webjars project (http://webjars.org) which packages javascript frameworks in JAR files available in Maven Central. They work out of the box if you drop them in WEB-INF/lib in a Servlet 3.0 container (like Jetty 7). It works because the 3.0 spec says that any files located in META-INF/resources/<path> will be made available by the servlet container as static resources (accessible as <path>). However the servlet 3.0 specs doesn't support adding those JAR dynamically outside of WEB-INF/lib so it doesn't work with our extension mechanism. Thus I'm proposing the following (which I have tested to work): * Add a new WebJarFilter filter to web.xml * The URL to access, for ex, angular.js packaged in the http://repo2.maven.org/maven2/org/webjars/angularjs/1.1.5-1/angularjs-1.1.5… jar would be: /xwiki/webjar/angularjs/1.1.5/angular.js This allows for example to have a dep on: <dependency> <groupId>org.webjars</groupId> <artifactId>angularjs</artifactId> <version>1.1.5-1</version> <scope>runtime</scope> </dependency> Then in a JSX object: require(["/xwiki/webjar/angularjs/1.1.5/angular.js"], function() { … }); WDYT? Thanks -Vincent

10 years, 7 months

[xwiki-devs] Adding a customer plugin to the wysiwyg editor

by rhierlmeier

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.

10 years, 9 months

[xwiki-devs] [Solr] What do we search for?

by Marius Dumitru Florea

Hi devs, This is a very important question so think carefully. Let me explain: In XWiki (model) we have a few entity types. There are *wikis* which have *spaces* which have *documents*. A document can have *objects* and *attachments*. A document can also define a *class*. At the same time we like to say that in XWiki "everything is a document" because everything revolves around documents. The document is the central notion. We can query the database (using HQL or XWQL) for any of the previously mentioned entities but what should a Solr query return (semantically)? In other words: * are you searching for an object without caring about the document that holds the object? Same for an object property. * how often are you searching for an attachment without caring about the document that holds the attachment? * are you searching for a class or for the document that defines that class? * are you searching for a wiki without caring about the documents it contains? Same for a space. IMO the result of a Solr query should be, semantically, a list of documents. But maybe I'm wrong. ----------------------- Technical Details ----------------------- Unlike a relational database, Solr/Lucene index has a single 'table'. So normally you index a single entity type. Each row in the index represents an entity of that type. As a consequence the result of a Solr query is semantically a list of entities of that type. In our case the entity type is (naturally) *document*. If you want to index more entity types (e.g. index attachments and objects _separately_, not as part of a document) then, since there is only one 'table' in the index, you need to add a 'type' column that specifies the type of entity you have on each row (e.g. type=document, type=attachment, type=object etc.). The result of a Solr query is now, semantically, a list of different entity types, unless you filter by a specific type. It smells like a hack to me. Let's imagine what happens if we want to search for blog posts that has a specific tag. With the first approach this is easy because all the (indexed) information is on a single row. With the second approach this is considerably more complex because the information is spread on multiple rows: * one row with type=document for the blog post document * one row with type=object for the blog post object * one row with type=object for the tab object In a relational database when you have the information spread in multiple places (tables) you do joins. Fortunately (you would says) Solr supports joins. In this particular case we would have to perform 2 joins which means: index X index X index where X represents the cartesian product. The document name would be the join key. Pretty complex even before trying to write this in Solr query syntax.. So basically the question becomes: is it worth indexing more entities _separately_ instead of indexing just documents (with info about their objects and attachments) considering the complexity that it brings in writing Solr queries? Do we search for objects and attachments alone as separate entities often enough to justify this complexity? My answer is no. Thanks, Marius

10 years, 9 months

[xwiki-devs] [Vote] Creation of a design wiki and it's purpose

by Ecaterina Moraru (Valica)

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

10 years, 9 months

[xwiki-devs] [Proposal] Wiki API

by Guillaume "Louis-Marie" Delhumeau

Hi. In this thread, I want to propose you the tiniest API that we need to handle multiwiki. All other features (users, templates, workspaces...) will be on other modules, because I think it is better for the extensibility. The new module will be based on the xwiki-platform-wiki-descriptor-api module, that I will rename to xwiki-platform-wiki-api. The WikiDescriptorManager becomes WikiManager and handle both descriptors and databases. This API will permit: * to create a wiki * to remove a wiki * to list all wikis (returning a list of descriptors) * ... You can see the code of that proposal there: https://github.com/gdelhumeau/xwiki-platform/tree/new-wiki-api/xwiki-platfo… The most important is to decide what the API must look like. The implementation can still be modified afterwards. I hope you like it, Louis-Marie

10 years, 10 months

[xwiki-devs] [Proposal] Crypto API - Expose Bouncy Castle, JCA or not ?

by Denis Gervalle

Hi devs, In the process of preparing signed scripts and other security improvements, I am currently refactoring the crypto API that suffer from being available during the early days of the component manager. Our objective has also changed, and some part will be deprecated in favor of a new more evolve API. In that process, I am wondering which kind of object we allow to go through our API, and I see 3 possibilities: 1) Do not use any object from either Bouncy Castle (BC), nor Java Cryptography API (JCA), and build our own, like BC does. This is obviously the most decouple solution, but it will increase the conversion between APIs. User that may also use BC or JCA on their own will also have to convert their native objects to our own, to use our API. 2) Use the JCA objects only in addition to our own. The JCA has not evolved since a while, and is therefore really stable. This seems to me a better alternative. BC provide support to use those objects, so the conversion to BC is easy. However, these objects are not as friendly as those of BC, so we may need to provide some equivalent helpers existing in BC. 3) Link us more closely with BC, and use the best alternative depending on the situation, either BC, JCA, or our own. This is more easy for us, and better for users of BC outside of our API. This will avoid having to duplicate some BC functionality that are already user friendly enough on our side, therefore limiting maintenance work as well. I am more in favor of 2) or 3), not because I am lazy, but since the initial API already use 2) and I prefer not to duplicate existing features in BC which looks to me a de-facto standard for cryptography in the open-source world. WDYT ? -- Denis Gervalle SOFTEC sa - CEO

10 years, 10 months

[xwiki-devs] [Reminder] BFD#42

by Vincent Massol

Hi devs, Today is Bug Fixing Day 42. We're currently at 3364 bugs created over 1500 days vs 3362 closed, ie only 2 bugs behind! (I think we got lucky ;)) http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Let’s crush the 1500 days threshold today! Here's the BFD#42 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11792 Thanks -Vincent

10 years, 10 months

[xwiki-devs] HTMLCleaner to remove some iframes?

by Paul Libbrecht

Hello fellow xwiki developers, trying to understand why an iframe element disappears after we re-edit source after we insert the iframe in source html, I seem to understand that the service called "HTMLCleaner" is the guilty one (the service is called as a POST to URL /xwiki/resources/js/xwiki/wysiwyg/xwe/HTMLConverter.gwtrpc Is there any way to configure the policy of the html-cleaner? I did not see this among the configs. thanks in advance. paul

10 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs October 2013