schooltool-developers team mailing list archive

[Alan Elkner <aelkner@xxxxxxxxx>]

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 <justas@xxxxxx> wrote:
> On 11/19/2010 03:59 PM, Tom Hoffman wrote:
>>
>> On Fri, Nov 19, 2010 at 7:06 AM, Justas<justas@xxxxxx>  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     : schooltool-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~schooltool-developers
> More help   : https://help.launchpad.net/ListHelp
>