Django

Code

Ticket #1132 (closed: duplicate)

Opened 3 years ago

Last modified 2 years ago

[patch] CurrentUserField and manipulator changes

Reported by: jkocherhans <jkocherhans@mac.com> Assigned to: adrian
Milestone: Component: Core framework
Version: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

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

Attachments

current_user_field_patch.diff (3.5 kB) - added by jkocherhans <jkocherhans@mac.com> on 12/28/05 16:15:16.
current_user_field_patch.2.diff (8.0 kB) - added by jkocherhans <jkocherhans@mac.com> on 12/29/05 12:28:03.
updated with ideas from rjwittams
current_user_field_patch.3.diff (9.2 kB) - added by jkocherhans <jkocherhans@mac.com> on 12/29/05 16:52:36.
patch for magic-removal

Change History

12/28/05 16:15:16 changed by jkocherhans <jkocherhans@mac.com>

  • attachment current_user_field_patch.diff added.

12/28/05 16:17:19 changed by jkocherhans <jkocherhans@mac.com>

  • type changed from defect to enhancement.

12/28/05 16:40:24 changed by ian@holsman.net

  • component changed from Admin interface to Core framework.

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

12/28/05 16:49:38 changed by jkocherhans <jkocherhans@mac.com>

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

12/28/05 17:34:06 changed by 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.

12/28/05 18:43:47 changed by 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?

12/29/05 06:15:50 changed by hugo

#714 would be solved with this ticket, too.

12/29/05 06:34:34 changed by rjwittams

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

12/29/05 12:28:03 changed by jkocherhans <jkocherhans@mac.com>

  • attachment current_user_field_patch.2.diff added.

updated with ideas from rjwittams

12/29/05 12:33:00 changed by jkocherhans <jkocherhans@mac.com>

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?

12/29/05 14:49:36 changed by 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.

12/29/05 16:52:36 changed by jkocherhans <jkocherhans@mac.com>

  • attachment current_user_field_patch.3.diff added.

patch for magic-removal

12/29/05 17:00:35 changed by jkocherhans <jkocherhans@mac.com>

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.

01/04/06 12:03:56 changed by jkocherhans <jkocherhans@mac.com>

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

01/24/06 02:18:04 changed by hugo

  • status changed from new to closed.
  • resolution set to duplicate.

superseeded by #1268

Add/Change #1132 ([patch] CurrentUserField and manipulator changes)




Change Properties
Action