About the demo
The code in the demo seems simple, with only a model field
demo.models to construct the gallery model. Actually, there’re some logic fall behind the
Handling the image instances
Although we didn’t explicitly specify in the code, the demo is actually using
galleryfield.models.BuiltInGalleryImage as the image model for
creating, listing, and updating images.
The image model has 2 fields: a
User field named
creator. We think whatever it called, an
field is needed because that’s the basis for the server to determine the
whether requested users are qualified to modify the image instances, or to view the
image instances in a form listview, or to potentially delete existing
Further, If you look into
you will see 3 class-based views which are handling images (or image instances):
galleryfield.image_views.BuiltInImageCreateViewfor uploading images, requires login. Following the naming rule, The URL name is
galleryfield.image_views.BuiltInImageListViewfor fetching existing images, restricted to the owner of the images or superuser, with URL name
galleryfield.image_views.BuiltInImageCropViewfor server side cropping of uploaded images, restricted to the owner of the images or superuser, with URL name
Handling the gallery
demo.models, we defined a gallery model named
DemoGallery, which contains
images, and again an
User field named
owner which is also used to guarantee permissions of requested user to create and update
The handling of galleries is fairly simple as compared to images. The views for galleries
demo.views and its
URL_CONF were in
demo.urls. Three views were provided:
demo.views.GalleryCreateViewis responsible for creating new gallery instances, restricted to owner and superuser.
demo.views.GalleryUpdateViewis responsible for updating existing gallery instances (add/delete/order images), restricted to owner and superuser.
demo.views.GalleryDetailView, which is responsible for rendering the gallery, requires no authentication.