schooltool-developers team mailing list archive

[Alan Elkner <aelkner@xxxxxxxxx>]

Hey Justas,

After talking with Tom about what changes I would make to the
intervention implementation, we agreed that there were two very
practical tasks I could undertake in the short term.  I'd like your
comments on these tasks to make sure I don't come up with the wrong
time estimate for Tom.  Please look at interfaces.py and
intervention.py to follow my points.

The first one is a small one requiring no change to the data model.
As is necessary in many of the views, I need to display the student's
name.  Currently, I have a student attribute for all of the
intervention objects that computationally returns the student's
BasicPerson record.  I think you would prefer that I used the more
standard approach of creating adapters from all the intervention
object types to IBasicPerson and then get rid of the no longer needed
property.  This would only take a couple of days to change the
implementation and write the tests.

The second task is a much larger one, requiring a change to the data
model, hence, an evolution script.  I know how much you hate having
ids saved in objects, so I plan to replace the current lists of ids
with relationships to the actual objects themselves.  This way, if a
person is removed from the system, they will automatically disappear
from the intervention objects, the advantage of using relationships.
This would also eliminate the need for my helper functions like
convertIdToNameWithSort which is already too complex and difficult to
test.  The most difficult to understand part is the ':n' that I add to
the student's id when I need to save a reference to one of the
student's parents.  Instead, I'll carry relationship links to the
contacts themselves, also magically disappearing if deleted at the
source.

Specifically, in the InterventionMessage object, I will be replacing
the sender attribute, an id, with a sender_link attribute, a
relationship.  I need the attribute name to change in order to handle
the evolve step where I will be reading from one and writing to the
other, right?  The recipients attribute will be replaced by two new
attributes, recipients_persons and recipients_contacts.  I need to
have two different lists there because relationships to teachers,
administrators and the student is with BasicPerson objects where
relationships to parents is with Contact objects.

For InterventionGoal objects, creator will be replaced by
creator_link, again the name change for evolution purposes.  The
persons_responsible attribute will be broken up into
persons_responsible_persons and person_responsible_contacts, where
at_one_time_responsible will be broken up into
at_one_time_responsible_persons and at_one_time_responsible_contacts.

One of the trickier parts of this change is how to rework the
PersonListField widget which is designed to work off of the list of
ids (:n included) that are found in the current implementation.  The
widget is designed to list the teachers and administrators in the
column labeled 'Staff' and the student and parents in the second
column labeled 'Student/Parents'.  Also, in those rare cases where
there is someone in the at_one_time_responsible list that is not in
the persons_responsible list, those people appear in the second
column, right below the student and parents with a 'Changed Status'
heading above.  This is all what we agreed to at the Rhode Island
sprint.

In any event, the mapping of the one list to this complex widget would
no longer be possible in the new implementation where we would be
carrying lists of both persons and contacts.  Would this be a case for
a sub-form?  The need to render the two column list and process the
request for which checkboxes the user clicked is found in four places,
each of the add an edit views for goals and messages.  I suppose the
same page template could be used for rendering the sub-form for goals
and messages and the processing of the request could be handled by two
different view classes, one for goals and one for messages.  The
current goal and message add and edit views are old formlib views, not
z3c.form, so there's that to deal with.  Also, even if I change the
views to use z3c.form, we don't currently have a page macro in core
that allows for sub-forms.  I suppose I could just have my own page
templates for this and not worry about using page macros.  What do
recommend?

Anyway, please get me your thoughts by the end of your day so I can
discuss with Tom what I will be doing.

Thanks,
Alan