Standard CRUD (SCRUD)
timmyt
like to use across projects and frameworks
before we get totally dependent on the pattern, I want to make sure
there's not some better solution out there, or some ideas that will
improve the design
below is the spec we came up with:
SCRUD (Standard CRUD)
=====================
Overview
-----------
Standard CRUD is a design pattern for:
* displaying a single instance
* displaying a filterable list of instances
* displaying a form to create a new single instance
* actually creating a new single instance
* displaying a form to update a single instance
* actually updating a single instance
* displaying a form to delete a single instance
* actually deleting a single instance
* displaying a form to perform a bulk insert
* actually performing a bulk insert
* displaying a form to perform a bulk update
* actually performing a bulk update
* displaying a form to perform a bulk delete
* actually performing a bulk delete
The intention is that all methods supported by the model will have
a consistent Class Method Interface - for example any model that
supports bulk insert will have a standard class method to support this
functionality.
Important Considerations
--------------------------------
* SCRUD should work the same in an ajax context as well as in a
traditional page submit
* SCRUD state changing methods should be easily testable using
selenium, twill or some other web testing tool in either an
ajax or page submit context
General Design
--------------------
A method performs one distinct action. For example the act of drawing
an update form is different than the act of actually updating an
object instance. This helps to enable testability and use in various
contexts.
Page Urls
---------
=============================================
Method URL What it does
=============================================
GET model/ gets a list of model instances, using
filters like ?key=value1&key=value2
GET model/search displays a search form
GET model/id displays a readonly instance
GET model/edit/id displays an edit form
POST model/update/id updates an instance and redirects
GET model/create displays an insert form
POST model/insert inserts a new record and redirects
POST model/delete/id deletes a record and redirects
GET model/bulk/edit display a bulk edit ui
POST model/bulk/update performs a bulk update and redirect
GET model/bulk/create display a bulk insert form
POST model/bulk/insert performs a bulk insert and redirect
POST model/bulk/delete performs a bulk delete and redirect
=============================================
Yuri Baburov
>
> my buddy and i have created a Standard CRUD (SCRUD) spec that we'd
> like to use across projects and frameworks
>
> before we get totally dependent on the pattern, I want to make sure
> there's not some better solution out there, or some ideas that will
> improve the design
Rails controllers?
There are some attempts on django RESTful urls:
http://www.google.com/search?hl=en&q=django+rest&btnG=Search
http://www.google.com/search?hl=en&q=django+restful&btnG=Search
And please post this to the django-users group instead (unless you
propose integrating this into django itself).
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
Russell Keith-Magee
>
> my buddy and i have created a Standard CRUD (SCRUD) spec that we'd
> like to use across projects and frameworks
>
> before we get totally dependent on the pattern, I want to make sure
> there's not some better solution out there, or some ideas that will
> improve the design
I'm not sure this is the right forum for your question. If you're
looking for general feedback on a design spec that you have for your
own projects, then you this question should be directed to
Django-users. This forum is for discussing the development of Django
itself.
If this is a proposal for Django itself, then you're going to need to
explain why this change is needed. At the moment, we provide generic
views; these can be deployed in any URL scheme you wish. Given the
extent to which different applications will need different subsets of
the 13 views you propose, with different authentication/access
controls, I'm not sure I see the value in wrapping this "standard". Of
course, I could be wrong - perhaps the best way to prove that is to
make your proposal an external reusable application, and demonstrate a
large user community.
If you're proposing this for Django, you should also keep in mind the
Django development cycle - at the moment, we're in a push for v1.1, so
new proposals aren't getting much attention. If you wait until the
dust has settled after v1.1, you may find you get more attention.
On a slightly broader note, this falls into the category of REST API
proposals - so I would suggest you have a read of the following:
http://jacobian.org/writing/rest-worst-practices/
Yours,
Russ Magee %-)
timmyt
for some info / ideas - thanks a lot for the input