[Reportbug-maint] Task-based callback-driven OO project refactoring proposal

[Luca Bruno]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,
I've a proposal for a new branch aimed at creating a well-structured, flexible and robust Reportbug.

class Application:
The aim of reportbug is to create a bug report. This class will own the extern UI (text, newt, urwid, ...), so that there will be no hacks on working with modules every time. The only instance of this class is passed to every other objects.

class BugReport:
There's one already, but this is aimed to be used widely.
Holds the severity, tags, text of the message, the filename and everything else.

class Task:
Each task can execute different operations and may call other tasks.

  def __init__ (parent, callback, error_callback=None)
parent is the parent task, where the application can be obtained.

  def start (args)
this will start the task in non-blocking mode

Once the task is done:
  def done (value)
The value will be returned back to the callback.

class UITask (Task):
These must be all extended by UI extensions.

class MainTask (Task):
The initial parent task that will own the application and that will organize all the other tasks to create the bug report.

Example:
class GetStringTask (UITask):
  def start (self):
    do something
    self.done ("returned value")
  
class GetReportTask (ThreadedTask):
  def run (self):
    notice this is not start()
    self.done (our report object)

class MessageTask (Task):
  def start (self):
    self.ui.GetStringTask (self, self.got_subject_string).start ("prompt")
    self.ui.GetLongStringTask (self, self.got_message_string).start ("prompt")

class SubmitTask (Task):
  def start (self):
    MessageTask (self, self.got_message).start ()

  def got_message (self, message):
    self.bts.GetReportTask (self, self.got_report).start (...)

Why callbacks:
If you notice, the UI must block operations. If the UI doesn't, nothing happens. After you setup all the tasks, nothing blocks the program to exit.

Why tasks:
Now the code is organized with "while". So if you want to repeat something, it's a pain to reorganize all the code.
Anyway with tasks you abstract all the operations the best way, from bigger tasks to the more atomic ones.

Consequences:
GUI won't do hacks with threading anymore (see the GTK+ code)
The code will become more flexible and robust.
Give the project an OO layer to encapsulate data safely.
Centralize all the operations with the application (like loading and exiting)
The operations will be done in a hierarchical flow like dependencies.

Bugs that will be fixed:
All the ones that want a particular operation to be done, like changing tags or severity, or new operations in whishlist.
Resuming the report process.
Ability to do more tasks at the same time: for example if the UI wants to open a secondary window while keeping the first one, and then merging information that are centralized in the application. This will lead to a better organization of different UIs itself.
If the organization is good at the end and if the stuff is really centralized, a chronological order of tasks could be created to allow a "GO BACK" feature.

Time for the refactoring:
The time shouldn't be a problem, everything can work like before in two weeks, one for projecting the base and the other for the refactoring IMHO.

- -- 
http://syx.googlecode.com - Smalltalk YX
http://lethalman.blogspot.com - Thoughts about computer technologies
http://www.ammazzatecitutti.org - Ammazzateci tutti
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAki8RZkACgkQw9Qj+8Kak3FrnACeJRb1ooAOhMM5m+adYQuDZv8V
SIUAnRpWaPDwTJz7W26pgNq5+sVXHbWA
=c0PV
-----END PGP SIGNATURE-----