bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: widget macros (ticket #138)
Date Thu, 29 Nov 2012 16:27:23 GMT
On 29/11/12 15:16, Olemis Lang wrote:
> On 11/29/12, Gary Martin <> wrote:
>> On 19/11/12 15:36, Olemis Lang wrote:
>>> On 11/19/12, Peter Koželj <> 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.


View raw message