Opened 9 years ago

Closed 8 years ago

#2360 closed enhancement (wontfix)

user centric/object centric generic crud tools

Reported by: django@… Owned by: jacob
Component: Generic views Version:
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:



I am trying to figure out the best way to deal with object/user centric
object creation. I am building a site that lets users create objects
tied to their identities, for e.g. having users posting news entries,

Currently one can make a wrapper to deal with checking a user's access
for viewing (object_detail), editing (update_object), and deleting
(delete_object), since we have an object instance which we can fetch
and do some tests on, prior to handing it to a generic view. (or better
yet, dealing with object.related_set) (this is discussed on

Unless I am mistaken, one cannot use the create_update.create_object
function with one of the model's fields pre-populated (in this case,
user_id/author_id). This is unfortunate, since it means making a custom
function for object creation.

I am trying to figure out a way to build a generic function for
relational object creation. i.e. being able to call something like
create_update.create_object(model=Post,relation=user.post_set) so the
function could call relation.create(instance based on form data). This
would also hide/ignore the POSTed settings which are immutable (i.e.
user's id)

Am I missing something, or is this possibly something that should go
into generic views, or should I code my own function? Can it be made
generic enough.

Attachments (1)

create_update.diff (2.2 KB) - added by nicolaslara@… 9 years ago.
Ok, here's the patch i promised. it only adds suport for the create view. I was going to do/post the rest but seeing this "manipulator to crud views" issue hasn't been welcomed by the developers i'll wait for feed back

Download all attachments as: .zip

Change History (4)

comment:1 Changed 9 years ago by nicolaslara@…

Probably the best way to do this, and i was thinking about creating a patch to do so, is to allow CRUD generic views to accept an especific manipulator. The generic view will only show the fields related to that manipulator, the other fields can be either filled with default values or, as you said, pre-populated in a view that extends the generic view.

Allowing the generic view to accept the manipulator is not hard, the only thing you need is your newly created manipulator to extend the right class (the one that contains the objects needed by the GV. i.e. flatten_data() ) and adding some:

if extra_manipulator:

manipulator = extra_manipulator()



to prepopulate field thats another story (ill probably post about that or add a patch sometime soon) but im sure this two enhancements are just what generic views are lacking (at least crud) and do not deviate from the 'django philosophy'

Changed 9 years ago by nicolaslara@…

Ok, here's the patch i promised. it only adds suport for the create view. I was going to do/post the rest but seeing this "manipulator to crud views" issue hasn't been welcomed by the developers i'll wait for feed back

comment:2 Changed 9 years ago by nicolaslara@…

For using the custom manipulators in a create view (with my patch) all you have to do is pass the generic view a parameter eith tthe manipulator that implements init() and save(). If you want to have extra content just add a dictionary containing the pairs of values for the data. to have this content prepopulated use: pre_populate=True (only to allow the template to see it, the content is always post_populates anyway).

As I said before i dont really understand that "manipulators are going away thing". maybe its because i havent been following the mailing list.
i hope to get some feed back on this issue.

comment:3 Changed 8 years ago by MichaelRadziej <mir@…>

  • Resolution set to wontfix
  • Status changed from new to closed

Thanks for your efforts, but the create/update views depend on oldforms which will soon be history, so I'm confident that your changes won't be accepted. Sorry.

Note: See TracTickets for help on using tickets.
Back to Top