[patch] CurrentUserField and manipulator changes

[jkocherhans <jkocherhans@…>]

This isn't as high level as I would like, but it works. It's also still usable without access to a request object as well. It feels like a hack to me, but no more so than DateField's auto_now and auto_add_now. I played around with using events, and even with RuleDispatch, but this was the simplest change that worked. It doesn't work for inline objects yet though. I figured I'd get some feedback before I waste my time. Here's how to use it:

class Article(meta.Model):
    title = meta.CharField(maxlength=100)
    body = meta.TextField()
    added_by = meta.CurrentUserField(update_on_edit=False) # only save the current user in add_stage
    edited_by = meta.CurrentUserField() # update_on_edit defaults to True

[ian@…]

I'm not sure I like just appending the 'user' to the save function.
shouldn't this be a dictionary so that the view can pass a set of different name/value pairs?
as I can see this being of use for other things besides from the user-id

regards
Ian

[jkocherhans <jkocherhans@…>]

I don't really like appending 'user' to the save function either. I hadn't thought of passing in a dict, but I think I like the idea. It'll make even more since once the new manipulators in the magic-removal branch land in the trunk and custom manipulators become straightforward to do. I thought about adding the request as an argument rather than just the user id. Would that cover the other things you're thinking of? I think anything more would require custom views/manipulators anyhow, and could be done there.

Joseph

[rjwittams]

Yeah, this is really horrible in its present form.
If anything was going to be passed in, it would need to be something general - we don't want to have arbitrary hacks for every bit of functionality.
The least bad thing I can come up with is optionally passing in a mapping - which would usually be the context (but there is no tight coupling, it can just be any mapping). This way processors can be reused, and custom fields can be packaged with the processors required for their functioning.

This would also mean coming up with a much better way of doing this than random isinstance checks inside the manipulator. The field class itself would have to be passed the context ( or whatever ), probably in the get_manipulator_new_data call. Then the field can check to see what is in the post data and in the context.

[anonymous]

Thanks for the comments rjwittams. You've given me quite a few more ideas to try. Just to clarify though, what do you mean by 'context' above? The template context? Would this be something like the new TEMPLATE_CONTEXT_PROCESSORS stuff?

[hugo]

#714 would be solved with this ticket, too.

[rjwittams]

Yeah, the template context. It might be better to think about it more generally than being just for the template system.

[jkocherhans <jkocherhans@…>]

updated with ideas from rjwittams

[jkocherhans <jkocherhans@…>]

I've got a new version of the patch (current_user_field_patch.2.diff) that's a lot more generic. I'm not entriely happy with all of it, but it's closer. fields like added_by vs edited_by don't work yet, and I haven't tested that edit_inline objects work with this though. Generic views would also need to be updated.

I passed the context into the manipulator on init, and that context is passed to fields in get_manipulator_new_data and get_default calls. Comments?

[rjwittams]

This would need to be done against magic-removal. Manipulators have been cleaned up quite a bit, and this wouldn't get applied to trunk.

[jkocherhans <jkocherhans@…>]

patch for magic-removal

[jkocherhans <jkocherhans@…>]

This patch makes auto_add_now stuff in the manipulator a little more general and does everything the previous ones do. Still no tests and no changes for generic views. If this has a good chance of being applied, I'll finish it up. I still don't like passing the context around in field.get_default and field.get_manipulator_new_data, but I think it's the best way. Suggestions for a different approach are welcome.

[jkocherhans <jkocherhans@…>]

Most of the issues here are taken care of in #1164

[hugo]

superseeded by #1268