October 2011 - xwiki-devs@xwiki.org

[xwiki-devs] [VOTE] Naming policy for "-manager" modules and naming the "Workspace feature"
by Eduard Moraru 03 Oct '11

03 Oct '11

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…

5 5

[xwiki-devs] [VOTE] Keep empty reference in XHTML
by Thomas Mortagne 03 Oct '11

03 Oct '11

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

5 5

[xwiki-devs] [Proposal] Add support for DocBook integration in XWiki Rendering
by Vincent Massol 03 Oct '11

03 Oct '11

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

4 3

[xwiki-devs] [API BREAK] Fixing the directory structure of xwiki-store-filesystem-attachments.
by Caleb James DeLisle 01 Oct '11

01 Oct '11

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

1 0