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 _______________________________________________ Mailing list: https://launchpad.net/~schooltool-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~schooltool-developers More help : https://help.launchpad.net/ListHelp
