incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: widget macros (ticket #138)
Date Fri, 30 Nov 2012 00:31:41 GMT
On 29/11/12 22:16, Joe Dreimann wrote:
>
>
> 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:
>>>> 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

Mime
View raw message