HTTP PUT request
Hi, There seems to be an issue with Django in the HttpRequest class, in that I cannot access the data provided in a HTTP PUT request. I'm writing a web app which uses a RESTful interface, but at the moment I have to put together a piece of hacky middleware in order to be able to get the PUT data. What I'm doing now is changing the method to POST, accessing the request.raw_post_data attribute, and then changing the method back to PUT. This seems a little unnecessary, and I'd like to suggest the addition of a content attribute which holds any raw content provided, whether through POST or PUT. Not much code really needs to be changed at all, and I'd be willing to do it myself. It's just that this seems like a bit of a bug in Django. Regards, Zack --~--~-~--~~~---~--~~ 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: Call for testing: new docs
I have just a tiny suggestions... could you make the headlines a bit bigger or with more space around them? When scrolling, there is no real distinction between different parts. I always found that a bit unusable in the Django docs. You just have a large stream of text and your eyes are unable to scan the parts of a document. --~--~-~--~~~---~--~~ 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: Call for testing: new docs
I wish the fonts were bigger all around. Less wasted space on the left and right and bigger, more readable fonts. If you're quickly scanning the page, looking for something in particular, it's easier if the fonts are a little bigger. Even in the existing docs, it's difficult for some of us that have to wear glasses. I bumped the font size up to 14px in Firebug and I thought it was easier to read. Thanks! Jon Brisibn http://jbrisbin.com On Aug 20, 2008, at 5:25 AM, julianb wrote: > > I have just a tiny suggestions... could you make the headlines a bit > bigger or with more space around them? When scrolling, there is no > real distinction between different parts. I always found that a bit > unusable in the Django docs. You just have a large stream of text and > your eyes are unable to scan the parts of a document. > > --~--~-~--~~~---~--~~ 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: Call for testing: new docs
Hi, On Wed, Aug 20, 2008 at 12:01 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > The docs refactor work is pretty much done; now I need a bunch more > eyes to look things over. There's still a bunch of TODOs (see below), > but it's better than the current docs and maintaining branched docs is > a major pain, so I plan to have this merged into trunk this week. Very Very Very good news! ;) > The best way to send me code is by letting me know about your remote > git repo. I'll try to give some love to it on my spare time, You can fetch some link corrections from my git branch already: http://www.marcfargas.com/gitweb/?p=django.git;a=shortlog;h=docs-refactor http://www.marcfargas.com/git/django.git/ -- 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: Call for testing: new docs
On Wed, Aug 20, 2008 at 2:36 AM, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Jacob Kaplan-Moss wrote: >> I've also put a built version of the docs online at >> http://docs.djangoproject.com/dev/. There are some problems with the >> version online right now; no need for bug reports since I'll be >> changing the online version to better fit into the django site over >> the next few days. > > Hi, Jacob! > > Does "no need for bug reports" apply only to presentation or to content > as well? I'm asking because I've found an old-style `class Admin` your > request declaration in an example in "Django at a glance" and I'm not > sure if such bugs are known. > There's already a ticket for this: #8150. Although the patch might need to be adjusted for the new docs. http://code.djangoproject.com/ticket/8150 -- 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 -~--~~~~--~~--~--~---
Re: Call for testing: new docs
On Wed, Aug 20, 2008 at 1:36 AM, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > Does "no need for bug reports" apply only to presentation or to content > as well? I'm asking because I've found an old-style `class Admin` your > request declaration in an example in "Django at a glance" and I'm not > sure if such bugs are known. Just to presentation -- there's a bunch of stuff that looks wrong that I know about. Content bugs are important; patches welcome! Jacob --~--~-~--~~~---~--~~ 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: Call for testing: new docs
On Tue, Aug 19, 2008 at 5:01 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: ... > The best way to send me code is by letting me know about your remote > git repo. Or use git-format-patch and send me patches. I can't really > spare time to help with git, but someone in #django-dev probably can > if you need it. We all enjoy Django over PHP, etc., but I think we should avoid too much snark in our opening tutorials. We should be impressing people with our improvements over alternatives, not judging their previous (and possibly current) tech decisions. Example from http://docs.djangoproject.com/dev/intro/overview.html: " In this case, the date filter formats a Python datetime object in the given format (as found in PHP's date function; yes, there is one good idea in PHP). " That doesn't help make the case, and might piss off people just starting to look at Django. They may some day come to agree, but PHP does have some things to recommend it, and at this stage, people have nothing else to judge the Django community by. --~--~-~--~~~---~--~~ 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: recent MultiValueDict.iteritems change (changeset 8399)
On Tue, 2008-08-19 at 22:09 -0700, James Turk wrote: [...] > It seems that changing my code to use lists will give almost the same > result, but would it be possible to get an "iterlists" method to > replace the iteritems which was changed? This is probably worth leaving until after 1.0 for now. It's not completely clear what iterlists should do -- is it iteritems-as-lists or itervalues-as-lists (the latter being possibly a more natural equivalent of the the getlist() method)? Since you can loop over the keys and the use getlist() to get each element, we haven't removed access to any data, so I'd be inclined to wait a bit and then we can look at it. File a patch anyway and maybe it will go in, but probably it will wait and we have it ready for later. > Also because of this should 8399, trivial as it is, go up on > BackwardsIncompatibleChanges? Yes, it should. Hopefully Gary (Wilson) will see this and make the change, since it was his commit. It was no doubt just forgotten at the time. Nothing malicious. Regards, Malcolm --~--~-~--~~~---~--~~ 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: HTTP PUT request
On Wed, 2008-08-20 at 02:29 -0700, zvoase wrote: [...] > What I'm doing now is changing the method to POST, accessing the > request.raw_post_data attribute, and then changing the method back to > PUT. This seems a little unnecessary, and I'd like to suggest the > addition of a content attribute which holds any raw content provided, > whether through POST or PUT. The raw_post_data attribute will contain the raw data regardless of the method used in the HTTP request. So it works identically for PUT and POST. Have a look at the implementation: there's nothing that restricts it to a single method. It would even work for OPTION or other HTTP verbs. Regards, Malcolm --~--~-~--~~~---~--~~ 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: recent MultiValueDict.iteritems change (changeset 8399)
On Wed, Aug 20, 2008 at 8:08 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: ... >> Also because of this should 8399, trivial as it is, go up on >> BackwardsIncompatibleChanges? > > Yes, it should. Hopefully Gary (Wilson) will see this and make the > change, since it was his commit. It was no doubt just forgotten at the > time. Nothing malicious. I was in the neighborhood, so updated: http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#CorrectedMultiValueDict.iteritemstoreturnitemsratherthanlists --~--~-~--~~~---~--~~ 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: recent MultiValueDict.iteritems change (changeset 8399)
Quite understandable that this isn't a priority by any means, ticket including patch is up here for posterity: http://code.djangoproject.com/ticket/8447 On Aug 20, 9:20 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > On Wed, Aug 20, 2008 at 8:08 AM, Malcolm Tredinnick<[EMAIL PROTECTED]> wrote: > > ... > > >> Also because of this should 8399, trivial as it is, go up on > >> BackwardsIncompatibleChanges? > > > Yes, it should. Hopefully Gary (Wilson) will see this and make the > > change, since it was his commit. It was no doubt just forgotten at the > > time. Nothing malicious. > > I was in the neighborhood, so > updated:http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Corre... --~--~-~--~~~---~--~~ 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: recent MultiValueDict.iteritems change (changeset 8399)
On Wed, Aug 20, 2008 at 10:01 AM, James Turk <[EMAIL PROTECTED]> wrote: > > Quite understandable that this isn't a priority by any means, ticket > including patch is up here for posterity: > http://code.djangoproject.com/ticket/8447 The patch was a bit off; it used iteritems in iterlists in tests.py. I replaced the patch just now. --~--~-~--~~~---~--~~ 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: BaseModelFormSet and ModelForm.instance
On Wed, Aug 20, 2008 at 12:57 AM, Justin Fagnani <[EMAIL PROTECTED]> wrote: > I'm not sure what parts of BaseModelFormSet are considered official > API. In the patch ModelForm.save() is now called by > ModelFormSet.save(), and I think the methods save_new, save_existing, > save_existing_objects, and save_new_objects are no longer needed. I sort of wonder myself too. I think it might definitely introduce some breakage. But ultimately this fixes formsets to work more naturally which is good. I am slightly unclear on what is allowed to be broken in this phase of Django development. I suspect it is okay since those methods are not explicitly documented and a quick note on the wiki would be decent. Someone please correct me if I am wrong, but will make this item post-1.0. > I don't think get_queryset is needed either. This however I just don't understand. What is the reasoning for this change. Removing the method will certain break code and is documented, but it seems the patch doesn't need this to be removed. I see there is no need for in the save stage, but surely can still be used as an extensibility hook. Passing the queryset directly in as initial data has problems too and needs to be ran through model_to_dict to fix those issues. I don't see why that needed to be removed. > > I know it's a rough patch, so any advice on how to improve it, or what > tests to add? Just out of curiosity do the tests pass with your patch? If so, I suspect the coverage isn't good enough ;) -- Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ 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: BaseModelFormSet and ModelForm.instance
On Wed, Aug 20, 2008 at 12:57 AM, Justin Fagnani <[EMAIL PROTECTED]> wrote: > ps. The *_factory methods seem odd to me. I wonder why metaclasses > weren't used here, but I understand that it's to close to 1.0 change > anything. Ah, missed this in the first e-mail. There was an effort to do this, but failed miserably. It may be revisited again, but IMO providing a declarative syntax to everything in the world doesn't fix the world ;) It simply would provide a better API for users which I understand is good. However, the factory function do provide functionality in places where things need to be dynamic. The admin relies on them heavily. If in any event we do go about a declarative syntax it would need to be a subset of the factories. However, right now I am -0 on introducing them since to me adds cruft to formsets. At any rate it would certainly be a post-1.0 if we did decide to so something. -- Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ 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: You've broken Oracle
> Rather than flag "row_number()" as an extra_select parameter (and then
> try to clean up after it later), Oracle now just uses the default
> set_limits and clear_limits methods and does all extra query munging
> in its as_sql() method. And instead of doing an outer SELECT *, we
> SELECT specific columns (or aliases) by name and ignore our
> row_number() column, which is only used in the WHERE clause.
>
> This seems to fix most of the failures. I'll check it in soon when
> I'm sure it's not causing any new problems.
>
This approach breaks slicing for Oracle in GeoDjango. Specifically,
getting rid of the `SELECT *` and manually specifying the columns has
introduced side effects. The following example will show the problems
-- here is a simple geographic model:
class City(models.Model):
name = models.CharField(max_length=30)
point = models.PointField()
objects = models.GeoManager()
In 8425, here's the SQL that `City.objects.all()[0]` would produce:
SELECT * FROM (SELECT (ROW_NUMBER() OVER (ORDER BY "GEO_CITY"."ID" ))
AS "RN", "GEO_CITY"."ID", "GEO_CITY"."NAME",
SDO_UTIL.TO_WKTGEOMETRY("GEO_CITY"."POINT") FROM "GEO_CITY") WHERE rn
> 0 AND rn <= 1
As you can see, I need to wrap the geometry column with a function
call that converts the column into an acceptable format. With the
changes in r8445, this is the broken SQL that is produced:
SELECT "ID", "NAME", "POINT") FROM (SELECT ROW_NUMBER() OVER (ORDER BY
"GEO_CITY"."ID") rn, "GEO_CITY"."ID", "GEO_CITY"."NAME",
SDO_UTIL.TO_WKTGEOMETRY("GEO_CITY"."POINT") FROM "GEO_CITY") WHERE rn
> 0 AND rn <= 1
There are a few problems here. The first is that the `col.rsplit('.',
1)[1]` logic is too brittle to handle a column wrapped in a stored
procedure. But the greater issue is that to fix this in GeoQuery is
that I need to make `get_columns` aware if it's being called for an
outer select or the inner select, i.e., I'll have to set an alias on
the inner select while not putting any function wrapping on the outer
select. I currently don't know how to do this other than adding extra
keyword parameters in my overridden implementation that may be used by
an overridden `as_sql` used only for Oracle just for this purpose.
Needless to say, this isn't trivial -- unless there's other ideas on a
different approach I may have to drop Oracle support for GeoDjango in
1.0. I'm hesitant to be rewiring internals this close to the deadline
instead of focusing on documentation.
-Justin
--~--~-~--~~~---~--~~
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: You've broken Oracle
Hi Justin,
Sorry, I should have run the gis tests as well. (Is that Malcom
snickering I hear? I'm chastened.)
Did GeoDjango break in r8426 then, as Oracle in general did? That's
where extra_select changed. I can see how our new code in r8445
breaks on your function column.
I'll look at it today and see if I can come up with a fix.
Matt
On Aug 20, 10:27 am, Justin Bronn <[EMAIL PROTECTED]> wrote:
> > Rather than flag "row_number()" as an extra_select parameter (and then
> > try to clean up after it later), Oracle now just uses the default
> > set_limits and clear_limits methods and does all extra query munging
> > in its as_sql() method. And instead of doing an outer SELECT *, we
> > SELECT specific columns (or aliases) by name and ignore our
> > row_number() column, which is only used in the WHERE clause.
>
> > This seems to fix most of the failures. I'll check it in soon when
> > I'm sure it's not causing any new problems.
>
> This approach breaks slicing for Oracle in GeoDjango. Specifically,
> getting rid of the `SELECT *` and manually specifying the columns has
> introduced side effects. The following example will show the problems
> -- here is a simple geographic model:
>
> class City(models.Model):
> name = models.CharField(max_length=30)
> point = models.PointField()
> objects = models.GeoManager()
>
> In 8425, here's the SQL that `City.objects.all()[0]` would produce:
>
> SELECT * FROM (SELECT (ROW_NUMBER() OVER (ORDER BY "GEO_CITY"."ID" ))
> AS "RN", "GEO_CITY"."ID", "GEO_CITY"."NAME",
> SDO_UTIL.TO_WKTGEOMETRY("GEO_CITY"."POINT") FROM "GEO_CITY") WHERE rn
>
> > 0 AND rn <= 1
>
> As you can see, I need to wrap the geometry column with a function
> call that converts the column into an acceptable format. With the
> changes in r8445, this is the broken SQL that is produced:
>
> SELECT "ID", "NAME", "POINT") FROM (SELECT ROW_NUMBER() OVER (ORDER BY
> "GEO_CITY"."ID") rn, "GEO_CITY"."ID", "GEO_CITY"."NAME",
> SDO_UTIL.TO_WKTGEOMETRY("GEO_CITY"."POINT") FROM "GEO_CITY") WHERE rn
>
> > 0 AND rn <= 1
>
> There are a few problems here. The first is that the `col.rsplit('.',
> 1)[1]` logic is too brittle to handle a column wrapped in a stored
> procedure. But the greater issue is that to fix this in GeoQuery is
> that I need to make `get_columns` aware if it's being called for an
> outer select or the inner select, i.e., I'll have to set an alias on
> the inner select while not putting any function wrapping on the outer
> select. I currently don't know how to do this other than adding extra
> keyword parameters in my overridden implementation that may be used by
> an overridden `as_sql` used only for Oracle just for this purpose.
> Needless to say, this isn't trivial -- unless there's other ideas on a
> different approach I may have to drop Oracle support for GeoDjango in
> 1.0. I'm hesitant to be rewiring internals this close to the deadline
> instead of focusing on documentation.
>
> -Justin
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Session expiration times
I recently ran into what I thought was counter-intuitive session expiration behavior. See ticket http://code.djangoproject.com/ticket/8452 for the details. I don't mean to dig up topics that have been long debated, but I also wonder if these semantics make sense? If I log into a site and only happen to read from my session, my session will log out in SESSION_COOKIE_AGE seconds (or whatever set_expiry says). However, if I happen to do actions that cause writes to my session then my session will expire in some hard-to-determine point in the future. How to explain to a user when they will be logged out -- X seconds after their last session write? I wrote the app and I'm not even sure when the session is written to due to third party libraries etc. Further, for security reasons it seems like it's a good policy for Django to ship with the default behavior for every session to automatically expire SESSION_COOKIE_AGE seconds after the session was created no matter what. If the app wants to push out the expiration time every time the user is active, they can call set_expiry explicitly. But I guess that's just one person's opinion. Alternatively, for consistency, Django could update the expiry age whenever the session is _read_ or written. Then the docs could simply say the expiry age is updated whenever the session is used which is very simple to understand: anytime someone comes back to the site their session expiration time will renew. If they don't come back within the expiration time, their session expires. --~--~-~--~~~---~--~~ 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: You've broken Oracle
On Wed, 2008-08-20 at 09:47 -0700, Matt Boersma wrote: > Hi Justin, > > Sorry, I should have run the gis tests as well. (Is that Malcom > snickering I hear? I'm chastened.) I'm not snickering. We're chasing a lot of things here and cascading changes are kind of to be expected. Just like they were before. > Did GeoDjango break in r8426 then, as Oracle in general did? That's > where extra_select changed. I can see how our new code in r8445 > breaks on your function column. I'm fixing the last remaining Oracle failures at the moment. At least, changing them -- I can't test them. I'll see if Leo's buildbot succeeds then (there'll still be failures due to e.g. PIL not being installed, but that's not db related). There are a few things due to fragile tests checking string output rather than Exception type. There's one SQL syntax error that I can't fix, however (in regressiontests/queries/models.py). I'll look at the pickling issue there, but the SQL problem I can't debug. Regards, Malcolm --~--~-~--~~~---~--~~ 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: You've broken Oracle
On Aug 20, 10:50 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> There's one SQL syntax error that I can't fix, however (in
> regressiontests/queries/models.py). I'll look at the pickling issue
> there, but the SQL problem I can't debug.
If you mean this one:
Item.objects.dates('created', 'day')[0]
DatabaseError: ORA-00923: FROM keyword not found where expected
then I'm on it. Thanks for looking at the other tests.
The pickling problem arises because we construct our OracleQuery class
dynamically, so it doesn't match the module path when pickle attempts
to resurrect it. Ian Kelly and I stared at this one for a while but
didn't come up with a good fix yet.
(If anyone out there uses Komodo, here's my tip of the day. Use
manual breakpoints:
from dbgp.client import brk; brk()
That's the only way I've found to fire up the debugger reliably when
inside doctests.)
Matt
--~--~-~--~~~---~--~~
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: BaseModelFormSet and ModelForm.instance
On Wed, Aug 20, 2008 at 8:39 AM, Brian Rosner <[EMAIL PROTECTED]> wrote: > I am slightly unclear on what is allowed to > be broken in this phase of Django development. I suspect it is okay > since those methods are not explicitly documented and a quick note on > the wiki would be decent. Someone please correct me if I am wrong, but > will make this item post-1.0. I could rewrite the patch to preserve those methods, but it'd be a lot less elegant. I could see the argument that save_existing_objects(), and save_new_objects() are useful in some ways. >> I don't think get_queryset is needed either. > > This however I just don't understand. What is the reasoning for this > change. Removing the method will certain break code and is documented, > but it seems the patch doesn't need this to be removed. I see there is > no need for in the save stage, but surely can still be used as an > extensibility hook. Passing the queryset directly in as initial data > has problems too and needs to be ran through model_to_dict to fix > those issues. I don't see why that needed to be removed. You are entirely correct. I forgot about the documentation of overriding get_queryset(). I actually didn't remove it, and if I had InlineFormSets would have broken, but I have to fix the patch to use it instead of self.queryset in some places. >> I know it's a rough patch, so any advice on how to improve it, or what >> tests to add? > > Just out of curiosity do the tests pass with your patch? If so, I > suspect the coverage isn't good enough ;) Yup, the tests pass. If I'm looking in the right places, the coverage seems pretty bad. ModelFormSets and InlineFormSets are not tested at all. Do you have a suggestion for not passing a queryset as the 'initial' argument to FormSet? I'm thinking that either the queryset is translated to a list of dicts like before, so the forms will have both an instance and initial data, or BaseFormSet.__init__() should be broken up so that _initial_form_count is set in another method that can be overridden. I like the later. -Justin --~--~-~--~~~---~--~~ 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: Session expiration times
TP wrote: > I recently ran into what I thought was counter-intuitive session > expiration behavior. See ticket http://code.djangoproject.com/ticket/8452 > for the details. > > I don't mean to dig up topics that have been long debated, but I also > wonder if these semantics make sense? > > If I log into a site and only happen to read from my session, my > session will log out in SESSION_COOKIE_AGE seconds (or whatever > set_expiry says). However, if I happen to do actions that cause writes > to my session then my session will expire in some hard-to-determine > point in the future. How to explain to a user when they will be logged > out -- X seconds after their last session write? I wrote the app and > I'm not even sure when the session is written to due to third party > libraries etc. > > Further, for security reasons it seems like it's a good policy for > Django to ship with the default behavior for every session to > automatically expire SESSION_COOKIE_AGE seconds after the session was > created no matter what. If the app wants to push out the expiration > time every time the user is active, they can call set_expiry > explicitly. But I guess that's just one person's opinion. > > Alternatively, for consistency, Django could update the expiry age > whenever the session is _read_ or written. Then the docs could simply > say the expiry age is updated whenever the session is used which is > very simple to understand: anytime someone comes back to the site > their session expiration time will renew. If they don't come back > within the expiration time, their session expires. SESSION_SAVE_EVERY_REQUEST is by far the most sensible option, and the default behavior for every other web framework I've used. Interaction of any kind with the server should be taken as an indication that the session user wants the session to remain alive. At least it's documented, though ... regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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: You've broken Oracle
On Wed, 2008-08-20 at 10:03 -0700, Matt Boersma wrote:
> On Aug 20, 10:50 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > There's one SQL syntax error that I can't fix, however (in
> > regressiontests/queries/models.py). I'll look at the pickling issue
> > there, but the SQL problem I can't debug.
>
> If you mean this one:
>
> Item.objects.dates('created', 'day')[0]
> DatabaseError: ORA-00923: FROM keyword not found where expected
>
> then I'm on it. Thanks for looking at the other tests.
So r8450 should fix the remaining database tests with the exception of
the pickling one. That should fix forced_insert_update and
get_or_create.
I've started working on a proto-solution for the pickle situation and it
almost works, but I'm stuck for the moment, so I'll go back to that
tomorrow or Friday (I'm writing a custom __reduce__ method to take
control of pickling for that class).
The other two failing tests are for other reasons: model_forms requires
PIL to give the right results. It's a fragile test in Django that we
should rewrite at some point to be more flexible. The files test is just
failing because it doesn't clean up after itself when it fails
sometimes, so the expected filename after a save is different. We can
make that a little more robust at some point, too. For now, they're
lower priority, since they could be fixed on the buildbot end if it was
of real concern and there are actual bugs to fix right now.
Regards,
Malcolm
--~--~-~--~~~---~--~~
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: You've broken Oracle
> Item.objects.dates('created', 'day')[0]
> DatabaseError: ORA-00923: FROM keyword not found where expected
That's the exact error that's giving me problems -- I think it's one
of the same issue as I'm having. It's because of the `col.rsplit('.',
1)[1]` logic in Oracle's `as_sql` when doing offsets. In other words
when the column is wrapped in a function (like the datetime SQL is)
then there will be a parenthesis after the quote still in the column
name.
> Did GeoDjango break in r8426 then, as Oracle in general did? That's
> where extra_select changed. I can see how our new code in r8445
> breaks on your function column.
Yes, GeoDjango broke in 8426, but a simple fix was committed in 8431
that fixed it PostGIS and MySQL -- basically I just needed to make
compatible for the data structure changes.
I came to the same conclusion on the pickling problems being caused by
the fact that OracleQuery doesn't exist at the module level, but
rather is returned from a function call dynamically.
-Justin
--~--~-~--~~~---~--~~
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: You've broken Oracle
On Aug 20, 1:01 pm, Justin Bronn <[EMAIL PROTECTED]> wrote:
> > Item.objects.dates('created', 'day')[0]
> > DatabaseError: ORA-00923: FROM keyword not found where expected
>
> That's the exact error that's giving me problems -- I think it's one
> of the same issue as I'm having. It's because of the `col.rsplit('.',
> 1)[1]` logic in Oracle's `as_sql` when doing offsets. In other words
> when the column is wrapped in a function (like the datetime SQL is)
> then there will be a parenthesis after the quote still in the column
> name.
That's true, and it's obviously a bug, but sadly there are a couple
other errors involved in this particular failure. First is that one
column is a TRUNC(date) function without a column alias, so there's no
way to SELECT that in the outer query. Second is that the query uses
DISTINCT, but we blindly injected our ROW_NUMBER() function as the
first column, which creates invalid SQL since DISTINCT must appear
before the column list. Then there's our mis-parsing of the column
name with parentheses.
I now think reintroducing the extra_select approach might work better,
and perhaps could fix the GeoDjango issues as well.
--~--~-~--~~~---~--~~
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: uploaded file permissions
On Aug 14, 5:29 pm, Dan Watson <[EMAIL PROTECTED]> wrote: > As mentioned a few times in #2070, uploaded files large enough to be > streamed to a temporary file get created with a mode of 0600, as per > python's tempfile.mkstemp. This causes two problems: > > 1. Files uploaded into memory and saved to disk respect the umask, so > uploads could have different permissions based on how big they are. > > 2. If the webserver user and django user do not match (such as when > running an external FastCGI process), the webserver can no longer > serve uploaded files. > > I got around this issue by subclassing FileSystemStorage._save to call > os.chmod, but it seems there should either be a setting (eg: > FILE_UPLOAD_MODE), or a mode that respects the current umask should be > specified when saving (and moving) the files. I can create a ticket > and patch either way. This inconsistency seems like a bug to me, so I've created ticket #8454 [1] with a patch that implements a FILE_UPLOAD_PERMISSIONS setting, and marked it as 1.0. This seemed like the least intrusive way to go, and the default behavior is unchanged. Regards, Dan [1] http://code.djangoproject.com/ticket/8454 --~--~-~--~~~---~--~~ 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: uploaded file permissions
On Wed, 2008-08-20 at 12:13 -0700, Dan Watson wrote: > On Aug 14, 5:29 pm, Dan Watson <[EMAIL PROTECTED]> wrote: > > As mentioned a few times in #2070, uploaded files large enough to be > > streamed to a temporary file get created with a mode of 0600, as per > > python's tempfile.mkstemp. This causes two problems: > > > > 1. Files uploaded into memory and saved to disk respect the umask, so > > uploads could have different permissions based on how big they are. > > > > 2. If the webserver user and django user do not match (such as when > > running an external FastCGI process), the webserver can no longer > > serve uploaded files. > > > > I got around this issue by subclassing FileSystemStorage._save to call > > os.chmod, but it seems there should either be a setting (eg: > > FILE_UPLOAD_MODE), or a mode that respects the current umask should be > > specified when saving (and moving) the files. I can create a ticket > > and patch either way. > > This inconsistency seems like a bug to me, so I've created ticket > #8454 [1] with a patch that implements a FILE_UPLOAD_PERMISSIONS > setting, and marked it as 1.0. This seemed like the least intrusive > way to go, and the default behavior is unchanged. Why did you go with another setting rather than using the umask (which hopefully would be set correctly -- the fastcgi server handles that now)? Is there some technical difficulty I'm not seeing here that means we can't get the umask and use that? It would seem nicer than having to worry about another setting that can get out of sync with things if it was possible. I'm not disputing (yet :-)) that your approach is correct. Rather, wondering what I'm missing. Regards, Malcolm --~--~-~--~~~---~--~~ 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: BaseModelFormSet and ModelForm.instance
On Wed, Aug 20, 2008 at 11:42 AM, Justin Fagnani <[EMAIL PROTECTED]> wrote: > > On Wed, Aug 20, 2008 at 8:39 AM, Brian Rosner <[EMAIL PROTECTED]> wrote: >> I am slightly unclear on what is allowed to >> be broken in this phase of Django development. I suspect it is okay >> since those methods are not explicitly documented and a quick note on >> the wiki would be decent. Someone please correct me if I am wrong, but >> will make this item post-1.0. > > I could rewrite the patch to preserve those methods, but it'd be a lot > less elegant. I could see the argument that save_existing_objects(), > and save_new_objects() are useful in some ways. One thing that I may have missed, but how are you dealing with save_new in BaseInlineFormSet? From a quick glance that would seem broken. > Yup, the tests pass. If I'm looking in the right places, the coverage > seems pretty bad. ModelFormSets and InlineFormSets are not tested at > all. Did you look at http://code.djangoproject.com/browser/django/trunk/tests/modeltests/model_formsets/models.py? > > Do you have a suggestion for not passing a queryset as the 'initial' > argument to FormSet? I'm thinking that either the queryset is > translated to a list of dicts like before, so the forms will have both > an instance and initial data, or BaseFormSet.__init__() should be > broken up so that _initial_form_count is set in another method that > can be overridden. I like the later. I think the better solution here is to keep the __init__ code the same but we need an instance level of the queryset persistent so we can use the use the caching it would provide. Then use the the indexing like you have with i local variable in _construct_form. -- Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ 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: You've broken Oracle
On Wed, 2008-08-20 at 12:10 -0700, Matt Boersma wrote: [...] > I now think reintroducing the extra_select approach might work better, > and perhaps could fix the GeoDjango issues as well. There's still the offer to add an extra paramater axis to the tuple inside extra_select if that helps at all -- so you can distinguish internal and external args or something. Regards, Malcolm --~--~-~--~~~---~--~~ 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: uploaded file permissions
On Aug 20, 3:34 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Wed, 2008-08-20 at 12:13 -0700, Dan Watson wrote: > > On Aug 14, 5:29 pm, Dan Watson <[EMAIL PROTECTED]> wrote: > > > As mentioned a few times in #2070, uploaded files large enough to be > > > streamed to a temporary file get created with a mode of 0600, as per > > > python's tempfile.mkstemp. This causes two problems: > > > > 1. Files uploaded into memory and saved to disk respect the umask, so > > > uploads could have different permissions based on how big they are. > > > > 2. If the webserver user and django user do not match (such as when > > > running an external FastCGI process), the webserver can no longer > > > serve uploaded files. > > > > I got around this issue by subclassing FileSystemStorage._save to call > > > os.chmod, but it seems there should either be a setting (eg: > > > FILE_UPLOAD_MODE), or a mode that respects the current umask should be > > > specified when saving (and moving) the files. I can create a ticket > > > and patch either way. > > > This inconsistency seems like a bug to me, so I've created ticket > > #8454 [1] with a patch that implements a FILE_UPLOAD_PERMISSIONS > > setting, and marked it as 1.0. This seemed like the least intrusive > > way to go, and the default behavior is unchanged. > > Why did you go with another setting rather than using the umask (which > hopefully would be set correctly -- the fastcgi server handles that > now)? Is there some technical difficulty I'm not seeing here that means > we can't get the umask and use that? It would seem nicer than having to > worry about another setting that can get out of sync with things if it > was possible. I guess I was envisioning a situation where you'd want to chmod uploaded files differently than other sorts of files your application may be writing out. Also, it appears the only way to get the current umask is by setting it at the same time, which seems like a good way to introduce a race condition (set to X to retrieve Y, another caller gets X instead of Y). > I'm not disputing (yet :-)) that your approach is correct. Rather, > wondering what I'm missing. I don't think either solution is bad, so long as there is a solution and it's documented. I'm not heavily in favor of one or the other, so if you'd rather see the current umask used, I'll submit a new patch. Another option would be to give the setting a reasonable default value (likely 0600, 0644, or 0640). Regards, Dan --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Ticket 7947 - 1:1 field bug
I know everyone's got their pet tickets they want to make sure get into trunk but I wanted to bring up http://code.djangoproject.com/ticket/7947 which deals with some breakage in editing 1:1 fields. I can attest that the patch does fix the problem we see in Satchmo but there are some other cases noted in the ticket where it may need to be improved (but don't readily impact Satchmo). My concern is that this patch might miss the boat if we try to get it perfect. Would it be acceptable to apply this one and open another ticket to deal with the other cases? If not, any pointers on how I can help move it along? Thanks, Chris --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Flatpages with multiple blocks/sections
I have found that the Flatpages application is very useful, especially
in projects where you create a site for someone else and you allow
them to change the content as they need. The only drawback with the
application, however, is that there's only one block/section of
modifiable content.
My solution was to pretty much copy the django.contrib.flatpages
application into my project and adjust it to conform to my
specifications. As one would guess, that's not very clean, as I'd
want my copy to change as Django's changed, but I saw no other way as
I could not easily extend what was already there.
For my use, I'll just touch on the basic changes I made. I left out
any "logical" imports below. Also note that changed
"django.contrib.flatpages" to "flatpages" where necessary so my
changes did not refer to the original.
# myproject.flatpages.models.py
class Section(models.Model):
slug = models.SlugField(_('slug'), max_length=50)
content = models.TextField(_('content'), blank=True)
flatpage = models.ForeignKey(FlatPage)
# myproject.flatpages.admin.py
class SectionInline(admin.StackedInline):
model = Section
class SectionAdmin(admin.ModelAdmin):
fieldsets = (
(None, {'fields': ('slug', 'content', 'flatpage')}),
)
list_display = ('slug', 'flatpage',)
list_filter = ('flatpage',)
search_fields = ('slug', 'content')
admin.site.register(Section, SectionAdmin)
(also add inlines = [SectionInline,] to FlatPageAdmin class)
# views.py - before creating Request Context
# Create a dictionary, indexed by section slug, of section content
d = {}
for s in f.section_set.all():
d[s.slug] = mark_safe(s.content)
...etc...
c = RequestContext(request, {
'flatpage': f,
'section': d,
})
So of course, in my templates I could just render a block/section of
content as {{ section.section_1 }}.
Do we think something like this could be useful for the general
population, either as part of flatpages or as a separate app?
Keith
--~--~-~--~~~---~--~~
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: Flatpages with multiple blocks/sections
You may want to check out django-chunks. I'm pretty sure it does what
you are looking for.
-justin
On Aug 20, 2008, at 4:41 PM, lingrlongr <[EMAIL PROTECTED]> wrote:
>
> I have found that the Flatpages application is very useful, especially
> in projects where you create a site for someone else and you allow
> them to change the content as they need. The only drawback with the
> application, however, is that there's only one block/section of
> modifiable content.
>
> My solution was to pretty much copy the django.contrib.flatpages
> application into my project and adjust it to conform to my
> specifications. As one would guess, that's not very clean, as I'd
> want my copy to change as Django's changed, but I saw no other way as
> I could not easily extend what was already there.
>
> For my use, I'll just touch on the basic changes I made. I left out
> any "logical" imports below. Also note that changed
> "django.contrib.flatpages" to "flatpages" where necessary so my
> changes did not refer to the original.
>
> # myproject.flatpages.models.py
> class Section(models.Model):
>slug = models.SlugField(_('slug'), max_length=50)
>content = models.TextField(_('content'), blank=True)
>flatpage = models.ForeignKey(FlatPage)
>
>
> # myproject.flatpages.admin.py
>
> class SectionInline(admin.StackedInline):
>model = Section
>
> class SectionAdmin(admin.ModelAdmin):
>fieldsets = (
>(None, {'fields': ('slug', 'content', 'flatpage')}),
>)
>list_display = ('slug', 'flatpage',)
>list_filter = ('flatpage',)
>search_fields = ('slug', 'content')
>
> admin.site.register(Section, SectionAdmin)
>
> (also add inlines = [SectionInline,] to FlatPageAdmin class)
>
>
> # views.py - before creating Request Context
>
># Create a dictionary, indexed by section slug, of section content
>d = {}
>for s in f.section_set.all():
>d[s.slug] = mark_safe(s.content)
>
>...etc...
>
>c = RequestContext(request, {
>'flatpage': f,
>'section': d,
>})
>
> So of course, in my templates I could just render a block/section of
> content as {{ section.section_1 }}.
>
>
> Do we think something like this could be useful for the general
> population, either as part of flatpages or as a separate app?
>
> Keith
>
> >
--~--~-~--~~~---~--~~
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: Flatpages with multiple blocks/sections
I think that will work well. Thanks! =)
On Aug 20, 10:40 pm, Justin Lilly <[EMAIL PROTECTED]> wrote:
> You may want to check out django-chunks. I'm pretty sure it does what
> you are looking for.
>
> -justin
>
> On Aug 20, 2008, at 4:41 PM, lingrlongr <[EMAIL PROTECTED]> wrote:
>
>
>
> > I have found that the Flatpages application is very useful, especially
> > in projects where you create a site for someone else and you allow
> > them to change the content as they need. The only drawback with the
> > application, however, is that there's only one block/section of
> > modifiable content.
>
> > My solution was to pretty much copy the django.contrib.flatpages
> > application into my project and adjust it to conform to my
> > specifications. As one would guess, that's not very clean, as I'd
> > want my copy to change as Django's changed, but I saw no other way as
> > I could not easily extend what was already there.
>
> > For my use, I'll just touch on the basic changes I made. I left out
> > any "logical" imports below. Also note that changed
> > "django.contrib.flatpages" to "flatpages" where necessary so my
> > changes did not refer to the original.
>
> > # myproject.flatpages.models.py
> > class Section(models.Model):
> > slug = models.SlugField(_('slug'), max_length=50)
> > content = models.TextField(_('content'), blank=True)
> > flatpage = models.ForeignKey(FlatPage)
>
> > # myproject.flatpages.admin.py
>
> > class SectionInline(admin.StackedInline):
> > model = Section
>
> > class SectionAdmin(admin.ModelAdmin):
> > fieldsets = (
> > (None, {'fields': ('slug', 'content', 'flatpage')}),
> > )
> > list_display = ('slug', 'flatpage',)
> > list_filter = ('flatpage',)
> > search_fields = ('slug', 'content')
>
> > admin.site.register(Section, SectionAdmin)
>
> > (also add inlines = [SectionInline,] to FlatPageAdmin class)
>
> > # views.py - before creating Request Context
>
> > # Create a dictionary, indexed by section slug, of section content
> > d = {}
> > for s in f.section_set.all():
> > d[s.slug] = mark_safe(s.content)
>
> > ...etc...
>
> > c = RequestContext(request, {
> > 'flatpage': f,
> > 'section': d,
> > })
>
> > So of course, in my templates I could just render a block/section of
> > content as {{ section.section_1 }}.
>
> > Do we think something like this could be useful for the general
> > population, either as part of flatpages or as a separate app?
>
> > Keith
--~--~-~--~~~---~--~~
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: Flatpages with multiple blocks/sections
Also django-assets
On Aug 20, 2008, at 21:57, lingrlongr <[EMAIL PROTECTED]> wrote:
>
> I think that will work well. Thanks! =)
>
> On Aug 20, 10:40 pm, Justin Lilly <[EMAIL PROTECTED]> wrote:
>> You may want to check out django-chunks. I'm pretty sure it does what
>> you are looking for.
>>
>> -justin
>>
>> On Aug 20, 2008, at 4:41 PM, lingrlongr <[EMAIL PROTECTED]>
>> wrote:
>>
>>
>>
>>> I have found that the Flatpages application is very useful,
>>> especially
>>> in projects where you create a site for someone else and you allow
>>> them to change the content as they need. The only drawback with the
>>> application, however, is that there's only one block/section of
>>> modifiable content.
>>
>>> My solution was to pretty much copy the django.contrib.flatpages
>>> application into my project and adjust it to conform to my
>>> specifications. As one would guess, that's not very clean, as I'd
>>> want my copy to change as Django's changed, but I saw no other way
>>> as
>>> I could not easily extend what was already there.
>>
>>> For my use, I'll just touch on the basic changes I made. I left out
>>> any "logical" imports below. Also note that changed
>>> "django.contrib.flatpages" to "flatpages" where necessary so my
>>> changes did not refer to the original.
>>
>>> # myproject.flatpages.models.py
>>> class Section(models.Model):
>>>slug = models.SlugField(_('slug'), max_length=50)
>>>content = models.TextField(_('content'), blank=True)
>>>flatpage = models.ForeignKey(FlatPage)
>>
>>> # myproject.flatpages.admin.py
>>
>>> class SectionInline(admin.StackedInline):
>>>model = Section
>>
>>> class SectionAdmin(admin.ModelAdmin):
>>>fieldsets = (
>>>(None, {'fields': ('slug', 'content', 'flatpage')}),
>>>)
>>>list_display = ('slug', 'flatpage',)
>>>list_filter = ('flatpage',)
>>>search_fields = ('slug', 'content')
>>
>>> admin.site.register(Section, SectionAdmin)
>>
>>> (also add inlines = [SectionInline,] to FlatPageAdmin class)
>>
>>> # views.py - before creating Request Context
>>
>>># Create a dictionary, indexed by section slug, of section
>>> content
>>>d = {}
>>>for s in f.section_set.all():
>>>d[s.slug] = mark_safe(s.content)
>>
>>>...etc...
>>
>>>c = RequestContext(request, {
>>>'flatpage': f,
>>>'section': d,
>>>})
>>
>>> So of course, in my templates I could just render a block/section of
>>> content as {{ section.section_1 }}.
>>
>>> Do we think something like this could be useful for the general
>>> population, either as part of flatpages or as a separate app?
>>
>>> Keith
> >
--~--~-~--~~~---~--~~
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: Flatpages with multiple blocks/sections
However, it'd still be nice to see these chunks be somehow related to
a flatpage. Maybe one day the we'll have a "chunky-flatpages" app so
they can share some sort of relation...
On Aug 20, 10:57 pm, lingrlongr <[EMAIL PROTECTED]> wrote:
> I think that will work well. Thanks! =)
>
> On Aug 20, 10:40 pm, Justin Lilly <[EMAIL PROTECTED]> wrote:
>
> > You may want to check out django-chunks. I'm pretty sure it does what
> > you are looking for.
>
> > -justin
>
> > On Aug 20, 2008, at 4:41 PM, lingrlongr <[EMAIL PROTECTED]> wrote:
>
> > > I have found that the Flatpages application is very useful, especially
> > > in projects where you create a site for someone else and you allow
> > > them to change the content as they need. The only drawback with the
> > > application, however, is that there's only one block/section of
> > > modifiable content.
>
> > > My solution was to pretty much copy the django.contrib.flatpages
> > > application into my project and adjust it to conform to my
> > > specifications. As one would guess, that's not very clean, as I'd
> > > want my copy to change as Django's changed, but I saw no other way as
> > > I could not easily extend what was already there.
>
> > > For my use, I'll just touch on the basic changes I made. I left out
> > > any "logical" imports below. Also note that changed
> > > "django.contrib.flatpages" to "flatpages" where necessary so my
> > > changes did not refer to the original.
>
> > > # myproject.flatpages.models.py
> > > class Section(models.Model):
> > > slug = models.SlugField(_('slug'), max_length=50)
> > > content = models.TextField(_('content'), blank=True)
> > > flatpage = models.ForeignKey(FlatPage)
>
> > > # myproject.flatpages.admin.py
>
> > > class SectionInline(admin.StackedInline):
> > > model = Section
>
> > > class SectionAdmin(admin.ModelAdmin):
> > > fieldsets = (
> > > (None, {'fields': ('slug', 'content', 'flatpage')}),
> > > )
> > > list_display = ('slug', 'flatpage',)
> > > list_filter = ('flatpage',)
> > > search_fields = ('slug', 'content')
>
> > > admin.site.register(Section, SectionAdmin)
>
> > > (also add inlines = [SectionInline,] to FlatPageAdmin class)
>
> > > # views.py - before creating Request Context
>
> > > # Create a dictionary, indexed by section slug, of section content
> > > d = {}
> > > for s in f.section_set.all():
> > > d[s.slug] = mark_safe(s.content)
>
> > > ...etc...
>
> > > c = RequestContext(request, {
> > > 'flatpage': f,
> > > 'section': d,
> > > })
>
> > > So of course, in my templates I could just render a block/section of
> > > content as {{ section.section_1 }}.
>
> > > Do we think something like this could be useful for the general
> > > population, either as part of flatpages or as a separate app?
>
> > > Keith
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
DjangoCon meetup Friday Sept 5
I'm planning a get together the night before DjangoCon for people going to the conference. I figured it would be nice to get to know each other a bit better before sitting in a conference together all weekend. I'm assuming that most people are going to be staying at the Hotel Avante where the block of rooms was reserved for the conference. So, I've talked to the hotel, and they've said that we can use the patio by the pool for the meetup. We can probably fit about 30 people there. If a lot more people show up, or if people aren't staying at the hotel, there's a billiard club across the street that's big enough to accommodate a larger group. I've set up a meetup page for the event here: http://django.meetup.com/3/ Please RSVP if you're thinking about attending. If the RSVP's fill up, we can move the venue across the street or find some place else. If anyone else can think of a better place to post this information, let me know. Comments and thoughts are always welcome. Jonathan --~--~-~--~~~---~--~~ 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: DjangoCon meetup Friday Sept 5
I think the TWID guys are doing something as well. Might want to combine groups. Eric On Wed, Aug 20, 2008 at 11:21 PM, Jonathan Nelson <[EMAIL PROTECTED]>wrote: > > I'm planning a get together the night before DjangoCon for people > going to the conference. I figured it would be nice to get to know > each other a bit better before sitting in a conference together all > weekend. > > I'm assuming that most people are going to be staying at the Hotel > Avante where the block of rooms was reserved for the conference. So, > I've talked to the hotel, and they've said that we can use the patio > by the pool for the meetup. We can probably fit about 30 people > there. > > If a lot more people show up, or if people aren't staying at the > hotel, there's a billiard club across the street that's big enough to > accommodate a larger group. > > I've set up a meetup page for the event here: > http://django.meetup.com/3/ > > Please RSVP if you're thinking about attending. If the RSVP's fill > up, we can move the venue across the street or find some place else. > > If anyone else can think of a better place to post this information, > let me know. Comments and thoughts are always welcome. > > Jonathan > > > > -- Eric Holscher Web Developer at The World Company in Lawrence, Ks http://www.ericholscher.com [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 -~--~~~~--~~--~--~---
Re: DjangoCon meetup Friday Sept 5
Is there any similar event happening in the nyc area? just wondering. On Thu, Aug 21, 2008 at 12:21 AM, Jonathan Nelson <[EMAIL PROTECTED]>wrote: > > I'm planning a get together the night before DjangoCon for people > going to the conference. I figured it would be nice to get to know > each other a bit better before sitting in a conference together all > weekend. > > I'm assuming that most people are going to be staying at the Hotel > Avante where the block of rooms was reserved for the conference. So, > I've talked to the hotel, and they've said that we can use the patio > by the pool for the meetup. We can probably fit about 30 people > there. > > If a lot more people show up, or if people aren't staying at the > hotel, there's a billiard club across the street that's big enough to > accommodate a larger group. > > I've set up a meetup page for the event here: > http://django.meetup.com/3/ > > Please RSVP if you're thinking about attending. If the RSVP's fill > up, we can move the venue across the street or find some place else. > > If anyone else can think of a better place to post this information, > let me know. Comments and thoughts are always welcome. > > Jonathan > > > > --~--~-~--~~~---~--~~ 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: Call for testing: new docs
Wow, the new docs look fantastic. I've been using Sphinx to generate some docs at work and recently figured out how to do the Sphinx -> LaTeX -> PDF thing so I thought I'd share it with the class: http://postneo.com/doc/django.pdf I had to tweak conf.py a little to get it working. Here's the patch for that: http://postneo.com/doc/0001-Tweak-conf.py-to-allow-for-building-LaTeX-documents.patch It choked on some of the graphics files which will obviously not show up in the PDF. admin01.png might still be a pdf instead of a png. You'll have to either comment out the reference to it or replace it with a real png. It also errored on the gifs (which I don't think pdflatex can handle) and a few other of the pngs, but got most of them. To generate the docs at home you'll need to do the following: Patch conf.py with the patch above. Grab a TeX distro (I used MacTeX. TeX Live is probably the easiest way to get off the ground on other platforms.) Make sure that pdflatex is on your PATH. I had to add /usr/local/ texlive/2007/bin/i386-darwin/ to my PATH. run "make latex" in the docs dir change to the _build/latex dir and run "make pdf-all" You'll encounter the image errors mentioned above but just keep hitting return until it's done. Thanks to all of the hard work put in by everyone. --Matt --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
