----- Original Message -----
From: "Nick Coghlan" <ncoghlan(a)redhat.com>
To: beaker-devel(a)lists.fedorahosted.org
Sent: Thursday, August 1, 2013 5:35:58 PM
Subject: Re: [Beaker-devel] A style guide for Beaker?
On 08/01/2013 05:18 PM, Dan Callaghan wrote:
> Excerpts from Nick Coghlan's message of 2013-08-01 17:05:01 +1000:
>> Bringing a conversation from IRC to email :)
>>
>> Currently, the dev guide has a few style hints in the "Source-code
>> walk-through" section. I had missed them because "walk-through"
really
>> doesn't suggest "style guide" to me :)
>>
>> We also have a few migrations in process that mean that existing code
>> isn't always a good guide to the style that should be used for future
>> patches, so I think it will be worth our while to spend some time
>> cleaning up this section of the dev guide.
>>
>> Firstly, I think we should retitle this section "Source components and
>> style guide". It's more than just a source code walk-through :)
>
> +1, or better yet separate them out entirely.
I agree, that would be better. If we ever have different style
recommendations for different components then we can call that out in
the style guide section, whereas embedding it in the walk-through
implies that allowing different conventions in different components is
normal, rather than only something we would allow in exceptional cases
(none of which spring to mind right now).
>> Things we should cover:
>>
>> - the migration from non-declarative to declarative SQL Alchemy models
>> - the migration from TG1 to Flask (once that is reality)
>> - the migration to using ActivityMixin for activity log updates
>> - the migration of permission checks from the view layer to the model
>> layer
>> - direction to use TG1 validators for TG1 views (what will we use for
>> Flask? Flask-WTF?)
>
> Another similar one for this list: use WebDriver and not Selenium 1.0.
Also using unittest2 for the better assertions and mock rather than
hand-rolling our own mock functionality.
Minor detail re. using unitttest2 (as a result of Dan's CR comment on a patch):
Please import it has 'import unittest2 as unittest' so that when we move to Python
2.7,
we only have to change the import statements and not the classes which subclass
unittest.TestCase.