Skip to content

Latest commit

 

History

History
49 lines (39 loc) · 2.61 KB

about_demo.rst

File metadata and controls

49 lines (39 loc) · 2.61 KB

About the demo

The code in the demo seems simple, with only a model field galleryfield.fields.GalleryField used in demo.models to construct the gallery model. Actually, there're some logic fall behind the code.

Handling the image instances

Although we didn't explicitly specify in the code, the demo is actually using built-in galleryfield.models.BuiltInGalleryImage as the image model for creating, listing, and updating images. The image model has 2 fields: a galleryfield.fields.GalleryField named image and an User field named creator. We think whatever it called, an User 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 image instances.

Further, If you look into galleryfield.urls and galleryfield.image_views, you will see 3 class-based views which are handling images (or image instances):

  • galleryfield.image_views.BuiltInImageCreateView for uploading images, requires login. Following the naming rule <image_handling_url_naming_rule>, The URL name is galleryfield-builtingalleryimage-upload.
  • galleryfield.image_views.BuiltInImageListView for fetching existing images, restricted to the owner of the images or superuser, with URL name galleryfield-builtingalleryimage-fetch.
  • and galleryfield.image_views.BuiltInImageCropView for server side cropping of uploaded images, restricted to the owner of the images or superuser, with URL name galleryfield-builtingalleryimage-crop.

In demo.models, we defined a gallery model named DemoGallery, which contains a galleryfield.fields.GalleryField named images, and again an User field named owner which is also used to guarantee permissions of requested user to create and update gallery instances.

The handling of galleries is fairly simple as compared to images. The views for galleries were in demo.views and its URL_CONF were in demo.urls. Three views were provided:

  • demo.views.GalleryCreateView is responsible for creating new gallery instances, restricted to owner and superuser.
  • demo.views.GalleryUpdateView is responsible for updating existing gallery instances (add/delete/order images), restricted to owner and superuser.
  • and demo.views.GalleryDetailView, which is responsible for rendering the gallery, requires no authentication.