incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Dreimann <joachim.dreim...@wandisco.com>
Subject Re: widget macros (ticket #138)
Date Thu, 29 Nov 2012 22:16:30 GMT



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

> On 29/11/12 15:16, Olemis Lang wrote:
>> On 11/29/12, Gary Martin <gary.martin@wandisco.com> wrote:
>>> On 19/11/12 15:36, Olemis Lang wrote:
>>>> On 11/19/12, Peter Koželj <peter@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

Mime
View raw message