xwiki-devs November 2012

xwiki-devs@xwiki.org

30 participants
78 discussions

[xwiki-devs] [VOTE] Name for Entity classes in the new model

by Vincent Massol

Hi devs, As you may have seen, I've been working on the new model in a branch. We need to decide on the naming of the Entity classes (wiki, space, document, object, object definition, etc). We have several possibilities I know of for naming them: 1) Wiki, Space, Document, Object, ObjectDefinition 2) WikiEntity, SpaceEntity, DocumentEntity, ObjectDefinitionEntity 3) Wiki, Space, Document, XObject, XObjectDefinition (or simply ObjectDefinition) 4) XWiki, XSpace, XDocument, XObject, XObjectDefinition 5) Some other name for objects. Some concerns: * Using Object as in 1) is a bit of a pain since there's java.lang.Object which forces to use the FQN name when coding in Java. Which is why I've put proposals 2) and 3) * In proposal 3) there's a bit of an inconsistency with the X in XObject which is not present in the other entity names, hence proposal 4 and 2) * In proposal 1) there can be some other clashes. For example Document can clash with the DOM Document object My personal vote goes to 2), even though it makes the entity names a bit longer. Cast your votes! Thanks -Vincent

12 years, 1 month

[xwiki-devs] Future of mailsender plugin

by Ludovic Dubost

Hi, I wanted to discuss about the future of the mailsender plugin ? I've been working on a small tool to be able to send a Calendar Invitation by email from a Meeting Notes AppWithinMinutes application and I found some limitation in the mailsender plugin, namely you cannot add multipart alternative email parts in addition to the text and html parts already supported by the plugin. I was able to hack the mailsender plugin to add a vcalendar part but it does not really sound right to do that since we should support any part of any content type, but this is a bigger refactoring. I was wondering what the future is for the mailsender plugin. Do we plan to make it a component and keep the same functionality ? Is there a plan for an alternative component ? And what would be the approach to add a vcalendar part in emails sent by the current mailsender ? This would be needed to support the feature of sending invitation emails which would be very powerfull. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

12 years, 2 months

[xwiki-devs] Free Web-based diagraming tool

by Roman Muntyanu

Hi Devs! Thought you might be interested http://www.diagram.ly/ Roman Muntyanu | rmuntyan(a)softserveinc.com<mailto:rmuntyan@softserveinc.com> | Project Manager | SoftServe<http://www.softserveinc.com/> Inc. | +380-32-240-9090 x3738

12 years, 2 months

[xwiki-devs] [Brainstorming] Handling "young" APIs for backward compatibility

by Vincent Massol

Hi devs, We have recently voted a rule where we said that we will do the following: * Always deprecate APIs * Always move them to Legacy modules * And when there's a technical issue to moving stuff to the Legacy module, only then, send a VOTE to remove an API (see http://markmail.org/message/tino4ngttflc5i3s). This means that from now on (starting on 26th of April 2012) we're not allowed to put excludes in CLIRR. However I've seen that we have added some CLIRR excludes after the vote was passed. I believe that the main issue we have is for "young" APIs that are not considered stable. Proposal 1: Internal package ========= * Young APIs must be located in the "internal" package till they become stable. I propose "internal" to reuse an existing package that we filter when testing for CLIRR. "internal" means that users should not use this API because it's considered unstable and can change at any time. * When a Young API is considered stable enough and we want to open it to public consumption then we move it from "internal" to its target package (that's easy to with IDEs). From that point forward any changes to them goes through the standard mechanism of deprecation/legacy. * If we want to add a new method to an existing public API then this should not be considered a "young" API. It's just an addition to an existing API and thus goes directly to the deprecation/legacy cycle. * We need to be careful to isolate "young" APIs from public API so that users don't inadvertently use "young" unstable APIs by mistake. If not possible then directly go through the deprecation/legacy cycle. The advantage of this proposal is that it doesn't change our current practices and is very easy to verify through CLIRR. Proposal 2: Experimental package ========= Another possibility I can think of is to introduce a new "experimental" package instead of reusing the "internal" one. It has the advantage of being able to follow "young" APIs and ensure they don't stay in that state indefinitely, while still allowing the user who uses it to notice it's experimental. Proposal 3: Experimental Annotation ========= Another idea is to just use an @Experimental javadoc tag for experimental code. It has the advantage of using the target package but it has drawbacks: * It's impossible for users to notice that they're using Experimental APIs since when they import a class they won't see anything that'll tell them they're using a "young" API * It's almost impossible to tell CLIRR to exclude those APIs from its checks. The only way to do this is to modify the source code of the CLIRR plugin AFAIK. Thus we would need to exclude those manually using CLIRR excludes and thus before we release we would need to go over the full list of CLIRR excludes to ensure the excludes listed are only for "young" APIs marked "experimental". Note that I mentioned javadoc tag and not annotation because I believe we need to add information about when the Experimental API was first introduced so that we eventually move it as a proper API by removing the Experimental tag. Maybe we would need a rule such as: keep that tag for less or equal to 3 full minor releases (i.e. 6 months). WDYT? Any other idea? Thanks -Vincent

12 years, 2 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

12 years, 2 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

12 years, 2 months

[xwiki-devs] [UX][Proposal] Skin 4.x

by Ecaterina Moraru (Valica)

Hi devs, I've been working in the 4.3 Roadmap for a new skin proposal. You can see it at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x I recommend looking at the "Annotations Overview" gallery in order to see the different elements of the skin and some explanations. I've made also separate pages for different components of the skin. For example, you can see more information about how the menus work at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4xMenus For each component you can also see how the elements scale and see the responsive layout. For the record, the proposal is made by using Bootstrap ( http://twitter.github.com/bootstrap/). Thanks, Caty

12 years, 2 months

[xwiki-devs] [PROPOSAL] So what do we do for our Maven projects names

by Thomas Mortagne

Hi devs, In order to automate the update of extensions imported from https://github.com/xwiki/ we need to have nothing to modify when an import is done. The last remaining thing is the name on which there is a debate is the name. Right now the name we have in our maven project looks like "XWiki Commons - Extension - Repository - Maven" so that's what we get when importing this project or when viewing it in EM UI. Some of us want to keep this idish name for Maven build but don't like it when displaying extension. I recently introduced a way to overwrite some extension related informations like the name based on properties. So here are the choices we have: 1) Do nothing which mean display "XWiki Commons - Extension - Repository - Maven" in EM UI and extensions.xwiki.org 2) Change our naming in Maven <name> property for it to be more a name than an id that would looks good in EM UI 3) Keep the same naming for Maven <name> and overwrite it everywhere using <xwiki.extension.name> property So, WDYT ? The one that makes the more sense to me is 2) so my +1 goes to this one. Frankly I don't care too much having the current id based display of the summary of built modules in Maven build and I personally won't have any issue to know what name correspond to what project (but that's because I know them well, I can understand new dev could be a bit more lost). Then: * +0 for 3) to +0 (I don't like too much having this special case everywhere in our Maven pom.xml) * -0 for 1) (I agree that it does not looks very nice as a display name). -- Thomas Mortagne

12 years, 2 months

[xwiki-devs] [VOTE] Move all lucene plugin classes to internal

by Jerome Velociter

Hello, Right now all code in the lucene plugin is exposed as API while almost none of it is actual API. I would like to move all lucene plugin classes to an internal package, except for "LucenePluginApi". For the non API "LucenePlugin", I'm not sure, since moving it would break users conf (xwiki.cfg). WDYT ? My +1, Jerome

12 years, 4 months

[xwiki-devs] Handling of property values indexing in Solr

by Jerome Velociter

Hello devs, This mail following a discussion we've had with Eduard on IRC concerning the indexing of object property values. On the current Solr implementation as well as on our lucene plugin, all property values are stored as text/strings. I've expressed the idea that we probably want to store each object's property in a field that matches the XClass property field type. For example, store integers in integer field types, double as doubles, etc. My personnal use case is to store geo objects (for example long/lat coordinates), but I think this has value for other types, numbers for example (it means you can use those numbers as such when querying for instance). Now this will increase the complexity of querying since you would have for example property_text, property_integer, property_double, etc. vs. just propertvalue. Again, I think this complexity should be hidden by the "expending API" Paul mentionned in the mail regarding document translations. WDYT ? Jerome

12 years, 4 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs November 2012