Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of joachim.dreimann@wandisco.com
 designates 74.125.82.175 as permitted sender)
Subject: Re: widget macros (ticket #138)
References: <50A51EA4.5050501@wandisco.com>
 <CAGMZAuN=92d9rggHE9QDe9sn9v1EqeCUd--+NFH44MqaNWZFWQ@mail.gmail.com>
 <CAJSKAsisiLoXckBe-hrNweVKV_obTN6H46hU8FMSLn462aLzQw@mail.gmail.com>
 <CAGMZAuNxUS_iCPSVfLLCixKR3K+HM8KVuUa=gWMME=p8945YhA@mail.gmail.com>
 <50B75F3C.2050307@wandisco.com>
 <CAGMZAuN6A4Z-w2r7rYZSOUaQNr=7qiVYGYyVMEz792+gL6REKQ@mail.gmail.com>
 <50B78CEB.8050808@wandisco.com>
From: Joe Dreimann <joachim.dreimann@wandisco.com>
Content-Type: text/plain;
	charset=utf-8
In-Reply-To: <50B78CEB.8050808@wandisco.com>
Message-Id: <4A8E4DC2-0605-4773-952A-0FDB941E2D83@wandisco.com>
Date: Thu, 29 Nov 2012 22:16:30 +0000
To: "bloodhound-dev@incubator.apache.org"
 <bloodhound-dev@incubator.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)


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=C5=BEelj <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.
>>>>=20
>>>>> I do not se any problems with this at the moment
>>>> cool
>>>>=20
>>>>> 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 ...
>>=20
>>> 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
>=20
> 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 li=
st of tickets ordered by the relevant field. It is possible that if we were t=
o put links on columns that we would want their primary action to be to orde=
r by that field with a bit of ajax.
>=20
> Interestingly [[TicketQuery(table, ?status=3D!closed&keywords=3D~starter, m=
ax=3D5)]] also seems to include the keywords field as one of the columns. Th=
at is almost certainly not the desired output for our dashboard views but I s=
uppose 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 o=
r an info/config dialogue. Anyway, we don't need to decide thy just yet.


>>=20
>>> 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>, ...)
>=20
> Well, not quite what I mean - two macros for effectively the same thing is=
 not really ideal.
>=20
> Cheers,
>    Gary