On Fri, Apr 8, 2011 at 5:37 AM, M Stefan<mstefa...@gmail.com> wrote:
Hello everyone. My name is Stefan, and I'm a 19 years old student in Iasi,
Romania, at Faculty of
Computer Science. I've started programming as a young kid (I was about 8 or
9) and
have been programming since then. I've started with the silly mIRC scripting
and Visual
Basic and then moved on to various real programming languages (e.g. C, C++,
Python,
Javascript, PHP, C# etc.) and various projects (mostly as a freelancer and
on personal projects).
This is my second time to participate on GSoC (I also participated last year
for Boost) and I
would really like to have the chance to work on a major project again.
I would like to work on removing databrowse from django and implement its
features on admin.
Although I have worked plenty with Python and other MVC frameworks (mostly
PHP ones), I
haven't started learning django until recently. I've read some of
databrowse's source code and toyed
with it a little and I realize it's pretty limited in functionality and, as
has been said, has multiple unfixed
bugs and lacks maintenance. It is too limited to be used for any production
purposes,
and admin does a pretty good job for both production and dev phases.
In fairness, it's not really intended for "production" -- it's a data
exploration tool. It's also a tool that hasn't seen a lot of work
since it was initially added; hence the motivation to merge it with
admin.
A few important features of databrowse include read-only access to tables
and rows, filtering by possible values
of a field (such as filtering by calendar date for datetime fields or
filtering by any of the values that match for
at least one row) and automatically displaying one-to-many,many-to-one and
many-to-many relationships
between models. Looking through the source-code, I realize that not even the
obvious problems have been fixed:
For instance, when creating hyperlinks to objects,
datastructures.EasyInstanceField.urls attempts to call
_get_pk_call() on values returned by
datastructures.EasyInstanceField.values(), which might return
strings or even NoneType (this occurs, for instance, when you have a null
foreign key, which is normal
if you would like to, for example, store a rooted tree). The patch is
trivial, and I've attached it here.
If you've found a patch for a specific bug, then you should open a
ticket and attach your patch there.
That said, I would like to merge its functionality into admin. Users will
have separate permissions
for viewing (which will be granted implicitly with change/delete, it doesn't
make much sense to be able to
change/delete without viewing in a web app). There will be multiple ways of
viewing the data, one that
lists all the tables and their relationships, allowing to view all rows in a
table (with the now-lacking pagination)
and the rows related to it (via foreign keys), with the possibility of
filtering by each of the fields. Another way
of viewing the rows are in a tree-view, in which all rows that are
subordinated (via a foreign key) to other
rows will appear underneath and indented to the right of the parent row. The
rows can be either displayed
by their representation (__unicode__) or by some kind of table showing all
of their fields. Pagination will
be added here too. Rows whose all foreign keys are null will appear as
roots, and so will the rows who
don't have foreign keys (i.e. belong to a table w/ no foreign keys). All
others should appear as children
of at least one row (can appear as children to multiple rows in case the
relationships are many-to-many).
This data viewing interfaces will have means of adding, changing or deleting
rows, which will forward
to the admin interface. If, for instance, one clicks something like "add
child" on a row whose primary
key field is the foreign key of another table, then a row of that table will
be created, whose foreign
key will be set to this row's primary key.
I apologize for being so late with the proposal, I really wish I could have
written it earlier.
I'm planning on writing a timeline for the final version of the proposal,
but please let me know what
your opinion is first.
Well -- to be brutally honest: From a high level, the project is
interesting, and you appear to be roughly on the right track. However,
so far, your proposal is a fairly light elaboration of what Django's
GSoC wiki already gives you, and that's a long way from being an
proposal that is likely to be accepted. You're proposing a set of
fairly major modifications to admin, and all we have to go on is a
paragraph of loose descriptions of what you intend to do.
Time is running out for GSoC applications; if you want your proposal
to be taken seriously, you need to provide a lot more elaboration and
a timeline -- and quickly.
Yours,
Russ Magee %-)
