Getting started on projects
22 views
Skip to first unread message
Aamir Mansoor
Oct 3, 2012, 8:32:42 PM10/3/12
to reviewbo...@googlegroups.com
Hi Mentors,
Aamir Mansoor
Now that we all are done fixing a few EasyFix bugs, I was wondering if we could get some guidance on how to get started with development on our assigned projects. I am working on Pluggable UI and have had gone through code Chris has submitted for review and was wondering what's next.
Thanks,
Sampson Chen
Oct 5, 2012, 5:08:30 PM10/5/12
to reviewbo...@googlegroups.com
Hello Mentors:
I'm in the same boat as Aamir: I have a general idea of what to do, but still fuzzy on the details of where exactly to get started on the code. Should we bug you in IRC on a case-by-case basis, or are more direction still on the way?
Cheers,
Sampson
Mike Conley
Oct 5, 2012, 5:20:12 PM10/5/12
to reviewbo...@googlegroups.com
Gotcha - these are good / important questions, will try to tackle
them this evening.
Christian Hammond
Oct 5, 2012, 7:17:09 PM10/5/12
to reviewbo...@googlegroups.com
Hi guys,
My apologies for not getting back to you on this. I'm fighting a cold and have been taking it easy the past few days.
(Btw, I go by Christian, not Chris, just fyi :)
So let's go over pluggable UIs a bit.
The basic concept is that instead of some hard-coded sets of code, templates and models for reviewing different sets of content, we introduce a new architecture for reviewing "stuff." That "stuff" can be file attachments, screenshots, or diffs, but it'd be backed by a standard interface.
The bulk of what you care about will be review UIs for specific file attachments. These are intended to be registered per-mimetype, so for example there may be a review UI for image/*, one for application/x-pdf, etc.
Right now, the very basics of this infrastructure is in. There's a FileAttachmentReviewUI class (reviewboard/reviews/ui/base.py) that you will be using as a base class for any custom review UIs.
(At the moment, there's no registration mechanism, so for any testing you do, you'll want to temporarily add an import of your ReviewUI's file in FileAttachmentReviewUI.get_best_handler, until one is added).
All comments will be stored in a FileAttachmentComment. There will soon be an extra_data field you'll be able to store any useful information (coordinates, etc.) in.
What you'll need to do is create a template file that provides the rendering of the content and loads in any custom JavaScript file that provides the review UI capability. You'll need to apply my change in /r/3342 (I'm going to try to get this committed tonight, though) and build JavaScript infrastructure on top of what's there. We use jQuery, Backbone.js and Underscore.js, so google for those and take a look at the docs and what my code in that change is doing.
As for what specifically you'll do for your review UIs, that's going to depend greatly on what review UIs you'll be making. We need a discussion on that and to figure out what realistically can be built. This will require some research into any JavaScript libraries that may be useful, possible parsing of file types, representing in HTML/JavaScript, etc. There will be plenty to learn here.
Once we know specifically what will be built, we can figure out how to build it.
Christian
--
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
My apologies for not getting back to you on this. I'm fighting a cold and have been taking it easy the past few days.
(Btw, I go by Christian, not Chris, just fyi :)
So let's go over pluggable UIs a bit.
The basic concept is that instead of some hard-coded sets of code, templates and models for reviewing different sets of content, we introduce a new architecture for reviewing "stuff." That "stuff" can be file attachments, screenshots, or diffs, but it'd be backed by a standard interface.
The bulk of what you care about will be review UIs for specific file attachments. These are intended to be registered per-mimetype, so for example there may be a review UI for image/*, one for application/x-pdf, etc.
Right now, the very basics of this infrastructure is in. There's a FileAttachmentReviewUI class (reviewboard/reviews/ui/base.py) that you will be using as a base class for any custom review UIs.
(At the moment, there's no registration mechanism, so for any testing you do, you'll want to temporarily add an import of your ReviewUI's file in FileAttachmentReviewUI.get_best_handler, until one is added).
All comments will be stored in a FileAttachmentComment. There will soon be an extra_data field you'll be able to store any useful information (coordinates, etc.) in.
What you'll need to do is create a template file that provides the rendering of the content and loads in any custom JavaScript file that provides the review UI capability. You'll need to apply my change in /r/3342 (I'm going to try to get this committed tonight, though) and build JavaScript infrastructure on top of what's there. We use jQuery, Backbone.js and Underscore.js, so google for those and take a look at the docs and what my code in that change is doing.
As for what specifically you'll do for your review UIs, that's going to depend greatly on what review UIs you'll be making. We need a discussion on that and to figure out what realistically can be built. This will require some research into any JavaScript libraries that may be useful, possible parsing of file types, representing in HTML/JavaScript, etc. There will be plenty to learn here.
Once we know specifically what will be built, we can figure out how to build it.
Christian
--
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
Mike Conley
Oct 6, 2012, 1:30:17 AM10/6/12
to reviewbo...@googlegroups.com
Sampson:
Regarding the thumbnails project - a student worked on getting the
infrastructure for the thumbnail renderers up and running a few
semesters back. Here's the current state of the code:
https://github.com/reviewboard/reviewboard/blob/master/reviewboard/attachments/mimetypes.py#L131
And, for reference, here's the review for when that code landed:
http://reviews.reviewboard.org/r/2967/
There's a generic base class, and then a method you can override to
generate the thumbnails. I guess you'll be adding more of these classes.
Some file types to consider, in case you haven't already been given any:
* PDF
* Microsoft Word's DOC / .DOCX
There are probably more, but I can't think of any right now.
Does this give you a place to start?
-Mike
> <http://aam1r.com?utm_source=gmail&utm_medium=email_signature&utm_campaign=me%40aam1r.com>
>
>
--
http://www.mikeconley.ca
Regarding the thumbnails project - a student worked on getting the
infrastructure for the thumbnail renderers up and running a few
semesters back. Here's the current state of the code:
https://github.com/reviewboard/reviewboard/blob/master/reviewboard/attachments/mimetypes.py#L131
And, for reference, here's the review for when that code landed:
http://reviews.reviewboard.org/r/2967/
There's a generic base class, and then a method you can override to
generate the thumbnails. I guess you'll be adding more of these classes.
Some file types to consider, in case you haven't already been given any:
* Microsoft Word's DOC / .DOCX
There are probably more, but I can't think of any right now.
Does this give you a place to start?
-Mike
>
>
--
http://www.mikeconley.ca
Sampson Chen
Oct 6, 2012, 8:53:24 AM10/6/12
to reviewbo...@googlegroups.com
Hey Mike:
That actually helps quite a bit, thanks! I'll bring any more questions I run into to the meeting tomorrow =)
Cheers,
Sampson
On Sat, Oct 6, 2012 at 1:30 AM, Mike Conley <mike.d...@gmail.com> wrote:
Sampson:
Regarding the thumbnails project - a student worked on getting the infrastructure for the thumbnail renderers up and running a few semesters back. Here's the current state of the code:
Reply all
Reply to author
Forward
0 new messages