xwiki-devs October 2011

xwiki-devs@xwiki.org

29 participants
64 discussions

[xwiki-devs] [VOTE] Naming policy for "-manager" modules and naming the "Workspace feature"

by Eduard Moraru

Hi devs, Since starting to develop the workspaces feature, under the Wiki3.0 project, I`ve used internally the name "Workspace Manager" (providing the script service "$services.workspaceManager") by following the naming scheme used by the Wiki Manager plugin. When the code was moved into the platform, I`ve named the top maven artefact "xwiki-platform-workspace-manager" and the java package "org.xwiki.workspacemanager". Recently, Vincent proposed [1][2](see arguments) to drop the "-manager" suffix, thus, the following changes would occur: - "$services.workspace" instead of "$services.workspaceManager" - "org.xwiki.workspace" instead of "org.xwiki.workspacemanager" - "xwiki-platform-workspace" instead of "xwiki-platform-workspace-manager" - "Workspace Feature" instead of "Workspace Manager Feature" Since it's a new module, there are no problems with backward compatibility so the changes can be applied with some minor refactorings of the velocity code using the service. I did not know about this naming policy, so I`d like your opinion/vote on whether to apply the proposed changes and enforce this policy in the future as well. Here's my +1. Thanks, Eduard References: ----------------- [1] https://github.com/xwiki/xwiki-platform/commit/8c1cc0bc73249eee20159dc3e540… [2] https://github.com/xwiki/xwiki-platform/commit/8c1cc0bc73249eee20159dc3e540…

13 years, 2 months

[xwiki-devs] [VOTE] Keep empty reference in XHTML

by Thomas Mortagne

Hi devs, When you want a local link you use something like [[label>>#anchor]] and it will produce an XHTML like <a href="/xwiki/bin/view/CurrentSpace/CurrentDocument#myanchor">label</a>. IMO this is not very good since: * it's doing lot's of useless work (resolving the reference, getting the corresponding XWikiDocument to finally generate the URL thanks to URLFactory * it's breaking any included local reference since it will be resolved based on the source document and not the current document which makes sense when you target a specific document but not when you asked for a local reference Note that it used to be that way (and I tough it was still the case) and I don't remember why this has been changed. So I proposed to put back the specific handling of empty reference: produce <a href="#myanchor">label</a> in the XHTML renderer for the previous example. WDYT ? Here is my +1 -- Thomas Mortagne

13 years, 2 months

[xwiki-devs] [Proposal] Add support for DocBook integration in XWiki Rendering

by Vincent Massol

Hi devs, This weekend I've been working on adding docbook support in XWiki Rendering by using the Doxia Bridge (since Doxia as both a DocBook parser and a DocBook renderer). I'd like to commit this now for 3.2RC1 if possible since it's not going to cause any issue with anything else (it's something new not impacting existing stuff). WDYT? Thanks -Vincent

13 years, 2 months

[xwiki-devs] [API BREAK] Fixing the directory structure of xwiki-store-filesystem-attachments.

by Caleb James DeLisle

When I made xwiki-store-filesystem-attachments, I made a mistake, I put the files which directly interface with the old core into the com.xpn.xwiki package. I realize it was a mistake not to ask about it and now I would like to correct it. This is an API break because these classes not under an /internal/ dir and are considered by clirr to be API. Since this implements interfaces which are defined in the old core, bridging is obviously impossible I would like to indicate somehow that those classes deal directly with old core and thus will be removed with it when the time comes. A) replace com.xpn.xwiki with org.xwiki.store.internal.legacy this will show that they are essentially with legacy code. B) replace com.xpn.xwiki with org.xwiki.store.filesystem.internal this will mix all of the implementations of oldcore interfaces with classes which provide services to them. Any other ideas? Caleb user@debo8:~/wrk/xwiki.git/xwiki-trunks/xwiki-platform/xwiki-platform-core/xwiki-platform-store/xwiki-platform-store-filesystem-attachments$ find

13 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs October 2011