Re: "things are ready" signal?
On Wed, Oct 1, 2008 at 5:04 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > > > So, would a signal there be useful? (no ticket filled yet) And, where > can one hook code for that? :) > I seem to recall this request being made from time to time. IIRC, it always turned out that whoever asked didn't really want this, but something else. Therefore, I don't believe anyone has provided a valid use case for such a signal. I'd suggest searching the archives. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Request for comments on ticket 8122: better way of testing for cookies
Hi all, Now that the trunk is open for enhancements, I would like to ask the core developers for their opinion on ticket 8122: better way of testing for cookies [1]. Chris Beaven looked at the ticket and suggested I bring it up here to solicit comments. The ticket addresses the awkward set_test_cookie() / test_cookie_worked() mechanism: if you want to check whether a client supports cookies you have to set_test_cookie() in one request and test_cookie_worked() in another. The patch in the ticket solves this by always setting the session cookie, but leaving it empty until the session is modified. This way the client can automatically be checked for cookies after the first request, while avoiding a call to the session backend until the session is modified. Note that the patch is not optimal, it does include tests but no documentation. Regards, Joost [1] http://code.djangoproject.com/ticket/8122 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
"things are ready" signal?
Hi there, Staring at #8638 I'm trying to find a way to hook code to be run "just after Django is completelly loaded" and found no way ;( The thing is, it's a really nice place to emit a signal if you want to do things "just after things are ready", but there's no signal for it. And, as I found nowhere to hook the code for #8638 I have no idea of where such signal should be emitted from (or that code hooked). So, would a signal there be useful? (no ticket filled yet) And, where can one hook code for that? :) Regards, Marc -- http://www.marcfargas.com - will be finished someday. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Branches "trimming" and structure
Hi ppl,
In the contributing docs we can read:
After a branch has been merged, it should be considered "dead";
write access to
it will be disabled, and old branches will be periodically "trimmed."
My English is not very good but I always understood that as "we'll
remove them when they get useless or there are lots of branches in
there", am I wrong?
Please Please Please run lots of "svn rm http"!!
Also, now we have branches/releases/, after clean-up, could we also
have branches/in-progress/ and branches/{dead,done} ? that would leave
things much clearer (and it wouldn't mess up git-svn :P)
Just an idea ;)
Regards,
Marc
--
http://www.marcfargas.com - will be finished someday.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: ANN: 1.0.X branch created; trunk is open for features
On Wed, Oct 1, 2008 at 4:07 AM, Richard Davies <[EMAIL PROTECTED]> wrote: > Perhaps it's now time for a '1.0.1' milestone in the ticket tracker, > to nominate those tickets which are simple bug fixes against '1.0'? No. Right now any bug at all that was present in 1.0 is a candidate for fixing. Seriously, people, cool it for a while (where by "a while" I mean "at least a couple months") about the milestones, OK? They're only useful when we're getting close to a release, and we're not going to be close to a release for a while. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django model version control
Please move this conversation to django-users. Django-developers is for the discussion pertaining to the maintenance and development of the django framework itself. On Thu, Oct 2, 2008 at 3:55 AM, Erik Allik <[EMAIL PROTECTED]> wrote: > > Nevermind the previous e-mail. > > On 01.10.2008, at 17:10, David Hall wrote: > > > > > I've just released an open-source version control application for > > Django. It is available for download from Google code. > > > > http://code.google.com/p/django-reversion/ > > > > Features include: > > > > - Roll back to any point in a model's history - an unlimited undo > > facility! > > - Recover deleted models - never lose data again! > > - Admin integration for maximum usability. > > - Group related changes into revisions that can be rolled back in a > > single transaction. > > - Automatically save a new version whenever your model changes using > > Django's flexible signalling framework. > > - Automate your revision management with easy-to-use middleware. > > > > It can be easily added to your existing Django project with an > > absolute minimum of code changes. > > > > It's so far been previewed by a half dozen developers, with good > > feedback. I'd appreciate any comments / suggestions you may have to > > offer. > > > > > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django model version control
Nevermind the previous e-mail. On 01.10.2008, at 17:10, David Hall wrote: > > I've just released an open-source version control application for > Django. It is available for download from Google code. > > http://code.google.com/p/django-reversion/ > > Features include: > > - Roll back to any point in a model's history - an unlimited undo > facility! > - Recover deleted models - never lose data again! > - Admin integration for maximum usability. > - Group related changes into revisions that can be rolled back in a > single transaction. > - Automatically save a new version whenever your model changes using > Django's flexible signalling framework. > - Automate your revision management with easy-to-use middleware. > > It can be easily added to your existing Django project with an > absolute minimum of code changes. > > It's so far been previewed by a half dozen developers, with good > feedback. I'd appreciate any comments / suggestions you may have to > offer. > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django model version control
Hi David, Is this integrate with Subversion or any Version Control Tool? Regards, -LN On Wed, Oct 1, 2008 at 10:10 AM, David Hall <[EMAIL PROTECTED]> wrote: > > I've just released an open-source version control application for > Django. It is available for download from Google code. > > http://code.google.com/p/django-reversion/ > > Features include: > > - Roll back to any point in a model's history - an unlimited undo > facility! > - Recover deleted models - never lose data again! > - Admin integration for maximum usability. > - Group related changes into revisions that can be rolled back in a > single transaction. > - Automatically save a new version whenever your model changes using > Django's flexible signalling framework. > - Automate your revision management with easy-to-use middleware. > > It can be easily added to your existing Django project with an > absolute minimum of code changes. > > It's so far been previewed by a half dozen developers, with good > feedback. I'd appreciate any comments / suggestions you may have to > offer. > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django model version control
Is it an alternative to django-evolution and dmigrations? If not, does it provide a subset of the features of the two? Erik On 01.10.2008, at 17:10, David Hall wrote: > > I've just released an open-source version control application for > Django. It is available for download from Google code. > > http://code.google.com/p/django-reversion/ > > Features include: > > - Roll back to any point in a model's history - an unlimited undo > facility! > - Recover deleted models - never lose data again! > - Admin integration for maximum usability. > - Group related changes into revisions that can be rolled back in a > single transaction. > - Automatically save a new version whenever your model changes using > Django's flexible signalling framework. > - Automate your revision management with easy-to-use middleware. > > It can be easily added to your existing Django project with an > absolute minimum of code changes. > > It's so far been previewed by a half dozen developers, with good > feedback. I'd appreciate any comments / suggestions you may have to > offer. > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Django model version control
I've just released an open-source version control application for Django. It is available for download from Google code. http://code.google.com/p/django-reversion/ Features include: - Roll back to any point in a model's history - an unlimited undo facility! - Recover deleted models - never lose data again! - Admin integration for maximum usability. - Group related changes into revisions that can be rolled back in a single transaction. - Automatically save a new version whenever your model changes using Django's flexible signalling framework. - Automate your revision management with easy-to-use middleware. It can be easily added to your existing Django project with an absolute minimum of code changes. It's so far been previewed by a half dozen developers, with good feedback. I'd appreciate any comments / suggestions you may have to offer. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
context-updating templatetags and ExtendsNode - some feedback ?
Hi everybody, and first thanks to everyone involved in Django's developpement. I recently discovered that when extending a base template, templatetags outside a block node in the 'extending' template where just ignored. This of course makes perfect sense for content-rendering tags, but can be a problem with context-updating tags - which are sometimes (often IMHO) the best solution to decoupling pluggable apps views from project-specific templates (context processors are not necessarily a good solution here, still IMHO). To provide more context (no pun), my use case is: - a complex project using a set of pluggable apps - a slots/portlets systems to add content on a per-template basis - and of course, template inheritance and somewhat complex templates with lot of blocks Since we want to keep pluggable apps, well, pluggable, loading appropriate portlets from the view is not an option. Using a context processor here would imply either always loading all possible portlets for all possible slots, which would be a costly waste of resources, or adding quite a lot of logic to the context processor - logic that will be subject to frequent changes, and that designers/integrators won't be able to handle. And also, some decisions on the portlets to load depends on the template's context, which is not available in the context_processor. Same problem with view middlewares FWIW. So I wrote a context updating template tag that, with appropriate arguments, loads all required portlets for a given user and a set of slots (as a slot:[portlets...] mapping) at once and inject them in the context. The problem is that, well, since slots correspond to blocks defined in a parent template, we actually have to call this tag for each slots (block), which means as many calls to the portlet loader functions and queries to the database, when we could have them all with a single call if we could put the call to the tag before any other block - that is, outside the blocks... I had a look at the ExtendsNode.render code, and it seems that it would be possible to allow for 'top-level' (outside blocks) context- updating tags without much change to the code and without (AFAICT) breaking anything. This modification requires context-updating tags to declare themselves as such (the same way extends declare itself as must_be_first), and adding about 6 lines of code (in it's current form, which is a first Q attempt) at the end of ExtendsNode.render to collect top-level context-updating tags and insert them at the appropriate position in the parent's template nodelist. So, what would you ladies and gentlemens think about adding such a feature, and what would it take (from me) to have a chance to see it added to the core ? Or is there any obvious other solution / problem with my solution / whatever I would have failed to spot ? Thanks for reading so far, and TIA for answers / comments / questions / criticism / whatever feedback. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Documentation url
On Wed, Oct 1, 2008 at 12:17 PM, Brett H <[EMAIL PROTECTED]> wrote: > > I cringe at posting this but.. there's a little forward slash that > suddenly appeared on the Django website documentation url > > http://docs.djangoproject.com/en/dev// > > Is it just visiting or should I re-bookmark? This is the result of an error introduced a few days ago in the code for the Django site; it has been logged (several times) on the Django ticket tracker, so we're aware of the problem - we just need to find the time to fix it. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Documentation url
I cringe at posting this but.. there's a little forward slash that suddenly appeared on the Django website documentation url http://docs.djangoproject.com/en/dev// Is it just visiting or should I re-bookmark? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
#689 Honour Webserver Provided Auth (REMOTE_USER)
Hi, #689 Honour Webserver Provided Auth (REMOTE_USER) http://code.djangoproject.com/ticket/689 I use it this patch since several weeks. This patch only adds new stuff, thus it wont' break running code. Why not commit it? Thomas PS: The current code is in a git repository linked in the ticket. -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ANN: 1.0.X branch created; trunk is open for features
Great! Perhaps it's now time for a '1.0.1' milestone in the ticket tracker, to nominate those tickets which are simple bug fixes against '1.0'? Clearly still too early for '1.1' milestone, etc, given that there's a different process started for that Cheers, Richard. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: HttpResponse and file-like objects
Streaming/iterable HttpResponse instances are kind of an issue which
needs sorting out. I've had problems in the past with the current
implementation. Maybe a closer look is actually necessary.
Regards,
Zack
On Oct 1, 3:41 am, David Cramer <[EMAIL PROTECTED]> wrote:
> Thanks Graham, I'll check that out.
>
> I was going to file a ticket for this, but it seems streaming isn't
> really "supported" anyways, so I had to change the approach.
>
> On Sep 30, 8:19 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > On Oct 1, 11:06 am, David Cramer <[EMAIL PROTECTED]> wrote:
>
> > > I'm running into an issue when trying to pass a file-like object to
> > > HttpResponse and telling it to label it as "application/xml"
>
> > > def sitemap(request, sitemaps, section):
> > > page = request.GET.get('p', 1)
> > > fpath = os.path.join(settings.BASE_PATH + '/', 'cache/sitemap-%s-
> > > %s.xml' % (section, page))
> > > if not os.path.exists(fpath):
> > > raise Http404
>
> > > return HttpResponse(open(fpath, 'r'), mimetype='application/xml')
>
> > > When added the mimetype, nothing gets sent to the browser. Removing it
> > > solves the issue, but then it has an invalid content type.
>
> > Nothing to do with your specific problem, but knowing how you always
> > want things to run as well as possible and how big your sitemap file
> > apparently is, may interest you to look at wsgi.file_wrapper
> > references in:
>
> > http://code.djangoproject.com/wiki/Version1.1Features
>
> > One of the tickets (7894) has patch to allow static files to be
> > returned using more optimal means provided by mod_wsgi/mod_python,
> > ie., using sendfile() or other memory mapping techniques.
>
> > Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: unique_for_ fields
> Short version: model-aware validation is being worked on. We didn't get
> it finished for 1.0, but it's still ongoing work.
Wouldn't it be nice to replace these three parameters by something like:
class SomeModel(models.Model):
[...]
class Meta:
unique_together = ('title', 'pub_date__year')
Meaning we could use the same syntax as we do for filter()/explude().
This could allow new use-cases like some combination of fields should be
unique for some given date. Example:
class SomeCategorizedModel(models.Model):
[...]
class Meta:
# perhaps useful for urls like /foo
unique_together = ('slug', 'category', 'pub_date__year')
Just some ideas I had when reading the original post, don't know if this
would require lots of work. :)
Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
