On 01/12/2012 11:25 AM, Ethan Jucovy wrote:
On Thu, Jan 12, 2012 at 11:13 AM, osimons <[email protected]
<mailto:[email protected]>> wrote:
Right, so 'tickets' is actually not a list of ticket objects... Chris,
it really makes sense for your code to follow the common Trac practice
of passing actual objects around instead of mutating them into various
structures. It just makes it so much harder for everyone, and makes
code less readable and questions harder to anwser. In everything I
read in your question and code, t should be a trac.ticket.model.Ticket
object - and 'tickets' should be a list of them....
Tracing through the code where ``tickets`` is defined (
http://trac-hacks.org/browser/tracjsganttplugin/0.11/tracjsgantt/tracjsgantt.py#L546
) I see that it's actually the result of a
trac.ticket.query.Query().execute() call, which returns a list of raw
dicts: http://trac.edgewall.org/browser/trunk/trac/ticket/query.py#L326
Does a higher-level or more formal API exist in Trac core for fetching
tickets from a query? I remember looking for one a while ago and not
finding anything.
I actually don't need ticket objects (and I'm sorry for my sloppy
nomenclature; I know if makes communication difficult). My PM stuff
(e.g., scheduling) only acts on ticket attributes and having there
results of a query is fine and adequate.
computeSchedule() should be easy to call with those query results:
# tickets is an unordered list of tickets. Each ticket contains
# at least the fields returned by queryFields() and the whole list
# was processed by postQuery().
#
# On return, each element of tickets has had two fields added:
# calc_start, and calc_finish. No other changes are made.
def computeSchedule(self, options, tickets):
But the scheduler is going to have to look up ticket values by ID again
and again, Each scheduler implementation could do it's own lookup table
but I put it in the wrapper:
# Convert list to dictionary
ticketsByID = {}
for t in tickets:
ticketsByID[t['id']] = copy.copy(dict(t))
# Schedule the tickets
self.scheduler.scheduleTasks(options, ticketsByID)
To give the scheduler the freedom to change attributes or add others, I
copy only the intended fields back from the result.
# Copy back the schedule results
for t in tickets:
for field in [ 'calc_start', 'calc_finish']:
t[field] = ticketsByID[t['id']][field]
But nothing I do seems to isolate the caller from scheduler changes to
the dependency fields (and possibly others but that's what I can see in
my current failure case).
Chris
--
Christopher Nelson, Software Engineering Manager
SIXNET - Solutions for Your Industrial Networking Challenges
331 Ushers Road, Ballston Lake, NY 12019
Tel: +1.518.877.5173, Fax: +1.518.877.8346 www.sixnet.com
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
