----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/8/ -----------------------------------------------------------
Review request for blockerbugs.
Bugs: 332 https://fedorahosted.org/fedora-qa/ticket/332
Repository: blockerbugs
Description -------
Make navigation bar content loaded dynamically
Diffs -----
blockerbugs/templates/index.html 17b98b686664754de74158afb4c793e245660690 blockerbugs/templates/base_nav.html f3a89798a9dadf297e722c067ad3795a72ebbf74 blockerbugs/controllers/main.py e7525f8433d74802f7c0cb2d719f0abdc13431c4
Diff: http://reviewboard-tflink.rhcloud.com/r/8/diff/
Testing -------
Thanks,
Martin Krizek
----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/8/#review10 -----------------------------------------------------------
Code looks good to me for the most part. I realize that we've talked about g versus session for storing this data before but I'm hitting some minor issues regarding the ability of the menu bars to update.
When I start adding/removing milestones, the only way that the menu bar is updated is if I start a new browser session - this means quitting the browser and re-starting _without_ restoring the previous session. There might be a better way to force a refresh but either way, I'm not so sure about putting the refresh burden on users instead of handling it in the app.
Unfortunately, I can't think of many good ways to make this work well that don't involve an extra database query per request. One way would be to have a statically defined expiration in the session (like 1 day after initial load) and force refresh after that expiration. However, that has its own pitfalls and adds complexity - I'm not convinced this is a good idea.
I'm wondering if it wouldn't be better to go back to what you had initially and use g. It would involve extra database queries but if that becomes a problem, caching would work well to reduce server load - most of the content is relatively static (in the timeframe of sync operations, 30 minutes right now) and caching could be a good way to work around this.
- Tim Flink
On Feb. 26, 2013, 9:28 a.m., Martin Krizek wrote:
This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/8/
(Updated Feb. 26, 2013, 9:28 a.m.)
Review request for blockerbugs.
Bugs: 332 https://fedorahosted.org/fedora-qa/ticket/332
Repository: blockerbugs
Description
Make navigation bar content loaded dynamically
Diffs
blockerbugs/templates/index.html 17b98b686664754de74158afb4c793e245660690 blockerbugs/templates/base_nav.html f3a89798a9dadf297e722c067ad3795a72ebbf74 blockerbugs/controllers/main.py e7525f8433d74802f7c0cb2d719f0abdc13431c4
Diff: http://reviewboard-tflink.rhcloud.com/r/8/diff/
Testing
Thanks,
Martin Krizek
On Feb. 26, 2013, 7:15 p.m., Tim Flink wrote:
Code looks good to me for the most part. I realize that we've talked about g versus session for storing this data before but I'm hitting some minor issues regarding the ability of the menu bars to update.
When I start adding/removing milestones, the only way that the menu bar is updated is if I start a new browser session - this means quitting the browser and re-starting _without_ restoring the previous session. There might be a better way to force a refresh but either way, I'm not so sure about putting the refresh burden on users instead of handling it in the app.
Unfortunately, I can't think of many good ways to make this work well that don't involve an extra database query per request. One way would be to have a statically defined expiration in the session (like 1 day after initial load) and force refresh after that expiration. However, that has its own pitfalls and adds complexity - I'm not convinced this is a good idea.
I'm wondering if it wouldn't be better to go back to what you had initially and use g. It would involve extra database queries but if that becomes a problem, caching would work well to reduce server load - most of the content is relatively static (in the timeframe of sync operations, 30 minutes right now) and caching could be a good way to work around this.
In general, I agree. However, and please correct me if I am wrong, our use case is to put milestones into db before the testing starts (before the app is actually used by anyone). Then there is a testing period and then there is a testing break during which the session expires. And after the break we put the new milestones into db again. In this scenario I don't see the problem with refreshing the milestones. Or do we add/delete/change milestones during the testing period? Or are we planning to do that? If so, we should use the g object, otherwise, I think we're better off with session.
- Martin
----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/8/#review10 -----------------------------------------------------------
On Feb. 26, 2013, 9:28 a.m., Martin Krizek wrote:
This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/8/
(Updated Feb. 26, 2013, 9:28 a.m.)
Review request for blockerbugs.
Bugs: 332 https://fedorahosted.org/fedora-qa/ticket/332
Repository: blockerbugs
Description
Make navigation bar content loaded dynamically
Diffs
blockerbugs/templates/index.html 17b98b686664754de74158afb4c793e245660690 blockerbugs/templates/base_nav.html f3a89798a9dadf297e722c067ad3795a72ebbf74 blockerbugs/controllers/main.py e7525f8433d74802f7c0cb2d719f0abdc13431c4
Diff: http://reviewboard-tflink.rhcloud.com/r/8/diff/
Testing
Thanks,
Martin Krizek
autoqa-devel@lists.fedorahosted.org
-
Martin Krizek