xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [VOTE] Link reference serialization in WYSIWYG editor output

by Marius Dumitru Florea

Hi devs, We need to decide what is the expected link reference serialization produced by the WYSIWYG editor when you create a link to a wiki page. I think we have to choose between 3 options: (1) Output untyped (ambiguous) link references whenever possible (2) Always output unambiguous (typed) link references (both 'doc:' and 'space:') (3) Always output 'doc:' link references (no 'space:' references) Let's see the details: = OPTION 1: Output untyped link references whenever possible = == <7.2 == Link from A.B * to A.WebHome (space home page) => [[WebHome]] * to A.C (same space) => [[C]] * to X.Y (different space) => [[X.Y]] * to X.WebHome => [[X.WebHome]] == 7.2+ == Link from A.B.WebHome * to A.WebHome (its parent) => [[space:A]] * to A.B.C or A.B.C.WebHome or A.C or A.C.WebHome (child or sibling) => [[C]] (very ambiguous) * to A.B.C.D or A.B.C.D.WebHome (nested page two levels or more below) => [[.C.D]] (ambiguous) * to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]] (ambiguous) * to X.Y.Z or X.Y.Z.WebHome => [[X.Y.Z]] (ambiguous) Link from A.B (terminal) * to A.WebHome (its parent) => [[space:A]] * to A.C or A.C.WebHome (sibling) => [[C]] (ambiguous) * to A.C.D or A.C.D.WebHome (nested page under sibling) => [[A.C.D]] (ambiguous) * to X.Y or X.Y.WebHome => [[X.Y]] (ambiguous) Link from A.B.C (terminal) or A.B.C.WebHome * to A.B.WebHome (its parent) => [[A.B]] (ambiguous) PROS: * shorter link references * hides WebHome from source syntax on 7.2+ CONS: * ambiguous link references * complex code * different output for <7.2 and 7.2+ in case of top level space [[WebHome]] or [[A.WebHome]] vs. [[space:A]] (we need to check if support for nested spaces is available) = OPTION 2: Always output unambiguous link references = == <7.2 == Link from A.B * to A.WebHome (space home page) => [[doc:WebHome]] (relative) * to A.C (same space) => [[doc:C]] (relative) * to X.Y (different space) => [[doc:X.Y]] * to X.WebHome => [[doc:X.WebHome]] == 7.2+ == Link from A.B.WebHome * to A.WebHome (its parent) => [[space:A]] * to A.B.C (terminal child) => [[doc:C]] (relative) * to A.B.C.WebHome (non-terminal child) => [[space:A.B.C]] (absolute) * to A.C (terminal sibling) => [[doc:A.C]] * to A.C.WebHome (non-terminal sibling) => [[space:A.C]] * to A.B.C.D (terminal descendant) => [[doc:.C.D]] (relative) * to A.B.C.D.WebHome (non-terminal descendant) => [[space:A.B.C.D]] (absolute) * to A.C.D (terminal descendant of sibling) => [[doc:A.C.D]] * to A.C.D.WebHome (non-terminal descendant of sibling) => [[space:A.C.D]] * to X.Y.Z => [[doc:X.Y.Z]] * to X.Y.Z.WebHome => [[space:X.Y.Z]] Link from A.B (terminal) * to A.WebHome (its parent) => [[space:A]] * to A.C (terminal sibling) => [[doc:C]] (relative) * to A.C.WebHome (non-terminal sibling) => [[space:A.C]] (absolute) * to A.C.D (terminal descendant of sibling) => [[doc:.C.D]] (relative) * to A.C.D.WebHome (non-terminal descendant of sibling) => [[space:A.C.D]] * to X.Y => [[doc:X.Y]] * to X.Y.WebHome => [[space:X.Y]] Link from A.B.C (terminal) or A.B.C.WebHome * to A.B.WebHome (its parent) => [[space:A.B]] (absolute) PROS: * unambiguous link references ("what you link is what you get") * slightly less complex code (but still complex) * hides WebHome from source syntax on 7.2+ CONS: * longer link references (because of "doc:" and "space:" prefixes) * cannot specify relative 'space:' references * different output for <7.2 and 7.2+ in case of [[doc:WebHome]] vs. [[space:A]] = OPTION 3: Always output 'doc:' references = == <7.2 == Link from A.B * to A.WebHome (space home page) => [[doc:WebHome]] (relative) * to A.C (same space) => [[doc:C]] (relative) * to X.Y (different space) => [[doc:X.Y]] * to X.WebHome => [[doc:X.WebHome]] == 7.2+ == Link from A.B.WebHome * to A.WebHome (its parent) => [[doc:A.WebHome]] * to A.B.C (terminal child) => [[doc:C]] (relative) * to A.B.C.WebHome (non-terminal child) => [[doc:.C.WebHome]] (relative) * to A.C (terminal sibling) => [[doc:A.C]] * to A.C.WebHome (non-terminal sibling) => [[doc:A.C.WebHome]] * to A.B.C.D (terminal descendant) => [[doc:.C.D]] (relative) * to A.B.C.D.WebHome (non-terminal descendant) => [[doc:.C.D.WebHome]] (relative) * to A.C.D (terminal descendant of sibling) => [[doc:A.C.D]] * to A.C.D.WebHome (non-terminal descendant of sibling) => [[doc:A.C.D.WebHome]] * to X.Y.Z => [[doc:X.Y.Z]] * to X.Y.Z.WebHome => [[doc:X.Y.Z.WebHome]] Link from A.B (terminal) * to A.WebHome (its parent) => [[doc:WebHome]] (relative) * to A.C (terminal sibling) => [[doc:C]] (relative) * to A.C.WebHome (non-terminal sibling) => [[doc:.C.WebHome]] (relative) * to A.C.D (terminal descendant of sibling) => [[doc:.C.D]] (relative) * to A.C.D.WebHome (non-terminal descendant of sibling) => [[doc:.C.D.WebHome]] (relative) * to X.Y => [[doc:X.Y]] * to X.Y.WebHome => [[doc:X.Y.WebHome]] Link from A.B.C (terminal) * to A.B.WebHome (its parent) => [[doc:WebHome]] (relative) Link from A.B.C.WebHome * to A.B.WebHome (its parent) => [[doc:A.B.WebHome]] (absolute) PROS: * unambiguous link references ("what you link is what you get") * relative references for nested non-terminal descendants * same output for <7.2 and 7.2+ * simpler code (easier to maintain) CONS: * doesn't hide WebHome from source syntax * longer link references (because of "doc:" prefix and "WebHome" suffix) I don't like ambiguous links so I'm against option (1). I don't think the WYSIWYG editor users care too much about the wiki syntax (option 2), as I commented on http://jira.xwiki.org/browse/XWIKI-13083, so I'm +1 for option (3). WDYT? Thanks, Marius

8 years, 9 months

[xwiki-devs] [Proposal] New Webjars URL format to support relative webjars URL

by Vincent Massol

Hi devs, In order to fix http://jira.xwiki.org/browse/XWIKI-13276, I’m proposing: * Use Case 1: No wiki specified: $services.webjars.url('org.xwiki.contrib:application-ckeditor-webjar', 'ckeditor.js’) would generate: /<context>/webjars/<currentWikiId>/application-ckeditor-webjar/1.4/ckeditor.js * Use Case 2: Wiki specified: $services.webjars.url('org.xwiki.contrib:application-ckeditor-webjar', 'ckeditor.js', {'wiki': 'mywiki’) would generate /<context>/webjars/mywiki/application-ckeditor-webjar/1.4/ckeditor.js Generic format: /<context>/webjars/<wikiId>/path/to/resource WDYT? I prefer this over having to deal with domain vs path-based; I also find it more clear. Thanks -Vincent

8 years, 9 months

[xwiki-devs] Java 8 doclint features: issue with unknown tags

by Vincent Massol

Hi devs, FYI, I was correcting the java 8 doclint errors over the weekend and I’ve noticed an issue: doclint fails the compilation when there’s an “unknown” javadoc tag. For example on the XAR Maven Plugin, the @parameter javadoc tag was making it fail. I’ve fixed it by converting the plugin to use annotation but still this is potentially a problem for other places. I haven’t found any option to turn this off specifically. We can turn off some group of features but apparently it’s not possible to turn off only this feature. See http://docs.oracle.com/javase/8/docs/technotes/tools/unix/javadoc.html I’m mentioning this FYI and also in case someone knows of a solution (ofc finding the corresponding doclint group and turning it off for the failing module is an option albeit not a perfect one). Thanks -Vincent

8 years, 9 months

[xwiki-devs] [Proposal] Make Ratings configurable from wiki and space Administration

by Alexandru Cotiuga

Hi devs, Ratings Application 6.4 introduced a new way to be configured, XWiki objects, meaning that the wikis (in XWiki.RatingsConfig) and the spaces (in *.WebPreferences) now can have their own configuration. Since there is no UI for editing the configuration so it has to be done by editing the objects manually, it would be nice to have a new section in XWiki.XWikiPreferences and in *WebPreferences UIs where individual properties from XWiki.RatingsConfigClass can be inherited or overwritten. Available properties: http://extensions.xwiki.org/xwiki/bin/view/Extension/Ratings+Application#HX… . WDYT? Thanks, Alex

8 years, 9 months

[xwiki-devs] [Proposal] Nested Spaces support for Contrib Applications

by Alexandru Cotiuga

Hello devs, Since I already experimented the Nested Spaces behaviour on the Forum application and there are other applications that might need it also, I think it's time to start discussing this topic and to decide what strategy should be implemented on contrib applications. What I have done in the Forum app was to handle both Pre NS and NS versions of XWiki, writing specific code for each case (wrapped in if-else statements), which proved to be the most complex and hard to maintain way, without much benefit. Sooner or later, everybody will have a NS Xwiki version and then all the support for Pre NS would become useless and then the code should be cleaned, which would be a lot of work again. Besides this already tried strategy, there are some others to be discused: 1: Support both Pre NS and NS versions but in different branches. 2: Move to NS, but keep fixing bugs for Pre NS in a separate branch. (This is what I'm proposing) 3: Move to NS without any maintance on Pre NS. 4: Others? In all the cases, a data migration should be performed. What we decide to do? Thanks, Alex

8 years, 9 months

[xwiki-devs] [XWiki Day] BFD#98

by Thomas Mortagne

Results: http://www.xwiki.org/xwiki/bin/view/Blog/Bug+Fixing+Day+968 -- Thomas Mortagne

8 years, 9 months

[xwiki-devs] Set the standard java.lang.Package fields in the MANIFEST

by Thomas Mortagne

Hi devs, The is a very easy way to get information about a jar trough Package class. Unfortunately we did not configured Maven to set most of the standard fields that Package expect (Specification-* and Implementation-* fields). Once enabled it mean you can get the version of your module (or the module of any class as easily) by doing this.getClass().getPackage().getImplementationVersion(). See https://maven.apache.org/shared/maven-archiver/examples/manifest.html for more. WDYT about enabling that in Maven Jar plugin ? Here is my +1. -- Thomas Mortagne

8 years, 9 months

[xwiki-devs] Get xwiki version from rendering component

by Sean Whalen

Hello, I'm very close to having code to contribute for XWIKI-13284 Add support for loading RSS feeds over HTTPS in the RSS Macro https://jira.xwiki.org/browse/XWIKI-13284 I've looked over the code here https://www.xwiki.org/xwiki/bin/view/FAQ/How+can+I+find+the+version+of+XWik…'m+running @Inject private CoreExtensionRepository coreExtensionRepository; ... CoreExtension distributionExtension = this.coreExtensionRepository. getEnvironmentExtension() Version version = distributionExtension.getId().getVersion() But I can't seem to import org.xwiki.extension.repository.CoreExtensionRepository from org.xwiki.rendering.internal.macro.rss. org.xwiki.extention will not resolve with org.xwiki.rendering.internal.macro.rss open in InteliJ. I'm new to Java web development. What am I missing?

8 years, 9 months

[xwiki-devs] RTWysiwyg bug: can't edit a page with 2 users when they type at the same time

by abtv

For some reason I can't post my bugreport in Jira (it complains about token, but I logged in). I'll post it here. Simultaneous editing with 2 users doesn't work How to reproduce the bug. Open the same page with 2 different users. When they type one after another it works well. But when they type at the SAME time it's impossible to use editor. We tried it with just 2 users. I think you need the second person who will type at the same time. -- View this message in context: http://xwiki.475771.n2.nabble.com/RTWysiwyg-bug-can-t-edit-a-page-with-2-us… Sent from the XWiki- Dev mailing list archive at Nabble.com.

8 years, 9 months

[xwiki-devs] How to enable asome the formatting/editing features of CKEditor which are not enabled by default?

by abtv

Right now XWiki CKEditor looks like http://ckeditor.com/demo#standard . I need at least `justify text` feature. And it would be great if I can make it something like http://ckeditor.com/demo#full or just find a way how to customized it. I saw `Configure the editor from the administration` is a future task , but maybe there is a way to do it with java or velocity? -- View this message in context: http://xwiki.475771.n2.nabble.com/How-to-enable-asome-the-formatting-editin… Sent from the XWiki- Dev mailing list archive at Nabble.com.

8 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs