## page was renamed from BugHelper/Dev/python-launchpad-bugs/API changes
''(This is still work in progress)''

As part of my Google Summer of code project I'm going to rewrite python-launchpad-bugs. This wiki-page will give a view of my ideas and a starting point for further discussions. Some of the following items are already implemented in my developing branch [[http://bazaar.launchpad.net/~thekorn/python-launchpad-bugs/api.changes.gsoc]]


= TODO =

 * Renaming (See also PEP 8)
  * launchpadBugs -> launchpadbugs (./)
  * Bug.py -> html_bug.py, a XMLRPC imlementation would be in xmlrpc_bug.py (./)
  * Buglist.py -> html_buglist.py, a XMLRPC imlementation would be in xmrpc_buglist.py (./)
  * Renaming some classes
  * ...

 * decide how to work with a Connector-class (./)
  * create `BugBase` properties
  * implement most urgent properties in Bug.py

 * add documentation to code

 * add unittest
  * create testing dir (./)
  * move api_test* to that dir (./)
  * add more unittests

 * create examples


= Splitting HTMLOperations.py =

I would like to split the existing `HTMLOperations` module into a `Buglist` and a `Bug` module.

 * all connection related functions like `safe_urlopen()` will be moved to utils
 * setting the `cookie_handler` should be a global option


== Buglist ==

This module will basically consist of the old `BugList` and `BugPage` classes.

=== BugList ===

 * Filtering should be a global option
 * the only required parameter in the constructor is `url`
 * `BugList.bugs` will be a `SET`

I almost finished the `Buglist` module, I wrote a small script `api_test_Buglist.py` to give an overview over the new API. I also created a [[BugHelper/Dev/python-launchpad-bugs/API_changes/BugListExample]] to show the usage of `BugList` in small examples.


== Bug ==

`api_test_Bug.py` shows the state of the developing progress.

 * objectify the current Bug -class:
  * `Comments`, `Attachments` and `InfoTable` are new container classes
  * `Comment`, `Attachment` and `Info` - objects are elements of this containers

 * changeable elements have their own `edit`,`add` or `remove` method: e.g.
  * `Comments` will have a `add` method
  * `Attachments` will have `add` and `remove`
  * `Info` will have an `edit` method
  * `Comment` and `InfoTable` are read-only

 * 'edit local and apply at once' - approach

 The following lines of code should explain that approach:

{{{
bug = Bug(1)
bug.attachments.add('fix.patch', comment='first attempt to fix that issue')
bug.status = 'Needs Info'
bug.tags.append('bitesize')
bug.apply()}}}

 * There should not be an extra module for exceptions

 * There is only one argument required in the Bug- constructor:

  * a `BugInfo` instance ''or''
  * an integer type `bugnumber` ''or''
  * an `url` to the bugreport

 * `ATTACHMENT_PATH`, `CONTENT_TYPES` and `ATTACHMENT_REGEX` are global options


= Use a LaunchpadConnector class =

We could use a `LaunchpadConnector` class and have several backends implementing it. That way we can have an easy transition to `XMLRPC` once we get it from Launchpad.

== current implementation ==

With revision 73 I added a Connector module to [[http://bazaar.launchpad.net/~thekorn/python-launchpad-bugs/api.changes.gsoc|api.changes.gsoc]].
In revision 77 I changed LaunchpadConnector into a class, this changed the syntax.

'''Example usage:'''

''loading the default Bug-class:''
{{{
import launchpadbugs.connector as Connector

Bug = Connector.ConnectBug()
Bug.authentication="cookie.txt"

b = Bug(4534)
}}}

''loading the Bug-class from xxx:''
{{{
import launchpadbugs.connector as Connector

Bug = Connector.ConnectBug("xxx")

b = Bug(4534)
}}}

= Discussion =


----
Go Back to '''[[BugHelper/Dev]]'''.<<BR>>
CategoryBugHelper