You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Peter Koželj <pe...@digiverse.si> on 2012/09/19 11:52:16 UTC
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
There are two ways we can do this.
1. We can add a "show_paginator" argument to the TicketQueryWidget and set
it to False for every widget instance on dashboard.
The plus side is that this leaves as with the option to have both style
instances of the widget.
The negative side is that we keep some dead code if we never use the
option with shown paginator.
2. The simple solution is to simply remove the pagination stuff from the
widget_grid.html.
As far as I can tell, the widget is not used outside the dashboard
anyway.
Peter
On Tue, Sep 18, 2012 at 1:18 PM, Apache Bloodhound <
bloodhound-dev@incubator.apache.org> wrote:
> #187: Remove row count and results pagination from Dashboard
> --------------------------+----------------------
> Reporter: jdreimann | Owner: peter
> Type: enhancement | Status: assigned
> Priority: minor | Milestone:
> Component: dashboard | Version:
> Resolution: | Keywords:
> --------------------------+----------------------
> Changes (by gjm):
>
> * status: new => assigned
> * owner: nobody => peter
>
>
> --
> Ticket URL: <https://issues.apache.org/bloodhound/ticket/187#comment:3>
> Apache Bloodhound <https://issues.apache.org/bloodhound/>
> The Apache Bloodhound (incubating) issue tracker
>
Patch submissions (Was: Re: [Apache Bloodhound] #187: Remove row
count and results pagination from Dashboard)
Posted by Gary Martin <ga...@wandisco.com>.
On 19/09/12 19:38, Olemis Lang wrote:
> About patches . I have the habit of including them in one of two forms
>
> 1.
>
> {{{
> #!diff
>
> <patch contents>
>
> }}}
>
> 2. Attachment having a name of the form
> t<ticket_number>_r<changeset_id>_<descriptive_name>.diff
>
> both ticket number and changeset ID are useful to know whether the
> patch needs to be updated before applying it , and also to tag the
> exact version modifications were tested against . This is a practice
> inherited from Trac-dev itself so we might just include a link to
> their patch submission guidelines wiki page or start from there and
> customize it for our own usage .
I think that attachment naming is more about whatever makes it easy for
the person who produces the patch. A description of the patch in a
comment is almost always useful and specification of the revision that
the patch was developed against is a very good idea. If these happen to
be a part of the file name instead of a comment (or in addition to),
that should be considered fine too.
All I would care about is that the information is available, correct and
understandable rather than the precise form. Maybe I will care more
about this later of course.
I can check out the Trac guidelines but we need our own page. PEP 8
(http://www.python.org/dev/peps/pep-0008/) is obviously an appropriate
Python style guide for instance. I understand that Trac frown upon
deviations from this so anything that we want to contribute back to Trac
should be vetted carefully. It remains to be seen how strict I will turn
out to be on enforcing this style. I don't believe it always pays off to
be overly strict and in the end, code readability wins.
Anyway, I should be putting all this and more into a wiki page as Brane
suggested.
Cheers,
Gary
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Olemis Lang <ol...@gmail.com>.
On 9/21/12, Gary Martin <ga...@wandisco.com> wrote:
> On 09/20/2012 02:57 PM, Olemis Lang wrote:
>> On 9/20/12, Olemis Lang <ol...@gmail.com> wrote:
>>> On 9/19/12, Gary Martin <ga...@wandisco.com> wrote:
>>>> On 19/09/12 19:38, Olemis Lang wrote:
>>>>> hmmm ... I'm hoping any of my previous comments be considered . IMO we
>>>>> shall not remove pagination . AFAICR there's an option for that ...
>>>>>
>>>>> AFAICR in #80 I submitted a patch (... pending or already committed I
>>>>> don't recall now ...) adding options to render Bootstrap pagination in
>>>>> reports web page and built-in smaller pagination in widgets
>>>>> (considering Joachim's suggestion ;) . Maybe we can follow a bit
>>>>> further and parameterize page index visibility in query and report
>>>>> widgets on top of the work made in there ...
>>>> Well, it is entirely possible that I have missed the scope over which
>>>> these changes apply. Do we have widgets where a change of page updates
>>>> the content of the widget itself?
>>> so far we don't . But I was considering this to be the case in the
>>> future .
>> ... considering Joachim's suggestions . I mean Edit and List buttons
>> included in widget header in mockups e.g. [1]_
>>
>> .. [1] MultiSite - Apache Bloodhound
>>
>> (http://svn.apache.org/repos/asf/incubator/bloodhound/trunk/doc/html-templates/product.html)
>>
>
> It looks to me like #80 does not provide all that much other than a
> change from trac defaults in pagination to bootstrap.
It also adds the possibility to use any pagination we decide in
widget_grid.html , and as a special case , remove it .
> It doesn't look
> like this change has been agreed to because there was a feeling that the
> pagination was a bit too intrusive too.
What was agreed once upon a time was to insert Bootstrap pagination in
web pages e.g. report view and legacy smaller pagination in widget .
> That means that all I can do
> with that ticket is move the template to the new suggested location.
>
I'll take a look once again , it's just that I don't have those
patches in my local MQ repos
:-/
> Meanwhile, I am not sure how the edit and list buttons are relevant to
> this part of the discussion
If a data is added or modified then the widget has to be refreshed via
AJAX ... if that happens , as a side effect it should be possible to
load query results incrementally without leaving the web page .
> although I suppose could be better ways of
> suggesting what the "more" link is for.. maybe.
>
¿?
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Gary Martin <ga...@wandisco.com>.
On 09/20/2012 02:57 PM, Olemis Lang wrote:
> On 9/20/12, Olemis Lang <ol...@gmail.com> wrote:
>> On 9/19/12, Gary Martin <ga...@wandisco.com> wrote:
>>> On 19/09/12 19:38, Olemis Lang wrote:
>>>> hmmm ... I'm hoping any of my previous comments be considered . IMO we
>>>> shall not remove pagination . AFAICR there's an option for that ...
>>>>
>>>> AFAICR in #80 I submitted a patch (... pending or already committed I
>>>> don't recall now ...) adding options to render Bootstrap pagination in
>>>> reports web page and built-in smaller pagination in widgets
>>>> (considering Joachim's suggestion ;) . Maybe we can follow a bit
>>>> further and parameterize page index visibility in query and report
>>>> widgets on top of the work made in there ...
>>> Well, it is entirely possible that I have missed the scope over which
>>> these changes apply. Do we have widgets where a change of page updates
>>> the content of the widget itself?
>> so far we don't . But I was considering this to be the case in the
>> future .
> ... considering Joachim's suggestions . I mean Edit and List buttons
> included in widget header in mockups e.g. [1]_
>
> .. [1] MultiSite - Apache Bloodhound
> (http://svn.apache.org/repos/asf/incubator/bloodhound/trunk/doc/html-templates/product.html)
>
It looks to me like #80 does not provide all that much other than a
change from trac defaults in pagination to bootstrap. It doesn't look
like this change has been agreed to because there was a feeling that the
pagination was a bit too intrusive too. That means that all I can do
with that ticket is move the template to the new suggested location.
Meanwhile, I am not sure how the edit and list buttons are relevant to
this part of the discussion although I suppose could be better ways of
suggesting what the "more" link is for.. maybe.
Cheers,
Gary
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Olemis Lang <ol...@gmail.com>.
On 9/20/12, Olemis Lang <ol...@gmail.com> wrote:
> On 9/19/12, Gary Martin <ga...@wandisco.com> wrote:
>> On 19/09/12 19:38, Olemis Lang wrote:
>>> On 9/19/12, Gary Martin <ga...@wandisco.com> wrote:
>>>> Interesting. In that case, I will suggest that we always attach patches
>>>> to tickets and refer to them as you have done here. For the smallest of
>>>> patches, you can also choose to paste the text directly into an email -
>>>> or indeed into a ticket comment as I did recently for #204. I will put
>>>> this into a wiki page shortly.
>>>>
>>>> As for the patch, it looks like good work to me. Unless anyone else
>>>> notices any problems I expect to commit it a bit later tonight.
>>>>
>>> hmmm ... I'm hoping any of my previous comments be considered . IMO we
>>> shall not remove pagination . AFAICR there's an option for that ...
>>>
>>> AFAICR in #80 I submitted a patch (... pending or already committed I
>>> don't recall now ...) adding options to render Bootstrap pagination in
>>> reports web page and built-in smaller pagination in widgets
>>> (considering Joachim's suggestion ;) . Maybe we can follow a bit
>>> further and parameterize page index visibility in query and report
>>> widgets on top of the work made in there ...
>>
>> Well, it is entirely possible that I have missed the scope over which
>> these changes apply. Do we have widgets where a change of page updates
>> the content of the widget itself?
>
> so far we don't . But I was considering this to be the case in the
> future .
... considering Joachim's suggestions . I mean Edit and List buttons
included in widget header in mockups e.g. [1]_
.. [1] MultiSite - Apache Bloodhound
(http://svn.apache.org/repos/asf/incubator/bloodhound/trunk/doc/html-templates/product.html)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Olemis Lang <ol...@gmail.com>.
On 9/19/12, Gary Martin <ga...@wandisco.com> wrote:
> On 19/09/12 19:38, Olemis Lang wrote:
>> On 9/19/12, Gary Martin <ga...@wandisco.com> wrote:
>>> Interesting. In that case, I will suggest that we always attach patches
>>> to tickets and refer to them as you have done here. For the smallest of
>>> patches, you can also choose to paste the text directly into an email -
>>> or indeed into a ticket comment as I did recently for #204. I will put
>>> this into a wiki page shortly.
>>>
>>> As for the patch, it looks like good work to me. Unless anyone else
>>> notices any problems I expect to commit it a bit later tonight.
>>>
>> hmmm ... I'm hoping any of my previous comments be considered . IMO we
>> shall not remove pagination . AFAICR there's an option for that ...
>>
>> AFAICR in #80 I submitted a patch (... pending or already committed I
>> don't recall now ...) adding options to render Bootstrap pagination in
>> reports web page and built-in smaller pagination in widgets
>> (considering Joachim's suggestion ;) . Maybe we can follow a bit
>> further and parameterize page index visibility in query and report
>> widgets on top of the work made in there ...
>
> Well, it is entirely possible that I have missed the scope over which
> these changes apply. Do we have widgets where a change of page updates
> the content of the widget itself?
so far we don't . But I was considering this to be the case in the
future . That's why I parameterized pagination template to use in
widget_grid.html . I have to review that patch for further details .
But in general I recall I added a variable containing pagination
template name and render it somehow like
<xi:include href="$pagination_template" />
the following cases (and many more) would be possible
1. legacy small pagination (page_index.html)
2. Bootstrap pagination (bh_page_index.html)
3. In the near future use paginator for AJAX updates
... IMO we should be updating that patch and update include tag
somehow like this
<xi:include href="$pagination_template" py:if="pagination_template" />
omitting that value when rendering widget_grid.html will remove it .
But IMO patches for #80 should be at least reviewed and perhaps
committed . There's another feature added in there as well and it is
that pagination is moved to the bottom , among other things I don't
quite recall now without reviewing it once again
;)
> If this is the case, I would expect to
> keep the pagination. If it is not the case, I would not expect us to
> enhance the widgets to do that quite yet and so I would consider
> removing the pagination, reverting once there is the need again (code is
> never really lost after all). On the other hand, perhaps there is some
> use for pagination that I have not considered.
>
yes , we may remove pagination for now , and that's ok for dashboard .
I personally prefer to add an option to the widget and propagate that
value until it gets to the right Genshi template , because widget may
be used in other contexts as well , and template is reused to render
other data , not just reports , queries ... but any tabular data . So
> Whichever way these things turn out, I will delay applying the patch for
> the moment to investigate further.
>
Thanks . But I'll say that work is on the right track . It's obvious
that the whole idea of widgets and interactions with templates has
been understood .
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Gary Martin <ga...@wandisco.com>.
On 19/09/12 19:38, Olemis Lang wrote:
> On 9/19/12, Gary Martin <ga...@wandisco.com> wrote:
>> Interesting. In that case, I will suggest that we always attach patches
>> to tickets and refer to them as you have done here. For the smallest of
>> patches, you can also choose to paste the text directly into an email -
>> or indeed into a ticket comment as I did recently for #204. I will put
>> this into a wiki page shortly.
>>
>> As for the patch, it looks like good work to me. Unless anyone else
>> notices any problems I expect to commit it a bit later tonight.
>>
> hmmm ... I'm hoping any of my previous comments be considered . IMO we
> shall not remove pagination . AFAICR there's an option for that ...
>
> AFAICR in #80 I submitted a patch (... pending or already committed I
> don't recall now ...) adding options to render Bootstrap pagination in
> reports web page and built-in smaller pagination in widgets
> (considering Joachim's suggestion ;) . Maybe we can follow a bit
> further and parameterize page index visibility in query and report
> widgets on top of the work made in there ...
Well, it is entirely possible that I have missed the scope over which
these changes apply. Do we have widgets where a change of page updates
the content of the widget itself? If this is the case, I would expect to
keep the pagination. If it is not the case, I would not expect us to
enhance the widgets to do that quite yet and so I would consider
removing the pagination, reverting once there is the need again (code is
never really lost after all). On the other hand, perhaps there is some
use for pagination that I have not considered.
Whichever way these things turn out, I will delay applying the patch for
the moment to investigate further.
Cheers,
Gary
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Olemis Lang <ol...@gmail.com>.
On 9/19/12, Gary Martin <ga...@wandisco.com> wrote:
> Interesting. In that case, I will suggest that we always attach patches
> to tickets and refer to them as you have done here. For the smallest of
> patches, you can also choose to paste the text directly into an email -
> or indeed into a ticket comment as I did recently for #204. I will put
> this into a wiki page shortly.
>
> As for the patch, it looks like good work to me. Unless anyone else
> notices any problems I expect to commit it a bit later tonight.
>
hmmm ... I'm hoping any of my previous comments be considered . IMO we
shall not remove pagination . AFAICR there's an option for that ...
AFAICR in #80 I submitted a patch (... pending or already committed I
don't recall now ...) adding options to render Bootstrap pagination in
reports web page and built-in smaller pagination in widgets
(considering Joachim's suggestion ;) . Maybe we can follow a bit
further and parameterize page index visibility in query and report
widgets on top of the work made in there ...
About patches . I have the habit of including them in one of two forms
1.
{{{
#!diff
<patch contents>
}}}
2. Attachment having a name of the form
t<ticket_number>_r<changeset_id>_<descriptive_name>.diff
both ticket number and changeset ID are useful to know whether the
patch needs to be updated before applying it , and also to tag the
exact version modifications were tested against . This is a practice
inherited from Trac-dev itself so we might just include a link to
their patch submission guidelines wiki page or start from there and
customize it for our own usage .
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Gary Martin <ga...@wandisco.com>.
Interesting. In that case, I will suggest that we always attach patches
to tickets and refer to them as you have done here. For the smallest of
patches, you can also choose to paste the text directly into an email -
or indeed into a ticket comment as I did recently for #204. I will put
this into a wiki page shortly.
As for the patch, it looks like good work to me. Unless anyone else
notices any problems I expect to commit it a bit later tonight.
Meanwhile Peter, if you were happy with all that, I can't see a problem
with you taking on another ticket if you want to and you have time. I'd
be happy to try to suggest one but you should feel free to look through
the list Joe created at
https://issues.apache.org/bloodhound/wiki/BloodhoundContributing and
assign yourself one you think would be interesting.
Cheers,
Gary
On 09/19/2012 04:12 PM, Peter Koželj wrote:
> So, it seems that my attached patch got stripped.
>
> I have now added it to the ticket itself:
> https://issues.apache.org/bloodhound/attachment/ticket/187/ticket-187.diff
>
> Cheers,
> Peter
>
> On Wed, Sep 19, 2012 at 2:03 PM, Peter Koželj <pe...@digiverse.si> wrote:
>
>> Hi,
>>
>> attached is a patch that I am proposing. It removes the paginator but
>> leaves the total ticket number as is.
>> Any changes to the "More" link and total tickets number should probably be
>> addressed separately.
>>
>> Peter
>>
>> On Wed, Sep 19, 2012 at 1:47 PM, Joachim Dreimann <
>> joachim.dreimann@wandisco.com> wrote:
>>
>>> I agree with displaying the total number - the More link could show "32
>>> More" for example to indicate how many more tickets there will be.
>>> Alternatively we could show something like:
>>>
>>> More 42 Total
>>>
>>> I believe we should always show the more link though, not just
>>> conditionally. It stands not just for 'more tickets', but also represents
>>> 'more query options', 'more filtering' etc - functionality that we may not
>>> want to duplicate on the Dashboard, and at least won't in the short term.
>>>
>>> Cheers,
>>> Joe
>>>
>>> On 19 Sep 2012, at 12:22, Gary Martin <ga...@wandisco.com> wrote:
>>>
>>>> I agree that a user might want to know the total number of tickets that
>>> are matching the query. I have not seen that feature in any mock-ups
>>> though. As it was Joe's request, I hope he might comment on this aspect.
>>>> Meanwhile thanks for the note about the "More" link. Discussions of
>>> this may overlap a little with #190 which Jure is looking at. On the other
>>> hand, I don't think that point is covered by #190 so I would probably
>>> encourage you to raise a new ticket.
>>>> As for a possible answer to it: I don't suppose it would be missed if
>>> the "More" link was shown conditionally. Although it could be considered
>>> useful as a link to the appropriate query, the alternative of changing the
>>> link text may just be confusing.
>>>> Cheers,
>>>> Gary
>>>>
>>>>
>>>> On 09/19/2012 11:26 AM, Peter Koželj wrote:
>>>>> I'll just remove it then.
>>>>>
>>>>> Another question: The task says we should remove total ticket number as
>>>>> well. Is that correct?
>>>>> Information about a number of all tickets seem useful.
>>>>>
>>>>> And a note: Should the "More" link really be there when there is less
>>> than
>>>>> max number of tickets?
>>>>>
>>>>> Cheers,
>>>>> Peter
>>>>>
>>>>> On Wed, Sep 19, 2012 at 12:03 PM, Gary Martin <
>>> gary.martin@wandisco.com>wrote:
>>>>>> If there is a way for the paginator to make sense we could consider
>>>>>> keeping the code. I think it would only make sense if it updated the
>>>>>> tickets shown on the same page but it is not clear that we want that
>>> at the
>>>>>> moment.
>>>>>>
>>>>>> I would lean towards the second option. Although it might be
>>> annoying, it
>>>>>> could always be reverted and adapted to a future behaviour.
>>>>>>
>>>>>> Cheers,
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 09/19/2012 10:52 AM, Peter Koželj wrote:
>>>>>>
>>>>>>> There are two ways we can do this.
>>>>>>>
>>>>>>> 1. We can add a "show_paginator" argument to the TicketQueryWidget
>>> and set
>>>>>>> it to False for every widget instance on dashboard.
>>>>>>> The plus side is that this leaves as with the option to have both
>>>>>>> style
>>>>>>> instances of the widget.
>>>>>>> The negative side is that we keep some dead code if we never use
>>> the
>>>>>>> option with shown paginator.
>>>>>>>
>>>>>>> 2. The simple solution is to simply remove the pagination stuff from
>>> the
>>>>>>> widget_grid.html.
>>>>>>> As far as I can tell, the widget is not used outside the
>>> dashboard
>>>>>>> anyway.
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>>> On Tue, Sep 18, 2012 at 1:18 PM, Apache Bloodhound <
>>>>>>> bloodhound-dev@incubator.**apache.org<
>>> bloodhound-dev@incubator.apache.org>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> #187: Remove row count and results pagination from Dashboard
>>>>>>>> --------------------------+---**-------------------
>>>>>>>> Reporter: jdreimann | Owner: peter
>>>>>>>> Type: enhancement | Status: assigned
>>>>>>>> Priority: minor | Milestone:
>>>>>>>> Component: dashboard | Version:
>>>>>>>> Resolution: | Keywords:
>>>>>>>> --------------------------+---**-------------------
>>>>>>>> Changes (by gjm):
>>>>>>>>
>>>>>>>> * status: new => assigned
>>>>>>>> * owner: nobody => peter
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Ticket URL: <
>>> https://issues.apache.org/**bloodhound/ticket/187#comment:*
>>>>>>>> *3 <https://issues.apache.org/bloodhound/ticket/187#comment:3>>
>>>>>>>> Apache Bloodhound <https://issues.apache.org/**bloodhound/<
>>> https://issues.apache.org/bloodhound/>
>>>>>>>> The Apache Bloodhound (incubating) issue tracker
>>>>>>>>
>>>>>>>>
>>>
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Peter Koželj <pe...@digiverse.si>.
So, it seems that my attached patch got stripped.
I have now added it to the ticket itself:
https://issues.apache.org/bloodhound/attachment/ticket/187/ticket-187.diff
Cheers,
Peter
On Wed, Sep 19, 2012 at 2:03 PM, Peter Koželj <pe...@digiverse.si> wrote:
> Hi,
>
> attached is a patch that I am proposing. It removes the paginator but
> leaves the total ticket number as is.
> Any changes to the "More" link and total tickets number should probably be
> addressed separately.
>
> Peter
>
> On Wed, Sep 19, 2012 at 1:47 PM, Joachim Dreimann <
> joachim.dreimann@wandisco.com> wrote:
>
>> I agree with displaying the total number - the More link could show "32
>> More" for example to indicate how many more tickets there will be.
>> Alternatively we could show something like:
>>
>> More 42 Total
>>
>> I believe we should always show the more link though, not just
>> conditionally. It stands not just for 'more tickets', but also represents
>> 'more query options', 'more filtering' etc - functionality that we may not
>> want to duplicate on the Dashboard, and at least won't in the short term.
>>
>> Cheers,
>> Joe
>>
>> On 19 Sep 2012, at 12:22, Gary Martin <ga...@wandisco.com> wrote:
>>
>> > I agree that a user might want to know the total number of tickets that
>> are matching the query. I have not seen that feature in any mock-ups
>> though. As it was Joe's request, I hope he might comment on this aspect.
>> >
>> > Meanwhile thanks for the note about the "More" link. Discussions of
>> this may overlap a little with #190 which Jure is looking at. On the other
>> hand, I don't think that point is covered by #190 so I would probably
>> encourage you to raise a new ticket.
>> >
>> > As for a possible answer to it: I don't suppose it would be missed if
>> the "More" link was shown conditionally. Although it could be considered
>> useful as a link to the appropriate query, the alternative of changing the
>> link text may just be confusing.
>> >
>> > Cheers,
>> > Gary
>> >
>> >
>> > On 09/19/2012 11:26 AM, Peter Koželj wrote:
>> >> I'll just remove it then.
>> >>
>> >> Another question: The task says we should remove total ticket number as
>> >> well. Is that correct?
>> >> Information about a number of all tickets seem useful.
>> >>
>> >> And a note: Should the "More" link really be there when there is less
>> than
>> >> max number of tickets?
>> >>
>> >> Cheers,
>> >> Peter
>> >>
>> >> On Wed, Sep 19, 2012 at 12:03 PM, Gary Martin <
>> gary.martin@wandisco.com>wrote:
>> >>
>> >>> If there is a way for the paginator to make sense we could consider
>> >>> keeping the code. I think it would only make sense if it updated the
>> >>> tickets shown on the same page but it is not clear that we want that
>> at the
>> >>> moment.
>> >>>
>> >>> I would lean towards the second option. Although it might be
>> annoying, it
>> >>> could always be reverted and adapted to a future behaviour.
>> >>>
>> >>> Cheers,
>> >>> Gary
>> >>>
>> >>>
>> >>>
>> >>> On 09/19/2012 10:52 AM, Peter Koželj wrote:
>> >>>
>> >>>> There are two ways we can do this.
>> >>>>
>> >>>> 1. We can add a "show_paginator" argument to the TicketQueryWidget
>> and set
>> >>>> it to False for every widget instance on dashboard.
>> >>>> The plus side is that this leaves as with the option to have both
>> >>>> style
>> >>>> instances of the widget.
>> >>>> The negative side is that we keep some dead code if we never use
>> the
>> >>>> option with shown paginator.
>> >>>>
>> >>>> 2. The simple solution is to simply remove the pagination stuff from
>> the
>> >>>> widget_grid.html.
>> >>>> As far as I can tell, the widget is not used outside the
>> dashboard
>> >>>> anyway.
>> >>>>
>> >>>> Peter
>> >>>>
>> >>>> On Tue, Sep 18, 2012 at 1:18 PM, Apache Bloodhound <
>> >>>> bloodhound-dev@incubator.**apache.org<
>> bloodhound-dev@incubator.apache.org>>
>> >>>> wrote:
>> >>>>
>> >>>> #187: Remove row count and results pagination from Dashboard
>> >>>>> --------------------------+---**-------------------
>> >>>>> Reporter: jdreimann | Owner: peter
>> >>>>> Type: enhancement | Status: assigned
>> >>>>> Priority: minor | Milestone:
>> >>>>> Component: dashboard | Version:
>> >>>>> Resolution: | Keywords:
>> >>>>> --------------------------+---**-------------------
>> >>>>> Changes (by gjm):
>> >>>>>
>> >>>>> * status: new => assigned
>> >>>>> * owner: nobody => peter
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Ticket URL: <
>> https://issues.apache.org/**bloodhound/ticket/187#comment:*
>> >>>>> *3 <https://issues.apache.org/bloodhound/ticket/187#comment:3>>
>> >>>>> Apache Bloodhound <https://issues.apache.org/**bloodhound/<
>> https://issues.apache.org/bloodhound/>
>> >>>>> The Apache Bloodhound (incubating) issue tracker
>> >>>>>
>> >>>>>
>> >
>>
>>
>
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Peter Koželj <pe...@digiverse.si>.
Hi,
attached is a patch that I am proposing. It removes the paginator but
leaves the total ticket number as is.
Any changes to the "More" link and total tickets number should probably be
addressed separately.
Peter
On Wed, Sep 19, 2012 at 1:47 PM, Joachim Dreimann <
joachim.dreimann@wandisco.com> wrote:
> I agree with displaying the total number - the More link could show "32
> More" for example to indicate how many more tickets there will be.
> Alternatively we could show something like:
>
> More 42 Total
>
> I believe we should always show the more link though, not just
> conditionally. It stands not just for 'more tickets', but also represents
> 'more query options', 'more filtering' etc - functionality that we may not
> want to duplicate on the Dashboard, and at least won't in the short term.
>
> Cheers,
> Joe
>
> On 19 Sep 2012, at 12:22, Gary Martin <ga...@wandisco.com> wrote:
>
> > I agree that a user might want to know the total number of tickets that
> are matching the query. I have not seen that feature in any mock-ups
> though. As it was Joe's request, I hope he might comment on this aspect.
> >
> > Meanwhile thanks for the note about the "More" link. Discussions of this
> may overlap a little with #190 which Jure is looking at. On the other hand,
> I don't think that point is covered by #190 so I would probably encourage
> you to raise a new ticket.
> >
> > As for a possible answer to it: I don't suppose it would be missed if
> the "More" link was shown conditionally. Although it could be considered
> useful as a link to the appropriate query, the alternative of changing the
> link text may just be confusing.
> >
> > Cheers,
> > Gary
> >
> >
> > On 09/19/2012 11:26 AM, Peter Koželj wrote:
> >> I'll just remove it then.
> >>
> >> Another question: The task says we should remove total ticket number as
> >> well. Is that correct?
> >> Information about a number of all tickets seem useful.
> >>
> >> And a note: Should the "More" link really be there when there is less
> than
> >> max number of tickets?
> >>
> >> Cheers,
> >> Peter
> >>
> >> On Wed, Sep 19, 2012 at 12:03 PM, Gary Martin <gary.martin@wandisco.com
> >wrote:
> >>
> >>> If there is a way for the paginator to make sense we could consider
> >>> keeping the code. I think it would only make sense if it updated the
> >>> tickets shown on the same page but it is not clear that we want that
> at the
> >>> moment.
> >>>
> >>> I would lean towards the second option. Although it might be annoying,
> it
> >>> could always be reverted and adapted to a future behaviour.
> >>>
> >>> Cheers,
> >>> Gary
> >>>
> >>>
> >>>
> >>> On 09/19/2012 10:52 AM, Peter Koželj wrote:
> >>>
> >>>> There are two ways we can do this.
> >>>>
> >>>> 1. We can add a "show_paginator" argument to the TicketQueryWidget
> and set
> >>>> it to False for every widget instance on dashboard.
> >>>> The plus side is that this leaves as with the option to have both
> >>>> style
> >>>> instances of the widget.
> >>>> The negative side is that we keep some dead code if we never use
> the
> >>>> option with shown paginator.
> >>>>
> >>>> 2. The simple solution is to simply remove the pagination stuff from
> the
> >>>> widget_grid.html.
> >>>> As far as I can tell, the widget is not used outside the
> dashboard
> >>>> anyway.
> >>>>
> >>>> Peter
> >>>>
> >>>> On Tue, Sep 18, 2012 at 1:18 PM, Apache Bloodhound <
> >>>> bloodhound-dev@incubator.**apache.org<
> bloodhound-dev@incubator.apache.org>>
> >>>> wrote:
> >>>>
> >>>> #187: Remove row count and results pagination from Dashboard
> >>>>> --------------------------+---**-------------------
> >>>>> Reporter: jdreimann | Owner: peter
> >>>>> Type: enhancement | Status: assigned
> >>>>> Priority: minor | Milestone:
> >>>>> Component: dashboard | Version:
> >>>>> Resolution: | Keywords:
> >>>>> --------------------------+---**-------------------
> >>>>> Changes (by gjm):
> >>>>>
> >>>>> * status: new => assigned
> >>>>> * owner: nobody => peter
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Ticket URL: <
> https://issues.apache.org/**bloodhound/ticket/187#comment:*
> >>>>> *3 <https://issues.apache.org/bloodhound/ticket/187#comment:3>>
> >>>>> Apache Bloodhound <https://issues.apache.org/**bloodhound/<
> https://issues.apache.org/bloodhound/>
> >>>>> The Apache Bloodhound (incubating) issue tracker
> >>>>>
> >>>>>
> >
>
>
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Olemis Lang <ol...@gmail.com>.
On 9/19/12, Joachim Dreimann <jo...@wandisco.com> wrote:
> I agree with displaying the total number - the More link could show "32
> More" for example to indicate how many more tickets there will be.
> Alternatively we could show something like:
>
> More 42 Total
>
This was implemented before and removed . Before a label like «Results
34 - 46 of 256» was displayed , because , if you notice (in general)
grid template and widgets may display a page different from the first
page and number of rows may be specified as a param as well .
If u ask me I'd rather prefer that label we removed once upon a time ...
There should be some old screenshot in the issue tracker or in my
Google+ albums (<= more probable in the later ;) illustrating this .
Somewhere after a request posted somewhere ... it was removed .
> I believe we should always show the more link though, not just
> conditionally. It stands not just for 'more tickets', but also represents
> 'more query options', 'more filtering' etc - functionality that we may not
> want to duplicate on the Dashboard, and at least won't in the short term.
>
oh ! we agree then , as I mentioned in previous message
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Apache Bloodhound] #187: Remove row count and results pagination from Dashboard
Posted by Joachim Dreimann <jo...@wandisco.com>.
I agree with displaying the total number - the More link could show "32 More" for example to indicate how many more tickets there will be. Alternatively we could show something like:
More 42 Total
I believe we should always show the more link though, not just conditionally. It stands not just for 'more tickets', but also represents 'more query options', 'more filtering' etc - functionality that we may not want to duplicate on the Dashboard, and at least won't in the short term.
Cheers,
Joe
On 19 Sep 2012, at 12:22, Gary Martin <ga...@wandisco.com> wrote:
> I agree that a user might want to know the total number of tickets that are matching the query. I have not seen that feature in any mock-ups though. As it was Joe's request, I hope he might comment on this aspect.
>
> Meanwhile thanks for the note about the "More" link. Discussions of this may overlap a little with #190 which Jure is looking at. On the other hand, I don't think that point is covered by #190 so I would probably encourage you to raise a new ticket.
>
> As for a possible answer to it: I don't suppose it would be missed if the "More" link was shown conditionally. Although it could be considered useful as a link to the appropriate query, the alternative of changing the link text may just be confusing.
>
> Cheers,
> Gary
>
>
> On 09/19/2012 11:26 AM, Peter Koželj wrote:
>> I'll just remove it then.
>>
>> Another question: The task says we should remove total ticket number as
>> well. Is that correct?
>> Information about a number of all tickets seem useful.
>>
>> And a note: Should the "More" link really be there when there is less than
>> max number of tickets?
>>
>> Cheers,
>> Peter
>>
>> On Wed, Sep 19, 2012 at 12:03 PM, Gary Martin <ga...@wandisco.com>wrote:
>>
>>> If there is a way for the paginator to make sense we could consider
>>> keeping the code. I think it would only make sense if it updated the
>>> tickets shown on the same page but it is not clear that we want that at the
>>> moment.
>>>
>>> I would lean towards the second option. Although it might be annoying, it
>>> could always be reverted and adapted to a future behaviour.
>>>
>>> Cheers,
>>> Gary
>>>
>>>
>>>
>>> On 09/19/2012 10:52 AM, Peter Koželj wrote:
>>>
>>>> There are two ways we can do this.
>>>>
>>>> 1. We can add a "show_paginator" argument to the TicketQueryWidget and set
>>>> it to False for every widget instance on dashboard.
>>>> The plus side is that this leaves as with the option to have both
>>>> style
>>>> instances of the widget.
>>>> The negative side is that we keep some dead code if we never use the
>>>> option with shown paginator.
>>>>
>>>> 2. The simple solution is to simply remove the pagination stuff from the
>>>> widget_grid.html.
>>>> As far as I can tell, the widget is not used outside the dashboard
>>>> anyway.
>>>>
>>>> Peter
>>>>
>>>> On Tue, Sep 18, 2012 at 1:18 PM, Apache Bloodhound <
>>>> bloodhound-dev@incubator.**apache.org<bl...@incubator.apache.org>>
>>>> wrote:
>>>>
>>>> #187: Remove row count and results pagination from Dashboard
>>>>> --------------------------+---**-------------------
>>>>> Reporter: jdreimann | Owner: peter
>>>>> Type: enhancement | Status: assigned
>>>>> Priority: minor | Milestone:
>>>>> Component: dashboard | Version:
>>>>> Resolution: | Keywords:
>>>>> --------------------------+---**-------------------
>>>>> Changes (by gjm):
>>>>>
>>>>> * status: new => assigned
>>>>> * owner: nobody => peter
>>>>>
>>>>>
>>>>> --
>>>>> Ticket URL: <https://issues.apache.org/**bloodhound/ticket/187#comment:*
>>>>> *3 <https://issues.apache.org/bloodhound/ticket/187#comment:3>>
>>>>> Apache Bloodhound <https://issues.apache.org/**bloodhound/<https://issues.apache.org/bloodhound/>
>>>>> The Apache Bloodhound (incubating) issue tracker
>>>>>
>>>>>
>
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Gary Martin <ga...@wandisco.com>.
I agree that a user might want to know the total number of tickets that
are matching the query. I have not seen that feature in any mock-ups
though. As it was Joe's request, I hope he might comment on this aspect.
Meanwhile thanks for the note about the "More" link. Discussions of this
may overlap a little with #190 which Jure is looking at. On the other
hand, I don't think that point is covered by #190 so I would probably
encourage you to raise a new ticket.
As for a possible answer to it: I don't suppose it would be missed if
the "More" link was shown conditionally. Although it could be considered
useful as a link to the appropriate query, the alternative of changing
the link text may just be confusing.
Cheers,
Gary
On 09/19/2012 11:26 AM, Peter Koželj wrote:
> I'll just remove it then.
>
> Another question: The task says we should remove total ticket number as
> well. Is that correct?
> Information about a number of all tickets seem useful.
>
> And a note: Should the "More" link really be there when there is less than
> max number of tickets?
>
> Cheers,
> Peter
>
> On Wed, Sep 19, 2012 at 12:03 PM, Gary Martin <ga...@wandisco.com>wrote:
>
>> If there is a way for the paginator to make sense we could consider
>> keeping the code. I think it would only make sense if it updated the
>> tickets shown on the same page but it is not clear that we want that at the
>> moment.
>>
>> I would lean towards the second option. Although it might be annoying, it
>> could always be reverted and adapted to a future behaviour.
>>
>> Cheers,
>> Gary
>>
>>
>>
>> On 09/19/2012 10:52 AM, Peter Koželj wrote:
>>
>>> There are two ways we can do this.
>>>
>>> 1. We can add a "show_paginator" argument to the TicketQueryWidget and set
>>> it to False for every widget instance on dashboard.
>>> The plus side is that this leaves as with the option to have both
>>> style
>>> instances of the widget.
>>> The negative side is that we keep some dead code if we never use the
>>> option with shown paginator.
>>>
>>> 2. The simple solution is to simply remove the pagination stuff from the
>>> widget_grid.html.
>>> As far as I can tell, the widget is not used outside the dashboard
>>> anyway.
>>>
>>> Peter
>>>
>>> On Tue, Sep 18, 2012 at 1:18 PM, Apache Bloodhound <
>>> bloodhound-dev@incubator.**apache.org<bl...@incubator.apache.org>>
>>> wrote:
>>>
>>> #187: Remove row count and results pagination from Dashboard
>>>> --------------------------+---**-------------------
>>>> Reporter: jdreimann | Owner: peter
>>>> Type: enhancement | Status: assigned
>>>> Priority: minor | Milestone:
>>>> Component: dashboard | Version:
>>>> Resolution: | Keywords:
>>>> --------------------------+---**-------------------
>>>> Changes (by gjm):
>>>>
>>>> * status: new => assigned
>>>> * owner: nobody => peter
>>>>
>>>>
>>>> --
>>>> Ticket URL: <https://issues.apache.org/**bloodhound/ticket/187#comment:*
>>>> *3 <https://issues.apache.org/bloodhound/ticket/187#comment:3>>
>>>> Apache Bloodhound <https://issues.apache.org/**bloodhound/<https://issues.apache.org/bloodhound/>
>>>> The Apache Bloodhound (incubating) issue tracker
>>>>
>>>>
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Olemis Lang <ol...@gmail.com>.
On 9/19/12, Peter Koželj <pe...@digiverse.si> wrote:
> I'll just remove it then.
>
> Another question: The task says we should remove total ticket number as
> well. Is that correct?
> Information about a number of all tickets seem useful.
>
FWIW . I'd rather keep it . I agree with your last statement .
> And a note: Should the "More" link really be there when there is less than
> max number of tickets?
>
IMO yes because users might want to perform further actions ... e.g.
batch modifications ;)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Peter Koželj <pe...@digiverse.si>.
I'll just remove it then.
Another question: The task says we should remove total ticket number as
well. Is that correct?
Information about a number of all tickets seem useful.
And a note: Should the "More" link really be there when there is less than
max number of tickets?
Cheers,
Peter
On Wed, Sep 19, 2012 at 12:03 PM, Gary Martin <ga...@wandisco.com>wrote:
> If there is a way for the paginator to make sense we could consider
> keeping the code. I think it would only make sense if it updated the
> tickets shown on the same page but it is not clear that we want that at the
> moment.
>
> I would lean towards the second option. Although it might be annoying, it
> could always be reverted and adapted to a future behaviour.
>
> Cheers,
> Gary
>
>
>
> On 09/19/2012 10:52 AM, Peter Koželj wrote:
>
>> There are two ways we can do this.
>>
>> 1. We can add a "show_paginator" argument to the TicketQueryWidget and set
>> it to False for every widget instance on dashboard.
>> The plus side is that this leaves as with the option to have both
>> style
>> instances of the widget.
>> The negative side is that we keep some dead code if we never use the
>> option with shown paginator.
>>
>> 2. The simple solution is to simply remove the pagination stuff from the
>> widget_grid.html.
>> As far as I can tell, the widget is not used outside the dashboard
>> anyway.
>>
>> Peter
>>
>> On Tue, Sep 18, 2012 at 1:18 PM, Apache Bloodhound <
>> bloodhound-dev@incubator.**apache.org<bl...@incubator.apache.org>>
>> wrote:
>>
>> #187: Remove row count and results pagination from Dashboard
>>> --------------------------+---**-------------------
>>> Reporter: jdreimann | Owner: peter
>>> Type: enhancement | Status: assigned
>>> Priority: minor | Milestone:
>>> Component: dashboard | Version:
>>> Resolution: | Keywords:
>>> --------------------------+---**-------------------
>>> Changes (by gjm):
>>>
>>> * status: new => assigned
>>> * owner: nobody => peter
>>>
>>>
>>> --
>>> Ticket URL: <https://issues.apache.org/**bloodhound/ticket/187#comment:*
>>> *3 <https://issues.apache.org/bloodhound/ticket/187#comment:3>>
>>> Apache Bloodhound <https://issues.apache.org/**bloodhound/<https://issues.apache.org/bloodhound/>
>>> >
>>> The Apache Bloodhound (incubating) issue tracker
>>>
>>>
>
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Gary Martin <ga...@wandisco.com>.
If there is a way for the paginator to make sense we could consider
keeping the code. I think it would only make sense if it updated the
tickets shown on the same page but it is not clear that we want that at
the moment.
I would lean towards the second option. Although it might be annoying,
it could always be reverted and adapted to a future behaviour.
Cheers,
Gary
On 09/19/2012 10:52 AM, Peter Koželj wrote:
> There are two ways we can do this.
>
> 1. We can add a "show_paginator" argument to the TicketQueryWidget and set
> it to False for every widget instance on dashboard.
> The plus side is that this leaves as with the option to have both style
> instances of the widget.
> The negative side is that we keep some dead code if we never use the
> option with shown paginator.
>
> 2. The simple solution is to simply remove the pagination stuff from the
> widget_grid.html.
> As far as I can tell, the widget is not used outside the dashboard
> anyway.
>
> Peter
>
> On Tue, Sep 18, 2012 at 1:18 PM, Apache Bloodhound <
> bloodhound-dev@incubator.apache.org> wrote:
>
>> #187: Remove row count and results pagination from Dashboard
>> --------------------------+----------------------
>> Reporter: jdreimann | Owner: peter
>> Type: enhancement | Status: assigned
>> Priority: minor | Milestone:
>> Component: dashboard | Version:
>> Resolution: | Keywords:
>> --------------------------+----------------------
>> Changes (by gjm):
>>
>> * status: new => assigned
>> * owner: nobody => peter
>>
>>
>> --
>> Ticket URL: <https://issues.apache.org/bloodhound/ticket/187#comment:3>
>> Apache Bloodhound <https://issues.apache.org/bloodhound/>
>> The Apache Bloodhound (incubating) issue tracker
>>
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Olemis Lang <ol...@gmail.com>.
Patch looks nice . Most of it will be approved by me , except for the
changes in widget_grid.html , which need to take into consideration
the modifications submitted for #80 which allow for more flexibility
considering the fact that other pagination templates besides
page_index.html may be included .
IMO 90% of the work has been done ... congrats !
:)
On 9/20/12, Peter Koželj <pe...@digiverse.si> wrote:
> Ok, I had another go at removing the pagination.
> As described in the ticket this is now a TicketQuery option:
>
> https://issues.apache.org/bloodhound/attachment/ticket/187/ticket187_r1387089_RemovePaginatorInDashboard.diff
>
> Cheers,
> Peter
>
> On Thu, Sep 20, 2012 at 11:48 AM, Peter Koželj <pe...@digiverse.si> wrote:
>
>> The fact that the widget_grid.html is reused outside the dashboard is an
>> oversite from my part. Ouch!
>> I'll prepare a new patch with optional "hidepaginator" argument for
>> TicketQuery widget that will only be set in dashboard definition.
>>
>> Peter
>>
>> On Wed, Sep 19, 2012 at 7:47 PM, Olemis Lang <ol...@gmail.com> wrote:
>>
>>> sorry , I'm late to the party
>>> :-/
>>>
>>> On 9/19/12, Peter Koželj <pe...@digiverse.si> wrote:
>>> > There are two ways we can do this.
>>> >
>>> > 1. We can add a "show_paginator" argument to the TicketQueryWidget and
>>> set
>>> > it to False for every widget instance on dashboard.
>>> > The plus side is that this leaves as with the option to have both
>>> style
>>> > instances of the widget.
>>> > The negative side is that we keep some dead code if we never use
>>> > the
>>> > option with shown paginator.
>>> >
>>>
>>> -1
>>>
>>> > 2. The simple solution is to simply remove the pagination stuff from
>>> > the
>>> > widget_grid.html.
>>>
>>> indeed what should be done do IMO is to specify correct args to
>>> bh_page_index.html inside widget_grid.html in order to get expected
>>> behavior and remove the limit restriction .
>>>
>>> > As far as I can tell, the widget is not used outside the dashboard
>>> > anyway.
>>> >
>>>
>>> Yes , it is . That's part of the philosophy of widgets in the end :
>>> EXTREME reuse . So grids template is implemented once and reused
>>> everywhere . That template is also used to render reports and query
>>> views (<= web pages I mean) . Nonetheless widget_grid.html is not
>>> limited to those use cases . You should also be able to use it to
>>> render any kind of tabular data . At least it's designed to do so .
>>>
>>> Besides , if using WidgetMacro the widget itself can be embedded
>>> everywhere WikiFormatting is supported .
>>>
>>> ;)
>>>
>>> --
>>> Regards,
>>>
>>> Olemis.
>>>
>>> Blog ES: http://simelo-es.blogspot.com/
>>> Blog EN: http://simelo-en.blogspot.com/
>>>
>>> Featured article:
>>>
>>
>>
>
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Peter Koželj <pe...@digiverse.si>.
Ok, I had another go at removing the pagination.
As described in the ticket this is now a TicketQuery option:
https://issues.apache.org/bloodhound/attachment/ticket/187/ticket187_r1387089_RemovePaginatorInDashboard.diff
Cheers,
Peter
On Thu, Sep 20, 2012 at 11:48 AM, Peter Koželj <pe...@digiverse.si> wrote:
> The fact that the widget_grid.html is reused outside the dashboard is an
> oversite from my part. Ouch!
> I'll prepare a new patch with optional "hidepaginator" argument for
> TicketQuery widget that will only be set in dashboard definition.
>
> Peter
>
> On Wed, Sep 19, 2012 at 7:47 PM, Olemis Lang <ol...@gmail.com> wrote:
>
>> sorry , I'm late to the party
>> :-/
>>
>> On 9/19/12, Peter Koželj <pe...@digiverse.si> wrote:
>> > There are two ways we can do this.
>> >
>> > 1. We can add a "show_paginator" argument to the TicketQueryWidget and
>> set
>> > it to False for every widget instance on dashboard.
>> > The plus side is that this leaves as with the option to have both
>> style
>> > instances of the widget.
>> > The negative side is that we keep some dead code if we never use the
>> > option with shown paginator.
>> >
>>
>> -1
>>
>> > 2. The simple solution is to simply remove the pagination stuff from the
>> > widget_grid.html.
>>
>> indeed what should be done do IMO is to specify correct args to
>> bh_page_index.html inside widget_grid.html in order to get expected
>> behavior and remove the limit restriction .
>>
>> > As far as I can tell, the widget is not used outside the dashboard
>> > anyway.
>> >
>>
>> Yes , it is . That's part of the philosophy of widgets in the end :
>> EXTREME reuse . So grids template is implemented once and reused
>> everywhere . That template is also used to render reports and query
>> views (<= web pages I mean) . Nonetheless widget_grid.html is not
>> limited to those use cases . You should also be able to use it to
>> render any kind of tabular data . At least it's designed to do so .
>>
>> Besides , if using WidgetMacro the widget itself can be embedded
>> everywhere WikiFormatting is supported .
>>
>> ;)
>>
>> --
>> Regards,
>>
>> Olemis.
>>
>> Blog ES: http://simelo-es.blogspot.com/
>> Blog EN: http://simelo-en.blogspot.com/
>>
>> Featured article:
>>
>
>
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Peter Koželj <pe...@digiverse.si>.
The fact that the widget_grid.html is reused outside the dashboard is an
oversite from my part. Ouch!
I'll prepare a new patch with optional "hidepaginator" argument for
TicketQuery widget that will only be set in dashboard definition.
Peter
On Wed, Sep 19, 2012 at 7:47 PM, Olemis Lang <ol...@gmail.com> wrote:
> sorry , I'm late to the party
> :-/
>
> On 9/19/12, Peter Koželj <pe...@digiverse.si> wrote:
> > There are two ways we can do this.
> >
> > 1. We can add a "show_paginator" argument to the TicketQueryWidget and
> set
> > it to False for every widget instance on dashboard.
> > The plus side is that this leaves as with the option to have both
> style
> > instances of the widget.
> > The negative side is that we keep some dead code if we never use the
> > option with shown paginator.
> >
>
> -1
>
> > 2. The simple solution is to simply remove the pagination stuff from the
> > widget_grid.html.
>
> indeed what should be done do IMO is to specify correct args to
> bh_page_index.html inside widget_grid.html in order to get expected
> behavior and remove the limit restriction .
>
> > As far as I can tell, the widget is not used outside the dashboard
> > anyway.
> >
>
> Yes , it is . That's part of the philosophy of widgets in the end :
> EXTREME reuse . So grids template is implemented once and reused
> everywhere . That template is also used to render reports and query
> views (<= web pages I mean) . Nonetheless widget_grid.html is not
> limited to those use cases . You should also be able to use it to
> render any kind of tabular data . At least it's designed to do so .
>
> Besides , if using WidgetMacro the widget itself can be embedded
> everywhere WikiFormatting is supported .
>
> ;)
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>
Re: [Apache Bloodhound] #187: Remove row count and results pagination
from Dashboard
Posted by Olemis Lang <ol...@gmail.com>.
sorry , I'm late to the party
:-/
On 9/19/12, Peter Koželj <pe...@digiverse.si> wrote:
> There are two ways we can do this.
>
> 1. We can add a "show_paginator" argument to the TicketQueryWidget and set
> it to False for every widget instance on dashboard.
> The plus side is that this leaves as with the option to have both style
> instances of the widget.
> The negative side is that we keep some dead code if we never use the
> option with shown paginator.
>
-1
> 2. The simple solution is to simply remove the pagination stuff from the
> widget_grid.html.
indeed what should be done do IMO is to specify correct args to
bh_page_index.html inside widget_grid.html in order to get expected
behavior and remove the limit restriction .
> As far as I can tell, the widget is not used outside the dashboard
> anyway.
>
Yes , it is . That's part of the philosophy of widgets in the end :
EXTREME reuse . So grids template is implemented once and reused
everywhere . That template is also used to render reports and query
views (<= web pages I mean) . Nonetheless widget_grid.html is not
limited to those use cases . You should also be able to use it to
render any kind of tabular data . At least it's designed to do so .
Besides , if using WidgetMacro the widget itself can be embedded
everywhere WikiFormatting is supported .
;)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article: