Opened 18 years ago
Closed 17 years ago
#2360 closed enhancement (wontfix)
user centric/object centric generic crud tools
Reported by: | 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: | no | UI/UX: | no |
Description
Hi,
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,
etc.
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
http://www.b-list.org/weblog/2006/07/03/django-tips-scaling-application
and
http://www.pointy-stick.com/blog/2006/06/29/django-tips-extending-gen...
)
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)
Change History (4)
comment:1 by , 18 years ago
by , 18 years ago
Attachment: | create_update.diff added |
---|
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 by , 18 years ago
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 by , 17 years ago
Resolution: | → wontfix |
---|---|
Status: | new → 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.
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:
else:
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'