- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [Proposal] Do not write pure-developer release notes
by Vincent Massol 31 May '19

31 May '19

Hi devs, Context ======= It’s been since we’ve deviated from the original purpose of the Release Notes by also adding developer-oriented release notes. The goal of the Release Notes was to **highlight** important novelties for our **users**, because looking at the JIRA list is too technical (otherwise we could simply use the Release feature of JIRA! :)). So you may ask why we do have a “Developer” Category in the RN app. These were not for pure developers but for XWiki users who are more advanced and can write scripts in wiki pages. And when it’s the case we **must** add examples, otherwise, it’s completely useless. For example this morning I saw this RN added: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.0/Change004/ This is typically something that has very little value to me: * It’s for pure developers (java devs) * It’s not understandable by anyone except the person who coded it or participated to the dev mailing list discussion about it * It doesn’t say more than what’s in the JIRA issue so what’s the point? * There are no examples at all in it! * Real developers can simply look at the reference documentation or can read the JIRAs. We always link the JIRA issues in the RN anyway (it was for this reason that we’re listing them). * It takes time to write RN items and thus it needs to have high value Proposal ======== * Go back to the original idea and only list developer RN items when they are for scripting users and not APIs. For example, document some new script service or some additions to existing script services. Of course Groovy would allow you to call any API so being able to use it from Groovy is not a good criteria. I’d say that the criteria should be whether the Release Note Change is useful for Velocity users. * Rename “Developers” into “Scripters” or or “Advanced Users” (any better name?) * Always put an example when writing a “developer” change and take the time to explain properly what it’s about. WDYT? Thanks -Vincent

6 14

[xwiki-devs] [Proposal] Merge on save
by Simon Urli 31 May '19

31 May '19

Hi everyone, I'm working on the merge on save for the roadmap of 11.5 and I need some decision to be taken. The main idea of the merge on save, is to try to merge users work in case of save conflict. Knowing that the merge might led to merge conflict in case of edits on the same places. Those merge conflict can be tackled automatically, but a priority will be then given to one version over another. I first propose to add an option in user profile, so users would have the possibility to choose between: 1. Always merge automatically the work, even in case of merge conflict 2. Always merge automatically, but ask what to do in case of merge conflict 3. Always ask what to do in case of save conflict Now the question is: what should be the default option? Option 1 looks like a good fit for decreasing the number of clicks to do, but I'm a bit afraid that in case of conflict they would have the same feeling as before the warning conflict window: i.e. to loose some part of their work. WDYT? Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

6 30

[xwiki-devs] [Brainstorming] Controlling transformations
by Vincent Massol 30 May '19

30 May '19

Hi devs, I’d like to discuss about how to control transformations and when they are executed. Right now we have an all-or-nothing strategy (either the transformation is defined in the config property or it’s not). We have some needs to be able to turn on/turn off some transformations on a page level basis. Here’s the idea that I put on https://jira.xwiki.org/browse/XWIKI-15100: * Add a new xproperty to Rendering.RenderingConfigClass * Modify java code: XWikiRenderingConfiguration, ExtendedRenderingConfiguration, DefaultExtendedRenderingConfiguration, RenderingConfigClassDocumentConfigurationSource * For the wiki level, get the config in Rendering.RenderingConfig * For the page level, get the config from an xobject of type Rendering.RenderingConfigClass * Make RenderingConfiguration.getTransformationNames() search in the current page, parent pages (spaces), current wiki, and fallback to xwiki.properties Note that, as Thomas pointed out in comment of https://jira.xwiki.org/browse/XWIKI-15100 the last point is the hard one. We could imagine having a transformation cache that would be loaded at startup and updated whenever a XWiki.RenderingConfigClass xobject is modified in the wiki. Very similar to wiki components. Note: We could also implement https://jira.xwiki.org/browse/XWIKI-13167 at the same time, with the query string in the URL overriding the transformations. WDYT? Any idea of the cost of adding such a feature in term of days? Does 7 days sounds good to you? (inluding testing and doc). Thanks -Vincent

2 3

[xwiki-devs] [XWiki Day] BFD#211
by Oana-Lavinia Florean 30 May '19

30 May '19

Hello devs, This Thursday is BFD#211: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -18 bugs over 120 days (4 months), i.e. we need to close 18 bugs to have created bugs == closed bugs * -97 bugs over 365 days (1 year) * -156 bugs over 500 days (between 1 and 2 years) * -357 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#211 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14418 Good luck at fixing bugs, Lavinia

1 0

[xwiki-devs] [Contrib] New Repository creation request
by Shubham Jain 28 May '19

28 May '19

Hello Devs, This is a request to create a repo for the XWiki Helm chart project. Something like `xwiki-helm-chart` or `helm-chart` (maybe because it’s implicit that it’s going to be XWiki’s Helm chart?) sounds good to start with. This repo will also be used by Ashish Sharma for his GSOC project. The helm chart should help deploy XWiki in minutes in both local or production level setting, on a Kubernetes setup. My Github handle - slayerjain, Ashish’s - ASHISH932 Thanks, Shubham.

4 6

[xwiki-devs] [ANN] XWiki 11.4 released
by Ecaterina Moraru (Valica) 27 May '19

27 May '19

The XWiki development team is proud to announce the availability of XWiki 11.4. This release brings improvements to the management of the conflicts encountered when editing a page. We've also provided better explained error messages for several cases, in order for the users to understand more easily the occurring issues. For developers we've added the ability to write a wiki macro in velocity and make its content inline-editable. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.4/ Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] Improve Android XWiki authenticator GSOC-19
by Divyansh Jain 25 May '19

25 May '19

Hello, devs My name is Divyansh Jain. I’m pursuing me under graduation in BCA. Bachelor of Computer Application in Mahatma Jyoti Rao Phoole University Campus. Currently, I’m in my sixth semester. I’m an avid and enthusiastic programmer with strong experience in Java and Android. I'll be working on the XWiki Android Authenticator App in this GSOC19. I've already submitted my proposal on http://design.xwiki.org/xwiki/bin/view/Main/ Here's the link to my proposal: - https://design.xwiki.org/xwiki/bin/view/Proposal/Codemigrationandfixexistin… - https://design.xwiki.org/xwiki/bin/view/Proposal/ImproveXWikiAndroidApplica… Though there are still some areas where I still need to study/practice*:* - Kotlin (working on sample projects of my own) - OCID (Need to watch some more google developer videos like https://www.youtube.com/watch?v=DdQTXrk6YTk&feature=youtu.be )e - Unit Test (Practicing on sample projects.) - AccountManager for adding several accounts in the XWiki Authenticator page. I'm very excited to work with all of you devs. I've already started working on migrating code in MVVM architecture and fixing existing bugs some of which are merged: - https://jira.xwiki.org/projects/ANDAUTH/issues/ANDAUTH-48?filter=doneissues - https://jira.xwiki.org/projects/ANDAUTH/issues/ANDAUTH-49?filter=doneissues - https://jira.xwiki.org/projects/ANDAUTH/issues/ANDAUTH-47?filter=doneissues - https://jira.xwiki.org/projects/ANDAUTH/issues/ANDAUTH-27?filter=doneissues Regards, Divyansh Jain

2 1

[xwiki-devs] OpenCollective for XWiki Community
by Ecaterina Moraru (Valica) 23 May '19

23 May '19

Hi devs, This is a proposal for the content we would have if we were to create an OpenCollective account for XWiki. Take a look at https://design.xwiki.org/xwiki/bin/view/Proposal/XWikiOpenCollective The issues we need to solve / validate are: A. Decide on the URL name (xwiki is already taken by XWiki SAS) B. See if XWiki SAS can act like our Fiscal host C. Validate the tiers and content https://design.xwiki.org/xwiki/bin/view/Proposal/XWikiOpenCollective#HTiers (we might need more details on how the "Bug Fixer" works in case we agree to it) Let me know what you think, Caty

2 14

[xwiki-devs] Location for extensions ideas
by Thomas Mortagne 23 May '19

23 May '19

Hi xwikiers, I'm never sure where to put ideas of extensions I have so I often forget them or details I had tough about or gathered back then. I don't think http://design.xwiki.org is the right place until you really start designing the extension. Also it's too generic for this need and not a very good entry point for searching something IMO, more something to link to from somewhere else. I would prefer something really dedicated to this "that would be a nice thingy but not sure about the details yet" state. Would be a good source for hackathons and GSOC or for contributors who are searching for something interesting to work on. I was thinking about the following alternatives: * a new dedicated project on https://jira.xwiki.org * reuse https://jira.xwiki.org/projects/XCONTRIB after some cleanup (close everything left in it basically) but not super clean (it's just that it's a good name) * some new application on http://www.xwiki.org WDYT ? Right now my preference goes to a clean new jira project (just need to think about a good project id) where you put description and close it when the extension work really start on a dedicated location. Less work and should do the job well. -- Thomas Mortagne

4 7

[xwiki-devs] Fwd: [Proposal] WikiMacro inline editing: 2 new dedicated macros
by Marius Dumitru Florea 21 May '19

21 May '19

---------- Forwarded message --------- From: Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> Date: Tue, May 21, 2019 at 1:06 PM Subject: Re: [xwiki-devs] [Proposal] WikiMacro inline editing: 2 new dedicated macros To: Simon Urli <simon.urli(a)xwiki.com> On Mon, May 20, 2019 at 11:57 AM Simon Urli <simon.urli(a)xwiki.com> wrote: > Hello Marius, > > On 14/05/2019 13:12, Simon Urli wrote: > > > > > > On 14/05/2019 13:07, Marius Dumitru Florea wrote: > >> On Tue, May 14, 2019 at 2:04 PM Simon Urli <simon.urli(a)xwiki.com > >> <mailto:[email protected]>> wrote: > >> > >> > >> > >> On 14/05/2019 13:02, Marius Dumitru Florea wrote: > >> > On Tue, May 14, 2019 at 1:55 PM Simon Urli <simon.urli(a)xwiki.com > >> <mailto:[email protected]> > >> > <mailto:[email protected] <mailto:[email protected]>>> > >> wrote: > >> > > >> > > >> > > >> > On 14/05/2019 12:43, Marius Dumitru Florea wrote: > >> > > On Fri, May 10, 2019 at 11:21 AM Simon Urli > >> <simon.urli(a)xwiki.com <mailto:[email protected]> > >> > <mailto:[email protected] <mailto:[email protected]>> > >> > > <mailto:[email protected] <mailto:[email protected] > > > >> <mailto:[email protected] <mailto:[email protected]>>>> > wrote: > >> > > > >> > > Hi Marius, all, > >> > > > >> > > On 09/05/2019 09:29, Simon Urli wrote: > >> > > > Hi Marius, all, > >> > > > > >> > > > On 08/05/2019 14:09, Marius Dumitru Florea wrote: > >> > > >> Hi Simon, > >> > > >> > >> > > >> As I commented on > >> > > https://github.com/xwiki/xwiki-platform/pull/1109 I > >> > > >> think > >> > > >> that most of the time you will want to use a > >> scripting > >> > macro + > >> > > HTML macro > >> > > >> like this: > >> > > >> > >> > > >> {{velocity}} > >> > > >> {{html clean="false"}} > >> > > >> <div ...> > >> > > >> ... > >> > > >>  > >> > > >> ... > >> > > >> </div> > >> > > >> {{/html}} > >> > > >> {{/velocity}} > >> > > >> > >> > > >> An example of such a macro could be: > >> > > >> > >> > > >> {{figure src="someImage.png"}}some > >> description{{/figure}} > >> > > >> > >> > > >> The macro code would look like this: > >> > > >> > >> > > >> {{velocity}} > >> > > >> {{html clean="false"}} > >> > > >> <div class="figure"> > >> > > >> <div class="figure-image-wrapper"> > >> > > >> <img src="..." class="figure-image" /> > >> > > >> </div> > >> > > >> <div class="figure-caption"> > >> > > >>  > >> > > >> </div> > >> > > >> </div> > >> > > >> {{/html}} > >> > > >> {{/velocity}} > >> > > >> > >> > > >> I know you can output DIVs with wiki syntax but > >> that's > >> > not the > >> > > point. The > >> > > >> point is that we want to use HTML for the UI and > >> leave > >> > the wiki > >> > > syntax > >> > > >> for > >> > > >> the user content. So I don't think > >> ``wikimacrocontent`` > >> > is that > >> > > useful > >> > > >> (if > >> > > >> it's only purpose is to help you output the > >> > > ``non-generated-content`` > >> > > >> DIV). > >> > > > > >> > > > so as Thomas mentioned in order to allow inline > >> editing I also > >> > > perform > >> > > > transformation on the generated list of blocks in > >> > > > DefaultWikiMacroRenderer to remove the macro marker > >> that > >> > can cause > >> > > > troubles for inline editing. So the > >> wikimacrocontent is > >> > used both to > >> > > > insert content, and to detect where to remove the > >> macro > >> > markers > >> > > during > >> > > > the transformation. > >> > > > > >> > > > Now right now even with this solution it's not > >> possible to > >> > inline > >> > > edit > >> > > > html macro because of the way it's designed: the > >> HTML > >> > macro only > >> > > create > >> > > > a raw blocks that contains all the html, so I > >> cannot easily > >> > > transform it > >> > > > for inline editing. IMO it requires a change in the > >> HTML > >> > macro. > >> > > > >> > > so, re the subject of HTML macro and the handle of > >> inline > >> > editing I was > >> > > actually wrong to assume that it was linked to the raw > >> block. > >> > It's > >> > > actually linked to the metadata that are currently not > >> > handled in the > >> > > custom HTML renderer of HTML macro. I created a > >> dedicated > >> > issue for it > >> > > (https://jira.xwiki.org/browse/XRENDERING-563) it's > >> actually > >> > easy to > >> > > fix since the mechanism already exist in > >> AnnotatedHTMLRenderer. > >> > > So I've been able to successfully create a very simple > >> inline > >> > editing > >> > > wiki macro like this: > >> > > > >> > > {{html wiki="true"}} > >> > > <div style="border: 1px solid red"> > >> > > ((({{wikimacrocontent/}}))) > >> > > </div> > >> > > {{/html}} > >> > > > >> > > I had to put the ((( ))) to avoid having the > >> wikimacrocontent > >> > rendered > >> > > inline, maybe there's a way to do it cleaner, but I > >> just > >> > wanted to > >> > > check > >> > > that it's working there. > >> > > IMO it should really be the next priority in terms of > >> > usability of > >> > > inline editing, to find a way to allow inline > >> editing of > >> > inline macro. > >> > > > >> > > > >> > > Would it be hard to have a scripting API equivalent for > the > >> > > wikimacrocontent macro? I don't like mixing HTML with wiki > >> syntax > >> > (you > >> > > can get into trouble easily). As a wiki macro developer I > >> would > >> > prefer > >> > > to be able to write something like this: > >> > > > >> > > {{velocity}} > >> > > {{html clean="false"}} > >> > > <div class="my-macro"> > >> > > $xcontext.macro.renderNonGeneratedContent() > >> > > </div> > >> > > {{/html}} > >> > > {{/velocity}} > >> > > Thanks, > >> > > Marius > >> > > >> > Basically this API would need to: > >> > 1. Create the div around the macro content > >> > 2. Add a marker around that div to specify that > >> everything's inside > >> > should be kept (since we need to remove the other macro > >> markers in the > >> > WikiMacroRenderer) > >> > 3. Render the div + the content in the right target > syntax > >> > > >> > What bothers me here is that I don't think we would have > >> access to the > >> > rendering context, to know the syntax that should be used to > >> render the > >> > metadata. > >> > > >> > > >> > The alternative is: > >> > > >> > {{velocity}} > >> > {{html clean="false"}} > >> > <div class="my-macro"> > >> > ... > >> > {{html}} > >> > > >> > {{wikimacrocontent/}} > >> > > >> > {{html clean="false"}} > >> > ... > >> > </div> > >> > {{/html}} > >> > {{/velocity}} > >> > It feels like a hack, but I can leave with it. > >> > >> Actually you could do: > >> > >> {{html wiki="true"}} > >> <div class="my-macro"> > >> {{wikimacrocontent/}} > >> </div> > >> {{/html}} > >> > >> but yeah it's mixing both syntax. > >> > >> I want to avoid this if possible. > > > > Now I have to check but with > > https://jira.xwiki.org/browse/XRENDERING-563 you might be able to > > directly do: > > > > {{velocity}} > > {{html}} > > <div class="mymacro"> > > <div > > data-xwiki-non-generated-content="java.util.List<org.xwiki.Block>"> > > $xcontext.macro.content > > </div> > > </div> > > {{/html}} > > {{/velocity}} > > > > However I don't know how it would handle content containing other macros. > > So I just tested how we would do that, and I managed to do it using the > following code: > {{velocity}} > {{html}} > <div style="border: 1px solid red"> > <div class="xwiki-metadata-container" > data-xwiki-non-generated-content="java.util.List<org.xwiki.Block>" > data-xwiki-wikimacrocontent="true" data-xwiki-syntax="xhtml/1.0"> > $xcontext.macro.content > </div> > </div> > {{/html}} > {{/velocity}} > > Note that the syntax metadata is mandatory here since the HTML Macro > will consider that it's content is HTML. > > Now there is one remaining issue: we cannot apparently insert macro in > it. Here's the parameter request which is sent: > > <!DOCTYPE+html+PUBLIC+"-//W3C//DTD+XHTML+1.0+Strict//EN"+" > http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html+xmlns=" > http://www.w3.org/1999/xhtml > "+xml:lang="en"+lang="en"><body><div+data-xwiki-non-generated-content="java.util.List<org.xwiki.Block>"+data-xwiki-syntax="xhtml/1.0"+data-xwiki-wikimacrocontent="true"+class="xwiki-metadata-container"><p>Some+content+inside+the+macro+encore+un+test?</p><div+class="wikimodel-emptyline"></div><p></p><p>un+autre+<strong>test</strong></p></div><div+class="wikimodel-emptyline"></div></body></html> > > you can see the markers for the box macro, with a new paragraph around > it and an empty line before it. > Here's the body answer of the request: > > <body id="body" class="skin-flamingo viewbody main wiki-xwiki > space-TotoMacro"><div > style="border: 1px solid red"> > <div class="xwiki-metadata-container" > data-xwiki-non-generated-content="java.util.List<org.xwiki.Block>" > data-xwiki-syntax="xhtml/1.0" data-xwiki-wikimacrocontent="true"> > <p>Some content inside the macro encore un test?</p><p>un autre > <strong>test</strong></p> > </div> > </div><div class="wikimodel-emptyline"></div></body> > > The fact that the macro marker is missing is expected since I removed it > after transformation in WikiMacroRenderer. However, it should have been > transformed: we should get the HTML for the box. I still need to > investigate to understand why it disappeared. > > > I'm not sure if I need to document this way to allow inline editing of > macro content, or maybe just in HTML macro page? WDYT? > I think it's worth documenting it on the wiki macro documentation page or on the tutorial about writing a wiki macro, as an advanced feature. I don't think the HTML macro page is the right place. Thanks for working on this, Marius > > Simon > > >> > >> Still it's working. > >> > > >> > Thanks, > >> > Marius > >> > > >> > > > >> > > > >> > > Simon > >> > > > > >> > > > Simon > >> > > >> > >> > > >> Thanks, > >> > > >> Marius > >> > > >> > >> > > >> > >> > > >> On Tue, May 7, 2019 at 9:21 AM Simon Urli > >> > <simon.urli(a)xwiki.com <mailto:[email protected]> > >> <mailto:[email protected] <mailto:[email protected]>> > >> > > <mailto:[email protected] > >> <mailto:[email protected]> <mailto:[email protected] > >> <mailto:[email protected]>>>> > >> > wrote: > >> > > >> > >> > > >>> Hi everyone, > >> > > >>> > >> > > >>> I'm currently working on allowing inline editing > >> on new > >> > wikimacros. > >> > > >>> My first challenge right now is to cope with the > >> problem of > >> > > inserting > >> > > >>> the macro content and allowing to inline edit it. > >> > > >>> > >> > > >>> In order to do so, I propose to create two new > >> dedicated > >> > macro: > >> > > >>> - wikimacrocontent: would allow to insert and > >> inline > >> > edit a > >> > > wiki > >> > > >>> macro content > >> > > >>> - wikimacroparameter: the same for a > >> parameter. > >> > > >>> > >> > > >>> The idea would be to be able to write something > >> such as: > >> > > >>> > >> > > >>> {{velocity}} > >> > > >>> {{wikimacrocontent/}} > >> > > >>> This is a content of > >> $xcontext.macro.content.length() > >> > characters. > >> > > >>> {{/velocity}} > >> > > >>> > >> > > >>> So the purpose of those macros would be twofold: > >> > > >>> 1. to ease the insertion of macro > >> content/parameters (no > >> > > need to > >> > > >>> always use > >> {{velocity}}$xcontext.macro.content{{/velocity}} > >> > > >>> 2. to create the dedicated metadata around > the > >> > content and > >> > > to be > >> > > >>> processed during wikimacro rendering to allow > >> inline editing > >> > > >>> > >> > > >>> Of course those macro would be only to be used > >> inside a > >> > wikimacro. > >> > > >>> I started to develop the wikimacroccontent, so I > >> have a > >> > first > >> > > working > >> > > >>> POC, but I'd like to know WDYT about this. > >> > > >>> > >> > > >>> I would also be really happy if you could give me > >> some > >> > wikimacro > >> > > >>> examples where the inline editing would make > >> sense, so I > >> > could > >> > > use it in > >> > > >>> my tests. > >> > > >>> > >> > > >>> Thanks, > >> > > >>> Simon > >> > > >>> -- > >> > > >>> Simon Urli > >> > > >>> Software Engineer at XWiki SAS > >> > > >>> simon.urli(a)xwiki.com > >> <mailto:[email protected]> <mailto:[email protected] > >> <mailto:[email protected]>> > >> > <mailto:[email protected] <mailto:[email protected]> > >> <mailto:[email protected] <mailto:[email protected]>>> > >> > > >>> More about us at http://www.xwiki.com > >> > > >>> > >> > > > > >> > > > >> > > -- > >> > > Simon Urli > >> > > Software Engineer at XWiki SAS > >> > > simon.urli(a)xwiki.com <mailto:[email protected]> > >> <mailto:[email protected] <mailto:[email protected]>> > >> > <mailto:[email protected] <mailto:[email protected]> > >> <mailto:[email protected] <mailto:[email protected]>>> > >> > > More about us at http://www.xwiki.com > >> > > > >> > > >> > -- > >> > Simon Urli > >> > Software Engineer at XWiki SAS > >> > simon.urli(a)xwiki.com <mailto:[email protected]> > >> <mailto:[email protected] <mailto:[email protected]>> > >> > More about us at http://www.xwiki.com > >> > > >> > >> -- Simon Urli > >> Software Engineer at XWiki SAS > >> simon.urli(a)xwiki.com <mailto:[email protected]> > >> More about us at http://www.xwiki.com > >> > > > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.urli(a)xwiki.com > More about us at http://www.xwiki.com >

1 0