- We should all be focusing on getting our screencasts ready to go
- There was not really anything else that we went over as a group, Steve and Crystal worked with David to figure out some issues with their second projects
- Successfully created a sub-repository for generating & uploading diffs to the test repositories
- Currently able to upload diffs
- Started to work on adding diff comments
- Get diff comments to successfully complete
- Polish up fill-database.py script for final critique
- Modify script based on feedback
- not entirely sure on the proper method of gaining handles to required areas (ie: no FileDiff handle or ReviewRequests->Review handle, etc) and creating appropriate relations between the objects
- Updated the banner review request with new JS to keep the banner in
- Write some better tests for the git patch
- Figuring out the best way to tell if the banner is in the box or not
- as is turns out, looking at the container is easier than looking at
- Have implemented a template loader to load specially named templates
- the template loader is linked into the settings and actually loads templates with _extension as the end of the regular template name
- figure out how to fix the infinite loading problem (see roadblocks)
- document how to extend a template
- keep working on breaking the templates into components
- infinite loading – the way the template loaders work they run in a specific order, so if the customized loader always runs first and looks for name_extension then when the extended template has to load name (because it extends it) it ends up loading itself again
- added options for spell checking at the admin setting page
- added options in accounts’ profile
- began to read about webapi stuff, preparing to work for dictionary resources.
- get a sense of webapi and begin to work with it for spell checking
- the performance of checking is still not improved.
- forgot to switch to a new branch before a relatively new part of feature..
- Moved the ui-autocomplete-* to common.css and now the autocomplete
looks really nice. Turned out it was much more simple than I thought
- Added the line “Press tab to autocomplete” on to the list of
- Tried working on clicking on suggestion would take you to the
- Made some git mistakes and fixed them
- Continuing with the user clicking on a suggestion, it should
directly go to the object’s URL
- Should finish my feature very soon
- Not sure how to do the URL… my approach was wrong
- Added the customizable button to extension admin page
- Started to figured out how to edit the page for the customization
- Researched on hooks for various fields
- Added the correct fields to the XMLExport
- Ran into a couple of problems (see road blocks)
- Fix road blocks so I can get the code snippet functionality working
- Fix road blocks so I can edit the customize tab on the extension
- I couldn’t figure out how to edit the customize page on extension in the admin page, and none of the extensions I have installed are using the customize page either.
- I notice that the code snippet part of the current Web UI doesn’t actually show the diff, it just gives the filename->line of each. I don’t know if this is sufficient enough.
Now that I’m finally on the right track I feel like I’ve made some good progress on the extend-able themes project. I’ve got a ‘working’ template loader built – there is still one problem with the loader getting stuck in an infinite loop, but it does load the correct templates at this point. I’m pretty sure I should be able to have this project completed in early March.
- Templates (1 week)
- Finish the extension template loader (1-2 days)
- Keep breaking up templates into smaller pieces (2-4 days)
- Test & Document (1 week)
So, working on the template loader – I’m finally on the right track with this project 🙂
All seems to be going well, I have it set up to try and load the extended version before going for the default template. But, there is a small catch… when the custom template extends the default template things get a bit messy. Because of the way the loaders are set up, the loader looking for extended templates always runs first when searching for any template. So, the new template loader looks for template_name + _extended each template load… this means that each time a template is loaded the _extended version is loaded first.
This at first seems like exactly what we want, but when the extended template extends the original… well, the new loader runs first and reloads the extended template – which extends the original, so reloads the extended version using the new loader, etc. So, it gets into an infinite loop of loading the same extended template.
I’m thinking that there would be a couple of ways to fix this:
- load from a special extended templates directory structure (but this could lead to the same problem, only in a different directory)
- have a set of default templates and used templates, then only extend the defaults (the regular templates would also extend the defaults, there just would be no changes – but then why not just have defaults & extensions?)
- know what template is calling the loader and if it is requesting the same template then don’t load using the extension loader (this seems to be the best & cleanest option to me as it gets rid of the need for extra template files and solves the infinite recursion problem – now, to figure out how to do this)
- or I could do this a bit backwards, have the special template loader remove the _extended part of the template_name and change all of the url redirects to template_name_extended – but this doesn’t seem very clean, it would keep the number of files down though
- Steve – making some good progress
- Mark – hasn’t encountered any problems
- Kahlil – starting to feel more at ease with the project
- having some trouble with quick search – not working in every page
- Mengyun – noticed some slowing down with the spellchecker
- is going to try some profiling to see where the slowdown is occurring
- “you can enable profiling in admin UI->Settings->Logging, and then access a URL with ?profiling=1 appended”
- Teresa – some questions about form handlers
- turns out to be unnecessary though (the admin would be expected to just copy their template extensions into the template directory)
- No one feels completely panicky at this point
- Screen caputures
- going to be due April 8th
- its a good idea to start looking into a decent program to do this
- Also, we will all need a decent mic for the screen captures
- best to either post the video to youtube or upload it and send the url to mike so he can post it to his youtube account
- after the screen capture is posted send Mengyun the url so she can put together the screencap blog
- Projects will not likely take the entire term to complete
- let Christian, Mike, or David know if this is the case so you can figure out some other work to do
- No one has been reimbursed for the code sprint yet – Mike is looking into it
- Crystal, Khalil, Steve, and Teresa all have reviewboard project presentations for class requirements in early April
Project Milestone Plan
1 week: add in forms to the theme settings page (have this completed using charFields right now – just need to build the customized forms to swap in)
2 weeks? (I am really not sure about this one): build the color-selector form & the image selector form for the theme settings page
- Color selection component (point and click on a desired color)
- Banner image selector/loader
- Restore defaults for each editable component
- Restore all defaults option
1 week: create a model to store the default theme values and the current values (defaults if there has been no editing) & add them into the theme settings page instead of the CharFields
After that I’m not sure about time, but have a plan on how to actually implement the change in themes:
- Pull out all of the editable values from the commons.css files and create a new .css file called commons_editable.css (should not take long). Also, edit the templates to use this new .css file as well as the commons.css.
- Whenever the themes are changed (and the changes are saved) re-write the editable.css with the new current values from the models
- Will also want to make a validation system for the banner image (should we allow uploading a banner image, or just using a url?) and the color values (the user should be able to just input a hex value instead of being forced to use the color selector).
- Try to break it
- Fix problems and repeat 4-5 until I can’t break it anymore
If there is time for me to take on another small project (or if things go faster than anticipated) I can look into working on one of the extension projects (or something else).
So, I did some more work on issue 1632. I’m not sure how the order_by(sort_list) actually uses the sort list to generate the SQL code, but it seems like my initial attempt to fix the problem (adding lower() around the submitter sort_item) will not work. I took a look at the SQL code being generated with the query.query.__str__() and adding lower() to the sort list didn’t seem to change anything – it also broke reviewboard (lower(submitter) was not a valid field in the query).
I will be working on adding customizable themes by the admin as my first project for reviewboard. So, I spent the rest of the day figuring out how the .html files were actually being linked to the GUI. I managed to make a new theme tab under the admin page’s settings tab by using the storage tab’s .html template. This required adding in a new /style url to the urls.py under reviewboard/admin as well as altering the reviewboard/admin/views.py file by adding in a new class StyleSettingsForm.
I will be looking into how to actually use the django framework to populate the theme page with data and then figuring out what kind of things should be customizable/making the GUI.