widget macros (ticket #138)

[Gary Martin <ga...@wandisco.com>]

Hi,

We have an old work item that appears not to have been discussed here. 
For some reason it was considered controversial so I thought I would 
bring it up here in order to decide how far to take it.

The full story is in https://issues.apache.org/bloodhound/ticket/138 
which intends to provide wiki macros for the widgets that are used on 
the dashboard style views so that they can be used in any part of the 
system that accepts wiki syntax. So, for example, a user could add a 
widget displaying a list of tickets or a widget showing a summary of 
tickets by resource.

Effectively this would provide the ability for users to create their own 
dashboards - whether or not that is what we want to see is an 
interesting question, but it seems more likely that people would just 
make use of them on a more ad hoc basis.

I'll avoid advocating a particular decision too early as it would be 
good to get some opinions and you may be able to change my mind on this 
issue.

Cheers,
     Gary

Re: widget macros (ticket #138)

[Olemis Lang <ol...@gmail.com>]

On 11/29/12, Gary Martin <ga...@wandisco.com> wrote:
> On 29/11/12 22:16, Joe Dreimann wrote:
>> On 29 Nov 2012, at 16:27, Gary Martin <ga...@wandisco.com> wrote:
>>
>>> On 29/11/12 15:16, Olemis Lang wrote:
>>>> On 11/29/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>> On 19/11/12 15:36, Olemis Lang wrote:
>
[...]
>
>>>>> At some point, once we get feature parity, we could consider
>>>>> overriding
>>>>> TicketQuery so that it uses Widget(TicketQuery,...) instead.
>>>> fwiw it's possible to have TicketQueryWidget( ... ) rather than
>>>> Widget(TicketQuery, ...) . In general , <WidgetName>Widget( ... ) vs
>>>> Widget(<WidgetName>, ...)
>>> Well, not quite what I mean - two macros for effectively the same thing
>>> is not really ideal.
>
> Actually, on the subject of names, I don't see the specific requirement
> for having Widget in the name at all. Surely that doesn't strictly have
> to be the way that you distinguish that the macro is widget enhanced.
>

/me neither . Nonetheless it's a practical approach to

1. do not clash with other macro names contributed
    by core + plugins
2. provide a generic widget-to-macro mapping when
    implementing `trac.wiki.api.IWikiMacroProvider.get_macros`

;)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Re: widget macros (ticket #138)

[Gary Martin <ga...@wandisco.com>]

On 29/11/12 22:16, Joe Dreimann wrote:
>
>
> On 29 Nov 2012, at 16:27, Gary Martin <ga...@wandisco.com> wrote:
>
>> On 29/11/12 15:16, Olemis Lang wrote:
>>> On 11/29/12, Gary Martin <ga...@wandisco.com> wrote:
>>>> On 19/11/12 15:36, Olemis Lang wrote:
>>>> The advantage is
>>>> if we bring enhancements to the existing functionality. At the moment,
>>>> in terms of TicketQuery vs Widget(TicketQuery, ...) we bring certain
>>>> improvements but not all the functionality yet.
>>> what's missing
>> Well, I suppose there is a question of whether any discrepancies matter. I note that columns are linked to queries in the TicketQuery that give the list of tickets ordered by the relevant field. It is possible that if we were to put links on columns that we would want their primary action to be to order by that field with a bit of ajax.
>>
>> Interestingly [[TicketQuery(table, ?status=!closed&keywords=~starter, max=5)]] also seems to include the keywords field as one of the columns. That is almost certainly not the desired output for our dashboard views but I suppose it may be a comfort to some that it was the right query.
> I think it would be better to provide an indicator what the query is and not show the column, unless requested.
> That indicator could be a line of text showing the query in a readable way or an info/config dialogue. Anyway, we don't need to decide thy just yet.

Absolutely.. I was really only pointing out a few discrepancies. At the 
moment I am really less interested in the specific solutions to these 
differences and more interested in whether we have any consensus on the 
idea of calling our TicketQuery in a Widget a replacement for the 
default. If we want to avoid aspects of feature parity and consistency 
of the defaults, we probably won't be able to go that route.

It should be remembered that we are likely to want to have a macro that 
can deal with our anticipated query syntax enhancements, along with the 
old syntax. It might be worth checking if the default TicketQuery macro 
is likely to be able to deal with that.

>
>>>> At some point, once we get feature parity, we could consider overriding
>>>> TicketQuery so that it uses Widget(TicketQuery,...) instead.
>>> fwiw it's possible to have TicketQueryWidget( ... ) rather than
>>> Widget(TicketQuery, ...) . In general , <WidgetName>Widget( ... ) vs
>>> Widget(<WidgetName>, ...)
>> Well, not quite what I mean - two macros for effectively the same thing is not really ideal.

Actually, on the subject of names, I don't see the specific requirement 
for having Widget in the name at all. Surely that doesn't strictly have 
to be the way that you distinguish that the macro is widget enhanced.

Cheers,
     Gary

Re: widget macros (ticket #138)

[Joe Dreimann <jo...@wandisco.com>]

On 29 Nov 2012, at 16:27, Gary Martin <ga...@wandisco.com> wrote:

> On 29/11/12 15:16, Olemis Lang wrote:
>> On 11/29/12, Gary Martin <ga...@wandisco.com> wrote:
>>> On 19/11/12 15:36, Olemis Lang wrote:
>>>> On 11/19/12, Peter Koželj <pe...@digiverse.si> wrote:
>>>>> First I would like to check if I understand this correctly.
>>>>> So, this means that a user can embed widgets from dashboard in wiki
>>>>> pages
>>>>> or ticket descriptions?
>>>> anywhere WikiFormatting is supported , yes . Widgets are enhanced
>>>> macros in first place.
>>>> 
>>>>> I do not se any problems with this at the moment
>>>> cool
>>>> 
>>>>> but, this can not be a
>>>>> substitute for user customizable dashboard.
>>>>> We still need to provide fully customizable dashboard
>>>> +1
>>>> for the moment think of it like the replacement to TicketQuery et al.
>>>> as we use it today on i.a.o . It looks weird to me that we were able
>>>> to customize those views and we can not embed a similar widget in a
>>>> wiki page when we need it .
>>> I don't see that it is weird not to be able to do this.
>> I could find the right word ...
>> 
>>> The advantage is
>>> if we bring enhancements to the existing functionality. At the moment,
>>> in terms of TicketQuery vs Widget(TicketQuery, ...) we bring certain
>>> improvements but not all the functionality yet.
>> what's missing
> 
> Well, I suppose there is a question of whether any discrepancies matter. I note that columns are linked to queries in the TicketQuery that give the list of tickets ordered by the relevant field. It is possible that if we were to put links on columns that we would want their primary action to be to order by that field with a bit of ajax.
> 
> Interestingly [[TicketQuery(table, ?status=!closed&keywords=~starter, max=5)]] also seems to include the keywords field as one of the columns. That is almost certainly not the desired output for our dashboard views but I suppose it may be a comfort to some that it was the right query.

I think it would be better to provide an indicator what the query is and not show the column, unless requested.
That indicator could be a line of text showing the query in a readable way or an info/config dialogue. Anyway, we don't need to decide thy just yet.


>> 
>>> At some point, once we get feature parity, we could consider overriding
>>> TicketQuery so that it uses Widget(TicketQuery,...) instead.
>> fwiw it's possible to have TicketQueryWidget( ... ) rather than
>> Widget(TicketQuery, ...) . In general , <WidgetName>Widget( ... ) vs
>> Widget(<WidgetName>, ...)
> 
> Well, not quite what I mean - two macros for effectively the same thing is not really ideal.
> 
> Cheers,
>    Gary

Re: widget macros (ticket #138)

[Gary Martin <ga...@wandisco.com>]

On 29/11/12 15:16, Olemis Lang wrote:
> On 11/29/12, Gary Martin <ga...@wandisco.com> wrote:
>> On 19/11/12 15:36, Olemis Lang wrote:
>>> On 11/19/12, Peter Koželj <pe...@digiverse.si> wrote:
>>>> First I would like to check if I understand this correctly.
>>>> So, this means that a user can embed widgets from dashboard in wiki
>>>> pages
>>>> or ticket descriptions?
>>>>
>>> anywhere WikiFormatting is supported , yes . Widgets are enhanced
>>> macros in first place.
>>>
>>>> I do not se any problems with this at the moment
>>> cool
>>>
>>>> but, this can not be a
>>>> substitute for user customizable dashboard.
>>>> We still need to provide fully customizable dashboard
>>> +1
>>> for the moment think of it like the replacement to TicketQuery et al.
>>> as we use it today on i.a.o . It looks weird to me that we were able
>>> to customize those views and we can not embed a similar widget in a
>>> wiki page when we need it .
>> I don't see that it is weird not to be able to do this.
> I could find the right word ...
>
>> The advantage is
>> if we bring enhancements to the existing functionality. At the moment,
>> in terms of TicketQuery vs Widget(TicketQuery, ...) we bring certain
>> improvements but not all the functionality yet.
>>
> what's missing

Well, I suppose there is a question of whether any discrepancies matter. 
I note that columns are linked to queries in the TicketQuery that give 
the list of tickets ordered by the relevant field. It is possible that 
if we were to put links on columns that we would want their primary 
action to be to order by that field with a bit of ajax.

Interestingly [[TicketQuery(table, ?status=!closed&keywords=~starter, 
max=5)]] also seems to include the keywords field as one of the columns. 
That is almost certainly not the desired output for our dashboard views 
but I suppose it may be a comfort to some that it was the right query.
>
>> At some point, once we get feature parity, we could consider overriding
>> TicketQuery so that it uses Widget(TicketQuery,...) instead.
>>
> fwiw it's possible to have TicketQueryWidget( ... ) rather than
> Widget(TicketQuery, ...) . In general , <WidgetName>Widget( ... ) vs
> Widget(<WidgetName>, ...)

Well, not quite what I mean - two macros for effectively the same thing 
is not really ideal.

Cheers,
     Gary

Re: widget macros (ticket #138)

[Olemis Lang <ol...@gmail.com>]

On 11/29/12, Gary Martin <ga...@wandisco.com> wrote:
> On 19/11/12 15:36, Olemis Lang wrote:
>> On 11/19/12, Peter Koželj <pe...@digiverse.si> wrote:
>>> First I would like to check if I understand this correctly.
>>> So, this means that a user can embed widgets from dashboard in wiki
>>> pages
>>> or ticket descriptions?
>>>
>> anywhere WikiFormatting is supported , yes . Widgets are enhanced
>> macros in first place.
>>
>>> I do not se any problems with this at the moment
>> cool
>>
>>> but, this can not be a
>>> substitute for user customizable dashboard.
>>> We still need to provide fully customizable dashboard
>> +1
>> for the moment think of it like the replacement to TicketQuery et al.
>> as we use it today on i.a.o . It looks weird to me that we were able
>> to customize those views and we can not embed a similar widget in a
>> wiki page when we need it .
>
> I don't see that it is weird not to be able to do this.

I could find the right word ...

> The advantage is
> if we bring enhancements to the existing functionality. At the moment,
> in terms of TicketQuery vs Widget(TicketQuery, ...) we bring certain
> improvements but not all the functionality yet.
>

what's missing

> At some point, once we get feature parity, we could consider overriding
> TicketQuery so that it uses Widget(TicketQuery,...) instead.
>

fwiw it's possible to have TicketQueryWidget( ... ) rather than
Widget(TicketQuery, ...) . In general , <WidgetName>Widget( ... ) vs
Widget(<WidgetName>, ...)

> Anyway, I'll try to commit the work soon and see where we are as it
> seems to be providing less controversy now given that discussion on this
> was limited.
>

thanks .
I look forward to implement further improvements .

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Re: widget macros (ticket #138)

[Gary Martin <ga...@wandisco.com>]

On 19/11/12 15:36, Olemis Lang wrote:
> On 11/19/12, Peter Koželj <pe...@digiverse.si> wrote:
>> First I would like to check if I understand this correctly.
>> So, this means that a user can embed widgets from dashboard in wiki pages
>> or ticket descriptions?
>>
> anywhere WikiFormatting is supported , yes . Widgets are enhanced
> macros in first place.
>
>> I do not se any problems with this at the moment
> cool
>
>> but, this can not be a
>> substitute for user customizable dashboard.
>> We still need to provide fully customizable dashboard
> +1
> for the moment think of it like the replacement to TicketQuery et al.
> as we use it today on i.a.o . It looks weird to me that we were able
> to customize those views and we can not embed a similar widget in a
> wiki page when we need it .

I don't see that it is weird not to be able to do this. The advantage is 
if we bring enhancements to the existing functionality. At the moment, 
in terms of TicketQuery vs Widget(TicketQuery, ...) we bring certain 
improvements but not all the functionality yet.

At some point, once we get feature parity, we could consider overriding 
TicketQuery so that it uses Widget(TicketQuery,...) instead.

Anyway, I'll try to commit the work soon and see where we are as it 
seems to be providing less controversy now given that discussion on this 
was limited.

Cheers,
     Gary

Re: widget macros (ticket #138)

[Olemis Lang <ol...@gmail.com>]

On 11/19/12, Peter Koželj <pe...@digiverse.si> wrote:
> First I would like to check if I understand this correctly.
> So, this means that a user can embed widgets from dashboard in wiki pages
> or ticket descriptions?
>

anywhere WikiFormatting is supported , yes . Widgets are enhanced
macros in first place.

> I do not se any problems with this at the moment

cool

> but, this can not be a
> substitute for user customizable dashboard.
> We still need to provide fully customizable dashboard

+1
for the moment think of it like the replacement to TicketQuery et al.
as we use it today on i.a.o . It looks weird to me that we were able
to customize those views and we can not embed a similar widget in a
wiki page when we need it .

> and compared to that
> I see this macros as lower priority feature.
>

The fact is that some work is needed to finish custom dashboards
support and it's going to take a while until such solution will be
implemented , reviewed and committed . OTOH the patches in #138 and
#139 are ready to go .

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Re: widget macros (ticket #138)

[Peter Koželj <pe...@digiverse.si>]

First I would like to check if I understand this correctly.
So, this means that a user can embed widgets from dashboard in wiki pages
or ticket descriptions?

I do not se any problems with this at the moment but, this can not be a
substitute for user customizable dashboard.
We still need to provide fully customizable dashboard and compared to that
I see this macros as lower priority feature.

Peter

On 16 November 2012 05:29, Olemis Lang <ol...@gmail.com> wrote:

> On 11/15/12, Gary Martin <ga...@wandisco.com> wrote:
> > Hi,
> >
>
> :)
>
> > We have an old work item that appears not to have been discussed here.
> > For some reason it was considered controversial so I thought I would
> > bring it up here in order to decide how far to take it.
> >
>
> Thanks for restarting the discussion once again.
>
> [...]
> >
> > Effectively this would provide the ability for users to create their own
> > dashboards - whether or not that is what we want to see is an
> > interesting question,
>
> ... even if users could do this I wonder whether this is a strong
> reason for not including WidgetMacro .
>
> > but it seems more likely that people would just
> > make use of them on a more ad hoc basis.
> >
>
> Exactly the macro serves to many other purposes . If widgets are and
> advanced implementation of WikiMacros and it's possible already to use
> the later together with WikiProcessors then I don't see a reason for
> not having WikiMacro installed .
>
> > I'll avoid advocating a particular decision too early as it would be
> > good to get some opinions and you may be able to change my mind on this
> > issue.
> >
>
> Simple use case . We have two tables listing the results of ticket
> queries in BloodhoundContributing and BEP 3 wiki pages . Nonetheless
> we cannot embed our own version in there and are forced to reuse
> TicketQuery macro. It'd be nice to make it look like the widget we
> already use in the dashboard . That's what WikiMacro is for ... among
> many other things .
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>

Re: widget macros (ticket #138)

[Olemis Lang <ol...@gmail.com>]

On 11/15/12, Gary Martin <ga...@wandisco.com> wrote:
> Hi,
>

:)

> We have an old work item that appears not to have been discussed here.
> For some reason it was considered controversial so I thought I would
> bring it up here in order to decide how far to take it.
>

Thanks for restarting the discussion once again.

[...]
>
> Effectively this would provide the ability for users to create their own
> dashboards - whether or not that is what we want to see is an
> interesting question,

... even if users could do this I wonder whether this is a strong
reason for not including WidgetMacro .

> but it seems more likely that people would just
> make use of them on a more ad hoc basis.
>

Exactly the macro serves to many other purposes . If widgets are and
advanced implementation of WikiMacros and it's possible already to use
the later together with WikiProcessors then I don't see a reason for
not having WikiMacro installed .

> I'll avoid advocating a particular decision too early as it would be
> good to get some opinions and you may be able to change my mind on this
> issue.
>

Simple use case . We have two tables listing the results of ticket
queries in BloodhoundContributing and BEP 3 wiki pages . Nonetheless
we cannot embed our own version in there and are forced to reuse
TicketQuery macro. It'd be nice to make it look like the widget we
already use in the dashboard . That's what WikiMacro is for ... among
many other things .

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article: