On 01/13/2011 09:50 AM, Alan Elkner wrote:
Hey Justsus,
I merged your branch and resolved the conflicts. There were only a
few, and the tests passed, so I pushed it.
Great :)
I then created the filter_keys method that you wanted and set out to
use it in the generateExtraFields method of the PersonForm class.
Only problem is, when adding a new person, what would be the keys to
pass? The person in question doesn't exist, so they don't belong to
any groups, and what's more, the context is the person container, so
I'm not sure what you would want there.
Please look at the custom person views I created in schooltool.niepa
because the whole reason for the limit_keys is to allow us to only
show the demos for the type of person we are adding, student, teacher
of administrator. Core schooltool doesn't have such a group-aware add
view, so it currently has no use for the filter_key method. I could
see in the case of the display and edit views, where the person object
is the context, then I could put a call to filter_keys, but what to do
in the add case? This is the discussion I was going to bring up in
schooltool dev, so I guess I'm doing it now.
The question is: do we want to bring the niepa person add views into
schooltool core? They depend on the presence of links that where
added to the niepa custom action link manager, as does
schooltool.cambodia, so that opens up discussion on what we want to do
there and when.
Another way of dealing with schooltool core's current group-unaware
add view is to leave it be and just not include any demos that have no
limit keys. Then, after the user has successfully added the person,
the edit view of that person could have the demos that apply to the
groups the user belongs to. That's clunky for the user, but without
group-aware add views, there's no other way.
Tom,
Do you want the group-aware views and the necessary special action
links and filtered container vews in schooltool core while we are
merging the demos fields branch? Or should we stick with the clunky,
add first, edit demos later approach for now, and deal with the more
complex group-aware views at the sprint?
To summarize the options...
Plan A (just remove the demo fields in add forms):
1. Users fills in person form without the demo fields.
2. Clicks "Add".
3. Figures out that he should click the "Edit" action button, and fills in
the demo fields.
4. Clicks "Done"
Plan B:
Show "Add teacher", "Add student", etc. action links *only* when there is a
relevant group in the active school year. Those forms would have the
person's group pre-selected and non changeable, like in schooltool.niepa.
Plan C (update add person and add multiple persons views):
1. Users fills in person form without the demo fields
2. Clicks "Add". If no group was selected, that's the end of operation.
3. User fills in the (filtered) demo fields for the newly added person.
4. Clicks "Done"
Drawbacks:
Plan A - very, very unintuitive
Plan B - users must create a schoolyear first to see them; it will clutter
the action bar somewhat: "Add person", "Add teacher", "Add student", "Add
administrator".
Plan C - most expensive.
Personally, I'd go with plan C. It would be nice to put strong emphasis on
group's dropdown. Put it on the top of the form, or maybe even in a
separate fieldset. So it looked like you are selecting a type of the person
to add:
--=--Add person--=--=--=--=--=--=--=--
Group: [ Teachers V]
Fist Name ________
Last Name ________
username ________
etc.
[Add] [Cancel]
--=--=--=--=--=--=--=--=--=--=--=--=--
Oh and as extra sugar, we could enhance the group select widget to display
something along the lines "You need a school year to add teachers and
students" instead of the dropdown when there is no school year.
Well, that's my two cents.
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
