New Fun Design: Difference between revisions
(Much better ideas on lifecycle resources, but definitely still not all there yet.) |
(Better formatting.) |
||
Line 17: | Line 17: | ||
gcd/publishers/(?P<id>)/indicia-publishers/ | gcd/publishers/(?P<id>)/indicia-publishers/ | ||
gcd/publishers/(?P<id>)/indicia-publishers/(?P<ip_id>) | gcd/publishers/(?P<id>)/indicia-publishers/(?P<ip_id>) | ||
GET: View object | |||
PUT: Not used (no direct edit, must reserve) | |||
POST: Create reservation | |||
DELETE: Pending delete? Or should this be a POST variant? | |||
===User Objects=== | ===User Objects=== | ||
Line 29: | Line 28: | ||
gcd/reservations/(?P<object_type>)/(?P<object_id>) | gcd/reservations/(?P<object_type>)/(?P<object_id>) | ||
GET: View edit form | |||
PUT: Update data | |||
POST: Submit for review | |||
DELETE: Abandon change (successful changes not deleted, just become inactive?) | |||
gcd/submissions/(?P<object_type>)/(?P<object_id>) | gcd/submissions/(?P<object_type>)/(?P<object_id>) | ||
GET: View preview and comment form | |||
PUT: Update comments | |||
POST: Commit change to gcd/(?P<object_type)/(?P<object_id) | |||
DELETE: Reject but leave reserved (successful changes not deleted, just become inactive?) | |||
gcd/diffs/(?P<object_type>)/(?P<object_id>)/(?P<version1>)/(?P<version2>) | gcd/diffs/(?P<object_type>)/(?P<object_id>)/(?P<version1>)/(?P<version2>) | ||
GET: View diffs (dynamically generated but may be cached) | |||
PUT: [not used] | |||
POST: [not used] | |||
DELETE: [not used] | |||
Note: Deletion/inactive problematic, as current form URL would need to be recycled for the next change. Also disallows stacking of changes such as "new issue" plus "edit data". Perhaps it is better to assign a new id to reservations/submissions. Note that a change ID is needed for changelog in DB anyway. Also, would such an id correspond to versions in diff URL? | Note: Deletion/inactive problematic, as current form URL would need to be recycled for the next change. Also disallows stacking of changes such as "new issue" plus "edit data". Perhaps it is better to assign a new id to reservations/submissions. Note that a change ID is needed for changelog in DB anyway. Also, would such an id correspond to versions in diff URL? |
Revision as of 04:46, 20 January 2009
[This is really more of a notes page than a proper design doc at this point. An announcement will be sent to gcd-tech when this page is ready for public review. Although feel free to comment before then.]
URLs
Primary Objects
gcd/sequences/ gcd/sequences/(?P<id>) gcd/issues/ gcd/issues/(?P<id>) gcd/series/ gcd/series/(?P<id>) gcd/publishers/ gcd/publishers/(?P<id>) gcd/publishers/(?P<id>)/imprints/ gcd/publishers/(?P<id>)/imprints/(?P<imprint_id>) gcd/publishers/(?P<id>)/indicia-publishers/ gcd/publishers/(?P<id>)/indicia-publishers/(?P<ip_id>) GET: View object PUT: Not used (no direct edit, must reserve) POST: Create reservation DELETE: Pending delete? Or should this be a POST variant?
User Objects
gcd/users/(?P<user_id>)/profile
Edit Lifecycle Objects
gcd/reservations/(?P<object_type>)/(?P<object_id>) GET: View edit form PUT: Update data POST: Submit for review DELETE: Abandon change (successful changes not deleted, just become inactive?)
gcd/submissions/(?P<object_type>)/(?P<object_id>) GET: View preview and comment form PUT: Update comments POST: Commit change to gcd/(?P<object_type)/(?P<object_id) DELETE: Reject but leave reserved (successful changes not deleted, just become inactive?)
gcd/diffs/(?P<object_type>)/(?P<object_id>)/(?P<version1>)/(?P<version2>) GET: View diffs (dynamically generated but may be cached) PUT: [not used] POST: [not used] DELETE: [not used]
Note: Deletion/inactive problematic, as current form URL would need to be recycled for the next change. Also disallows stacking of changes such as "new issue" plus "edit data". Perhaps it is better to assign a new id to reservations/submissions. Note that a change ID is needed for changelog in DB anyway. Also, would such an id correspond to versions in diff URL?
Query Objects
gcd/series/(?P<series_id>)/covers gcd/covers/(?P<when_uploaded>) gcd/resources/(?P<when_modified>)
Python Code
Models
package: apps.gcd.models modules: One per table classes: One per table/module
Most of the structure of the model classes is determined by the database structure. The tables and columns will be renamed to conform to PEP-8 naming standards and avoid most abbreviations. Abbreviations that are retained will be used consistently.
Models may support properties built from multiple columns to ease migration to the new schema and/or reduce the calculations necessary in the UI layer. Models may not directly emit UI markup.
Views
The views modules should only include functions called directly as views, plus code that is tightly coupled with those functions (for instance, functions that implement one action but are split up for organzational or length purposes rather than to add abstraction layers). Code that implements a concept separate from direct view access should go in a support module.
package: apps.gcd.views modules: apps.gcd.details: Detailed data on the primary database objects. apps.gcd.search: Integration with Solr. classes: none, views are function-based and classes should go in support.
Forms
Support
These modules implement abstractions or concepts on which the views or other code in the system rely, but which are not backed directly by the database and therefore are not models.
package: apps.gcd.support modules: apps.gcd.covers: Abstraction for the ever-changing location of covers scans.