Merge some branches in before 1.0?
Simon G.
We've warned people off using the svn version to run production sites
because of the post-1.0 code breakage that's going to be happening.
So, we don't need to worry as much about stability of trunk, since
0.96 is the stable, recommended version.
Therefore, why don't we get some of these branches merged in (once
newforms-admin and unicodisation are sorted out), and let people get
onto testing them?
There are a number which look so close (Oracle, FullHistory,
GenericAuth), but they don't seem to be getting any attention from the
wider community, which I think they would if people didn't have to
switch branches to get them.
I know the reason that they've been left out is that they no-one's
stepped up to maintain them, but once people start using them, then
we'll see tickets and patches start to come in for them, and generate
interest about them.
Comments?
--Simon
David Danier
I started to read the code of FullHistory and GenericAuth, because I
needed this for my own project some time ago. So I try to comment on
these two. Perhaps I can help finishing both, as I implemented this
functionality myself after reading the code and concluding that both are
not ready.
FullHistory:
Has some nice ideas, but seems very unfinished (there is even
debug-output inside the code...print-statements). Additionally I think
it has some real issues, that need to be addressed before merging.
In detail:
* Signal-handlers use pre-events, but save()/delete() might raise an
exception
* Creating new revisions (model: ChangeLog) using signals misses the
option to add an comment (text describing the changes) to the history
(model-attribute for this exists)
* I had some problems with unicode-strings in my own code, this will
happen in this branch again, because I used mainly the same code
(unicode + pickle + db: newforms provides unicode-string -> pickle puts
this into some normal string as utf-8 -> INSERT fails)
* user-Field is unused so far, as the signal does not provide this
information (and should not do this)...and saving the IP might be
useful, too
* Some way to specify options for dumping might be useful (like for the
admin)...not all models need to create a history
* No views so far (and using the current approach - see urls.py - this
will have the same problems with reverse urls I sent to this list some
time ago, see
http://groups.google.com/group/django-developers/msg/51ef359db17f5e40)
* Code is far from being complete
For the comment/user-problem some generic function to create a revision
can be provided that is called from the (generic-)views. Perhaps forms
can add a comments-field if a history is wanted (I extended the newforms
to be complete modular, so a simple forms.HistoryField() does this job
for me).
GenericAuth:
I'm not sure if extending the current auth-system is the right way (as
stated many times before). Some of the reasons may be in this list again.
* Model-backends-approach has the drawback, that every backend must
return a standard-django user-model. So data needs to be duplicated and
may drift apart. Every backend must mimic the ModelBackend (even with
the return value-type)...otherwise many things start to fail (example:
models.ForeignKey(User))
* The current system uses some "foo.bar"-string for permissions. This
can be avoided using the model-class directly.
* No decorators for object-permissions (tricky, but possible...did it
using two decorators: fetch_object() and had_object_permission())
* uses oldforms
I think the auth-system should be refactored as it is done with the
admin (newforms-admin) currently. The GeneriyAuth-branch does a great
job here, but tries to keep as much from the old system as possible. I
think this should be changed (for example no permission-table should be
added by default, instead this can go into a different application).
But the code seems mature and working, only some details are missing, if
the current auth-solution should be kept.
(Changing this might be better for post-1.0...but adding this now and
changing it later may be worse than changing it now)
Greetings, David Danier
Adrian Holovaty
> We've warned people off using the svn version to run production sites
> because of the post-1.0 code breakage that's going to be happening.
> So, we don't need to worry as much about stability of trunk, since
> 0.96 is the stable, recommended version.
>
> Therefore, why don't we get some of these branches merged in (once
> newforms-admin and unicodisation are sorted out), and let people get
> onto testing them?
That's the plan. Once the branches get finalized, they'll get moved to
trunk so that more people can test them.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
James Bennett
> because of the post-1.0 code breakage that's going to be happening.
> So, we don't need to worry as much about stability of trunk, since
> 0.96 is the stable, recommended version.
Most of the branches under active development are things which are
planned to land in trunk before 1.0 -- newforms-admin and unicode, for
example.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."