Re: [xwiki-devs] [Proposal] WikiMacro inline editing: 2 new dedicated macros
This mail is missing the most important part of what we talked about
with Simon actually but maybe the plan was to do that in another mail
?
Without entering too much in the details (I let Simon do that ;)) the
core idea to support inline editing in wiki macro is to cleanup macro
implementation details: in short remove in the result the macro
markers which are coming from the implementation (so in the end you
don't have the velocity macro marker which break the inline editing
flow, etc.). So one of the job of those those special macro helpers
would be to protect the inserted content from that cleanup.
On Wed, May 8, 2019 at 2:09 PM 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"}}
>
> ...
>
> ...
>
> {{/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"}}
>
>
>
>
>
>
>
>
> {{/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).
>
> Thanks,
> Marius
>
>
> On Tue, May 7, 2019 at 9:21 AM Simon Urli 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.u...@xwiki.com
> > More about us at http://www.xwiki.com
> >
--
Thomas Mortagne
Re: [xwiki-devs] [Proposal] WikiMacro inline editing: 2 new dedicated macros
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"}}
...
...
{{/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"}}
{{/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).
Thanks,
Marius
On Tue, May 7, 2019 at 9:21 AM Simon Urli 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.u...@xwiki.com
> More about us at http://www.xwiki.com
>
Re: [xwiki-devs] Analysis of BFD releases 11.2 and 11.3
On Mon, May 6, 2019 at 3:55 PM Vincent Massol wrote: > > > > On 6 May 2019, at 13:10, Marius Dumitru Florea < > mariusdumitru.flo...@xwiki.com> wrote: > > > > On Mon, May 6, 2019 at 1:07 PM Vincent Massol > wrote: > > > >> > >> > >>> On 6 May 2019, at 11:42, Marius Dumitru Florea < > >> mariusdumitru.flo...@xwiki.com> wrote: > >>> > >>> On Thu, May 2, 2019 at 12:22 PM Simon Urli > wrote: > >>> > Hi all, > > On 02/05/2019 11:20, Thomas Mortagne wrote: > > On Thu, May 2, 2019 at 10:57 AM Vincent Massol > wrote: > >> > >> I did a quick analysis of 11.2 & 11.3 to see how many bugs we fixed > since they were supposed to be BFD releases. > >> > >> The results are not that impressive: > >> > >> * XWiki 11.0 (non BFD): 32 bugs closed > >> * XWiki 11.1 (non BFD) 44 bugs closed > >> * XWiki 11.2 (BFD): 37 bugs closed > >> * XWiki 11.3 (BFD): 54 bugs closed > >> > >> Here’s the graph: > >> https://www.evernote.com/l/AHcQ57uKyNRK-YmB09gvM70OXXVTIhFWcs0 > >> > >> The graph shows that during the period (March and April) we had: > >> * Created issues (128) > >> * Resolved issues (123) > >> > >> So we were not even able to catch up with created bugs during the > period. > >> > >> So the question is: why are we not able to catch up? > >> > >> Let’s look at who closed bugs during the period: > >> https://www.evernote.com/l/AHfj3Z0DW8RAuZ0AHw9BX6cnoDZc89KPvog > >> > >> Top resolvers: > >> > >> * Simon Urli - 32 > >> * Thomas Mortagne - 30 > >> * Vincent Massol - 15 > >> * Guillaume Delhumeau - 5 > >> * Marius Dumitru Florea - 2 > >> > >> So one reason is that we roughly have only 2 main issue resolvers > (Simon and Thomas) and the other committers are not closing enough. So > >> not > enough manpower. > >> > >> Would be interesting to see if we have more bugs being created every > month these days when compared to, say, 2 years ago. > >> > >> For ex: > >> * category = 1 AND type = Bug and created >= 2019-03-01 and > >> created > <= 2019-03-31 > >> ** 70 bugs created > >> * category = 1 AND type = Bug and created >= 2018-03-01 and > >> created > <= 2018-03-31 > >> ** 41 bugs created > >> * category = 1 AND type = Bug and created >= 2017-03-01 and > >> created > <= 2017-03-31 > >> ** 46 bugs created > >> * category = 1 AND type = Bug and created >= 2016-03-01 and > >> created > <= 2016-03-31 > >> ** 81 bugs created > >> > >> More generally: > >> * category = 1 AND type = Bug and created >= 2015-01-01 and > >> created > <= 2015-12-31 > >> ** 780 bugs created > >> * category = 1 AND type = Bug and created >= 2016-01-01 and > >> created > <= 2016-12-31 > >> ** 732 bugs created > >> * category = 1 AND type = Bug and created >= 2017-01-01 and > >> created > <= 2017-12-31 > >> ** 609 bugs created > >> * category = 1 AND type = Bug and created >= 2019-01-01 and > >> created > <= 2019-12-31 > >> * 257 bugs created so far. Extrapolates to 257*3 = 771 > >> > >> So it seems we don’t have specifically more bugs being reported in > general. > >> > >> So it seems it’s mostly a manpower/focus issue. > > > > Yes > > > >> > >> WDYT? > > > >>> > FTR Marius was on leave for a full month during those BFD releases, so > we lost an important manpower for fixing issues then. > > >>> > >>> Besides that I also worked on fixing some CKEditor integration bugs > which > >>> are not counted. Not much, I counted 7 bugs, but still. > >> > >> > > > >> They’re supposed to be counted :) I’ve used “category = 1” which > >> includes bundled contrib extensions. > >> > > > > They are definitely not counted. Can you give a link to the jira filter > you > > used? For instance > > > https://jira.xwiki.org/issues/?jql=project%20%3D%20CKEDITOR%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20resolved%20%3E%3D%202019-03-01%20AND%20assignee%20in%20(mflorea)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC > > shows 7 bugs closed during March and April. > > > Depends what we’re talking about. > I'm talking about: " Let’s look at who closed bugs during the period: https://www.evernote.com/l/AHfj3Z0DW8RAuZ0AHw9BX6cnoDZc89KPvog ... * Marius Dumitru Florea - 2 " I closed 10 bugs during the period as shown by https://jira.xwiki.org/issues/?jql=category%20%3D%201%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20resolved%20%3E%3D%202019-03-01%20AND%20assignee%20in%20(mflorea) . > > Indeed if you’re talking about the first part of the email, it’s not > counting the contrib extensions since I did a JQL on the version of XS. By > first part I mean: > > " > * XWiki 11.0 (non BFD): 32 bugs closed > * XWiki 11.1 (non BFD) 44
