On 29/11/12 22:16, Joe Dreimann wrote:
On 29 Nov 2012, at 16:27, Gary Martin <[email protected]> wrote:
On 29/11/12 15:16, Olemis Lang wrote:
On 11/29/12, Gary Martin <[email protected]> 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
