Re: [Roundup-users] Subclassing IssueClass

[Richard J. <ric...@op...>]

On Fri, Oct 8, 2010 at 2:23 AM, Bryce L Nordgren <bno...@gm...>
wrote:
>
> On Wed, Oct 6, 2010 at 6:29 PM, Richard Jones
> <ric...@op...> wrote:
>>
>> Roundup will use whatever class you use in your tracker's schema.py,
>> including any custom IssueClass you choose to use there.
>>
>
> Here is my previous assessment of this situation. Please tell me where I
> went astray:
>>
>> I attempted to subclass the IssueClass with a DiscussionClass in order to
>> modify the behavior of the nosymessage method. However, this will never
>> work, as the backends all implement the IssueClass class (and not my
>> subclass.)
>>
>> The schema.py script is executed in a controlled environment, where the
>> names of the classes available to specify the schema are defined as
follows,
>> in instance.py:
>>
>>  1         backend = self.backend
>>  2         vars = {
>>  3             'Class': backend.Class,
>>  4             'FileClass': backend.FileClass,
>>  5             'IssueClass': backend.IssueClass,
>>  6             'String': hyperdb.String,
>>  7             'Password': hyperdb.Password,
>>  8             'Date': hyperdb.Date,
>>  9             'Link': hyperdb.Link,
>> 10             'Multilink': hyperdb.Multilink,
>> 11             'Interval': hyperdb.Interval,
>> 12             'Boolean': hyperdb.Boolean,
>> 13             'Number': hyperdb.Number,
>> 14             'db': backend.Database(self.config, name)
>> 15         }
>> 16
>> 17 ...
>> 18
>> 19             self._load_python('schema.py', vars)
>> 20
>>
>> To alter the behavior of the nosymessage method via inheritance, I would
>> have to substantially modify the main roundup codebase, affecting
roundupdb,
>> rdbms_common, and back_mysql as well as instance. This is one of those
areas
>> where Roundup is hardcoded to the set of classes/interfaces it ships
with.

That's not true. The above defines a set of defaults that are handed into
the schema when it's invoked (by _load_python). Inside schema.py you may
define a new IssueClass, or use some other IssueClass defined elsewhere,
when you create your "issue" class. So inside schema.py you may:

class MyIssueClass(IssueClass):
   def nosymessage(self, issueid, msgid, oldvalues, whichnosy='nosy',
           from_address=None, cc=[], bcc=[]):
        # ... my custom nosy message handler

issue = MyIssueClass(db, "issue",
               assignedto=Link("user"),
               keyword=Multilink("keyword"),
               priority=Link("priority"),
               status=Link("status"))


>> Note that it looks like you cannot import anything from nonstandard
>> locations in interfaces.py, at least not during runtime. The lib
directory
>> is not on the pythonpath unless optimization is turned on.
>
> By "nonstandard" above, I mean "outside the running python installation"
> (site-packages will work, tracker directory will not). Relative paths
don't
> seem to work because it's relative to whatever code happens to call it, so
I
> haven't had any luck making something that works for roundup-admin, the
mail
> gateway, AND the web gateway.

Indeed. You can get around this by, inside your interfaces.py module,
including right at the top:

    import sys
    sys.path.insert(0, '/the/path/to/your/code')


> PS: I apologize in advance if the HTML above gets all messed up going
> through the list.

Came through fine for me :-)


     Richard