schooltool-developers team mailing list archive

[Alan Elkner <aelkner@xxxxxxxxx>]

Hey Justus,

I hope you're feeling better.  I decided to not to bother you for a
while to give you a chance to recover, but I do want to ask you to
take a look at my latest commit to my schooltool branch,

https://code.launchpad.net/~aelkner/schooltool/demo_fields

in which I added support for resource demographics.  I have only
created the objects and adpaters and written the unit tests, but I was
hoping you could look it over and tell me what you think.  You'll
notice that I created the same containers for the demo fields and the
demo data as in the basicperson package.  Also, I recreated the same
classes, so there is some duplication of code there, but the question
could be, what were those classes doing in basicperson in the first
place?  Also, consider that in the case of the resource demo fields,
they are wired to be limited by resource_type instead of group_id as I
did with the basicperson demo fields.  In both cases the filter is a
key of sorts (one being a person id and the other a resource object
type), and it's just the method name that differs between them.

That brings me to a point I wanted to make in response to your
objection to using group ids in the case of filtering basicperson demo
fields.  I think there could be a point to be made for filtering them
by the three core person types (admin, teacher, student) and forget
about any additional groups that the user may or may not set up from
year to year.  SchooTool does set up those groups by default anyway,
and so much of the application is wired to take into account the role
of the user, so why not have the filter of person demo fields go by a
person type (so to speak), using a vocabulary key as the value that
goes in the list.  This would make it the same concept as what I'm
using with resource type, again potentially a vocabulary with keys
('resource', 'location', and 'equiptment') to represent the three
types of resource objects.  Incidentally, I will proceed with writing
the resource edit forms to use the filter_resource_type method in my
new resource demo fields in the meantime, and I will not set up the
vocabularies in the short term, just relying on the enum widget for
entering the limit_resource_types.

If we are able to look at filtering both basicperson and resource demo
fields by a vocabulary key (a simple unicode string), then perhaps we
could move the whole set of demo fields out of basicperson and into
the demographics package (don't they belong there anyway?), use a
generic attribute name like limit_keys and method name like filter_key
in the demo fields container.  Then the resource package could reuse
the same classes, saving me from creating the duplicate code that I
had to do in the resource package.

Your thoughts?

Thanks,
Alan