Hey Justus, Could you please have a look at my schooltool branch,
https://code.launchpad.net/~aelkner/schooltool/demo_fields in preparation for our upcoming meeting? Your suggestions were very helpful, so I changed IDemographicFields in basicperson to have limit_keys rather than limit_group_ids, something generic enough to be reused by the resource package, and it also removes the idea of using group_ids in the filtering process. Anyway, I got the unit tests working for the resource demos, and I started working on the views. For starters, I added a link to the Manage tab called “Resource Demographics” which creates a link called “resource_demographics” which, in turn, is the traversal adapter to get to the ResourceDemographicFields container. In the container view itself, the action buttons are coming out for IDemographicFields which have links pointing to the basicperson demo fields. Those lnks come from the view registrations in basicperson that are a bit out of date, using the menu="schooltool_actions" directive that is rendering the links into the wrong container, for example, http:://localhost:7080/demographics/@@addText.html rather than having the resouce_demographics traverser in the link. Additionally, I created my own action button, “New Resource Text Field” for the correct context, and it renders as well, also with the wrong traverser in it. Therefore, hitting any of these button calls up add views that are for the basicperson demo fields container rather than the resource one. It's tricky. If you could take a look at the two recent commits and formulate some suggestions, that would help a lot. Also, I hope you'll have some time after the meeting to look at this stuff with me. Thanks, Alan On Fri, Nov 19, 2010 at 10:31 AM, Justas <[email protected]> wrote: > On 11/19/2010 03:59 PM, Tom Hoffman wrote: >> >> On Fri, Nov 19, 2010 at 7:06 AM, Justas<[email protected]> wrote: >> >>> First, the groups are not set up until user creates a school year. It's >>> a >>> very annoying problem for me. >>> Secondly, it's not written in stone that default groups in a year or so >>> will work as they do now. Or that will exist in all deployments. >> >> I'm willing to write in stone that they will exist. It is a >> reasonable assumption. > > Apologies, I did not phrase that well. > > What I meant to say is: > > From the user's point of view it's, of course, *very* reasonable to expect > them to stay. > > From developers point of view, it's a faulty assumption that default groups > will be implemented exactly as they are now: stay in same containers, their > per-year identification via __name__ will stay as it is now and that all of > them will always be in a per-year container only. > > It's worth to mention that Alan made a wonderful suggestion that will > isolate the hacked-in default ids in a vocabulary and an adapter for groups > specifically, making it possible to have a clean base implementation that is > shared with extra resource fields -- and easy to refactor if needed. > > Regards, > Justas > > > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~schooltool-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~schooltool-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~schooltool-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~schooltool-developers More help : https://help.launchpad.net/ListHelp
