xwiki-devs March 2013

xwiki-devs@xwiki.org

31 participants
79 discussions

[xwiki-devs] [Proposal] When the DB is empty propose to install the EM

by Vincent Massol

Hi devs, When the wiki is empty (just the WAR installed, DW skipped) and when the user goes to the Administration, I think we should have a warning and a button telling the user that he should install the EM UI to be able to install extensions. ATM he can only use the Import feature and this will not allow him to easily install stuff (see the email about the user who tried to install the Admin app like this). WDYT? Thanks -Vincent

11 years, 9 months

[xwiki-devs] [Proposal] Introduce a first set of UI Extension Points

by Jean-Vincent Drean

Hi, following the previous thread I'd like to make a new proposal, introduce the following UIXPs in our templates : * header top: after <div id="xwikimaincontainerinner"> * header bottom : before the closing </div> * content top: after <div id="contentcontainer"> * content bottom : before the closing </div> * footer top: after <div id="footerglobal"> * footer bottom : before the closing </div> Since we don't have a builtin mechanism (as in: have top/bottom static list independent from the UIXP ID in the UIX) for the moment we have to emulate it by inserting multiple API calls (in the current proposal: at the top and bottom of the elements). Now we need to choose a syntax for the extension point IDs: 1) Use only dots in IDs: platform.header.top, platform.header.bottom, etc I was worried about using dots at first [1] but I guess that if we want to have a mapping between the HTML skeleton and UIXP IDs we'll use html5 custom attributes (<element data-uixp="platform.header" />), since we're talking about the future here. 2) Use a different separator for the position: platform.header#top If we decide to create a "position" static list in UIX, a specific separator for the position would allow to easily migrate existing UIXs. My preference goes to 2). Here are the UIXPs that would appear in the current homepage (after renaming the current IDs): * platform.header#top * platform.header#bottom * platform.content#top * platform.content#bottom * platform.panels.rightPanels * platform.panels.Applications * platform.panels.Applications.more * platform.footer#top * platform.footer#bottom [1] The problem dots is that if we decide to move towards a more generic insertion mechanism (http://dev.xwiki.org/xwiki/bin/view/Design/InterfaceExtensions#HInterfaceEx…) with a mapping between HTML IDs and UIPX IDs, the IDs will not be HTML friendly. It's not recommended to use dots in HTML elements ID and Name attributes because of HTML selectors (#id.class is a CSS selector that will look for <element id="id" class="class"/> and not <element id="id.class"/>) which then requires to escape dots in IDs when manipulating the DOM. WDYT ? JV.

11 years, 9 months

[xwiki-devs] [Notice] For contrib developers

by Vincent Massol

Hi guys, I've just added explanations on how to publish a contrib extension on extensions.xwiki.org here: http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HPublishingonextension… Hope it helps, -Vincent

11 years, 9 months

[xwiki-devs] [Proposal] Add support for referencing easily XObjects in the model module

by Vincent Massol

Hi devs, ATM in the model module there's no ability to reference an xobject other than by using a free form name. The problem is that this is not really usable. This is why we introduced the BaseObjectProperty in oldcore. However this is major PITA since we can't have clean code that create an object reference and that doesn't depend on oldcore. I'd like to propose the following: * Modify ObjectProperty to add 2 named parameters: Class reference and position * Make the name optional in EntityReference This means that when we use an EntityReferenceResolver to resolve "wiki:space.page^wiki2:space2.page2" we get an ObjetReference with: * name = null * param1: name = "classReference", value = EntityReference * param2: name = "objectPosition", value = 0 Rationale: * This is exactly what we already do for Locale (and what we'll do for Version too probably) so it's logical to do it for Object References too Consequences: * We need to modify the Seralizers/Resolvers accordingly * We need to modify EntityReference to support a null name * We deprecate BaseObjectProperty * Probably some other stuff to modify like modifying event listeners listening on objects since it's now going to be much easier, etc WDYT? Thanks -Vincent

11 years, 9 months

[xwiki-devs] xwiki-platform-chat and snapshots

by Felix T

Hi all, I worked the last days to get the xwiki-platform-chat running in an example installation. This project looks very interesting for us at Curriki. But I think I have the "normal" problems at this point of time. The current version of the xwiki-platform-chat at github seems to depend on the 4.2-SNAPSHOT version of xwiki. but I can not find them in the snapshot repository of xwiki nexus ( http://nexus.xwiki.org/nexus/content/groups/public-snapshots). Is that intended? Am I doing something wrong (Searching the wrong repository)? Apart from that it would be interesting what you think about the future of the xwiki-platform-chat? Is is intended to be pushed further, to newer versions of xwiki, or away from the jetty dependency? Thanks in advance Felix PS: I tried to remove all the "SNAPSHOT"s and go for version 4.2 this seems to bring me to a "Build Successful" but the resulting .war seems not to be assembled correctly (missing artifacts).

11 years, 9 months

[xwiki-devs] [Brainstorming] XWiki Flavors

by Ecaterina Moraru (Valica)

Hi, XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc. Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions. So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custo… Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.). After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies. I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility. So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavo… If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them. Just some ideas. Thanks, Caty [1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv

11 years, 9 months

[xwiki-devs] [ANN] XWiki 5.0 Milestone 1 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 5.0 Milestone 1. This release is the first release for the 5.x cycle with a new Release application and contains various Extension Manager and Distribution Wizard improvements. 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/ReleaseNotesXWiki50M1 Thanks -The XWiki dev team

11 years, 9 months

[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

11 years, 9 months

[xwiki-devs] [Discussion] Remove 'buttonwrapper' class from Standard

by Ecaterina Moraru (Valica)

Hi devs, Our documentation http://platform.xwiki.org/xwiki/bin/view/DevGuide/VerticalForms is requesting to use .buttonwrapper class as container for button controls. When I added this in the standard was because we were also supporting Toucan Skin and in Toucan this was needed in order to have images on buttons (it was an older skin and we needed to support IE6 and IE7). Since we don't support Toucan anymore and now the CSS has advanced that you can insert additional style by using the ':after' or ':before' pseudo-classes I don't think there is no reason to keep an additional container. I send this mail because Marius created a very sweet Button Group Widget in 4.5.1 http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki451#HButt… and he is using the .buttonwrapper container. I don't think we should promote an additional container anymore. Right now Colibri's CSS demand the 'buttonwrapper' in the style it has both for inputs or for links. This could be changed for Colibri by rewriting a bit those rules or by adding new ones (more specific but would preserve backward compatibility). I don't know if these changes should be kept for a new skin or added now, so let me know what you think. Thanks, Caty

11 years, 9 months

[xwiki-devs] Statistics about XWiki bug fixing

by Vincent Massol

Hi devs, I've created a new dashboard for stats about how we fare regarding bugs: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Namely there are 3 majors charts (left column shows stats over the whole period of the project while on the right stats are for the last 365 days): * Created vs Resolved: Show how many bugs were created vs bugs resolved. The blue line shows the evolution of non fixed bugs. We can see that we've not been good till recently and only recently we're starting to invert the trend. * Recently Created Chart: The red bars shows how many bugs that were created at given point in time are still open. I'm not sure exactly how to draw a conclusion from this chart yet… * Average age chart: Shows how long it was taking to fix a bug as an average. For example on 1 Jan 2006 it was taking 184 days average to get a bug fixed. And on 1st of March 2013 it's now taking 736 days average to get your bug fixed… This shows how bad we are with bug fixing… By continuing our weekly BFDs, we should see this average age go down normally… We should also try to pick the oldest bugs first to make it go down faster ;) WDYT? Any analysis that comes to your mind? For me it means we really needed to start addressing our bugs and that are weekly BFDs are going in the right direction and starting to have some effects. Thanks -Vincent

11 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs March 2013