Re: newforms-admin Status Update
I'm almost positivie #7353 is no longer an issue. I was getting that error with oldforms-admin, and once upgrading to newforms-admin it was resolved. On Jul 16, 12:16 am, "Joseph Kocherhans" <[EMAIL PROTECTED]> wrote: > On Tue, Jul 15, 2008 at 11:50 PM, Brian Rosner <[EMAIL PROTECTED]> wrote: > > > Hey all, > > > I wanted to quickly update everyone on the status of the > > newforms-admin branch. It is quite literally a few tickets away! I > > have either fixed or triaged many tickets today so that the branch can > > get merged into trunk. The tickets triaged really shouldn't have been > > made blocker tickets and since we are rapidly approaching the 1.0 > > alpha they can be looked at after the merge to trunk. > > Woo hoo! Thank you for all your work on this. > > > #5780 [2] - Honza and Joseph have been looking at this. While this > > seems reasonable, it seems to involve a lot more than just what the > > patch does. Ideally all the save functionality is refactored in > > ModelAdmin a bit to allow for commit=False behavior. Should this still > > be considered a nfa-blocker? > > I don't think this is a blocker either, but it's certainly a pre-1.0 > thing that should go together with #6406 and #6002 which you > (rightfully) moved off of the blocker list a little while ago. I > looked at all of those last night and have some ideas, but it's > tricky. They *will* introduce some API changes, but I don't see any > reason why all API changes need to happen on the branch. To be more > specific, those changes will be limited to people overriding > ModelAdmin... not for people just casually using the admin system. > Likely, some hooks will go away, some signatures will be changed, and > more hooks will be added. > > > #7353 [3] - I am not exactly sure what this ticket is trying to say > > that is wrong with newforms-admin? AddManipulator no longer exists as > > functionality code with the branch. Could someone give a bit more > > information to get this fixed or just close it. > > Hopefully James will comment on this. I don't see how it could be a > problem for newforms-admin anymore. > > Joseph --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
newforms-admin Status Update
Hey all, I wanted to quickly update everyone on the status of the newforms-admin branch. It is quite literally a few tickets away! I have either fixed or triaged many tickets today so that the branch can get merged into trunk. The tickets triaged really shouldn't have been made blocker tickets and since we are rapidly approaching the 1.0 alpha they can be looked at after the merge to trunk. There are couple of tickets I want to get some opinions on. #5490 [1] - The patch has been marked ready for check-in, but to me something doesn't feel right with the patch. The patch introduces URL_SAFE_CHARACTERS in django.utils.http and is used in the admin by passing it in as the safe keyword argument to urlquote. Wouldn't it seem reasonable to just make it the default value of safe? #5780 [2] - Honza and Joseph have been looking at this. While this seems reasonable, it seems to involve a lot more than just what the patch does. Ideally all the save functionality is refactored in ModelAdmin a bit to allow for commit=False behavior. Should this still be considered a nfa-blocker? #7353 [3] - I am not exactly sure what this ticket is trying to say that is wrong with newforms-admin? AddManipulator no longer exists as functionality code with the branch. Could someone give a bit more information to get this fixed or just close it. Other than those, I have the remaining tickets as WIP locally. They will be finished tomorrow. The documentation is pretty much done. I would like for people to give it some attention and shake out any problems. Not a big deal and can be dealt with after a merge. The tutorial needs a bit of newforms-admin love. I haven't touched it due to the sensitivity of it so if Adrian or Jacob can take a whip at that that would be great! The branch has seen a lot of usage and I don't think it needs a call for testing, but for those who would like to test it now is that time. Please bang on it and report bugs in Trac. [1]: http://code.djangoproject.com/ticket/5490 [2]: http://code.djangoproject.com/ticket/5780 [3]: http://code.djangoproject.com/ticket/7353 Thanks, 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: API change in set_cookie for 1.0?
On 16 Jul 2008, at 01:14, Jeremy Dunck wrote: > > On Tue, Jul 15, 2008 at 6:56 PM, Malcolm Tredinnick > <[EMAIL PROTECTED]> wrote: >> >> >> On Tue, 2008-07-15 at 18:49 -0500, Jeremy Dunck wrote: >>> I was using HttpResponse.set_cookie for the first time and annoyed >>> that expires has to be a properly-formatted string. >>> >>> Why not take a datetime and do the formatting in the function? >>> >>> Obviously this is a breaking change, unless we have an isinstance >>> for >>> backwards incompatibility. >> >> Yeah, we should do something sensible if passed a datetime. Can you >> open >> a ticket? > > http://code.djangoproject.com/ticket/7770 > It would be nice if there were global cookie domain/path/secure/age settings that could be applied. Somehow SESSION_COOKIE_DOMAIN doesn't seem suitable, what with sessions being an optional component. Ben --~--~-~--~~~---~--~~ 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: API change in set_cookie for 1.0?
On Tue, 2008-07-15 at 19:15 -0500, Jeremy Dunck wrote: > On Tue, Jul 15, 2008 at 7:14 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > On Tue, Jul 15, 2008 at 6:56 PM, Malcolm Tredinnick > > <[EMAIL PROTECTED]> wrote: > >> > > >> Yeah, we should do something sensible if passed a datetime. Can you open > >> a ticket? > > > > http://code.djangoproject.com/ticket/7770 > > > > Err, note that I marked that Milestone 1.0, but please rule as you > like wrt to that. :) It's not going to be backwards incompatible, since we're adding more things that we accept, rather than removing something would previously have been valid. We can work out the timing in due course. 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: API change in set_cookie for 1.0?
On Tue, Jul 15, 2008 at 7:14 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > On Tue, Jul 15, 2008 at 6:56 PM, Malcolm Tredinnick > <[EMAIL PROTECTED]> wrote: >> >> Yeah, we should do something sensible if passed a datetime. Can you open >> a ticket? > > http://code.djangoproject.com/ticket/7770 > Err, note that I marked that Milestone 1.0, but please rule as you like wrt to that. :) --~--~-~--~~~---~--~~ 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: API change in set_cookie for 1.0?
On Tue, Jul 15, 2008 at 6:56 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > On Tue, 2008-07-15 at 18:49 -0500, Jeremy Dunck wrote: >> I was using HttpResponse.set_cookie for the first time and annoyed >> that expires has to be a properly-formatted string. >> >> Why not take a datetime and do the formatting in the function? >> >> Obviously this is a breaking change, unless we have an isinstance for >> backwards incompatibility. > > Yeah, we should do something sensible if passed a datetime. Can you open > a ticket? http://code.djangoproject.com/ticket/7770 --~--~-~--~~~---~--~~ 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: API change in set_cookie for 1.0?
On Tue, Jul 15, 2008 at 7:49 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > I was using HttpResponse.set_cookie for the first time and annoyed > that expires has to be a properly-formatted string. > > Why not take a datetime and do the formatting in the function? > > Obviously this is a breaking change, unless we have an isinstance for > backwards incompatibility. When I looked into set_cookie a while back, I was surprised how much was just being passed verbatim to SimpleCookie, which ended up causing some API confusion with secure cookies as well.[1] I don't know if it's worth looking at other attributes, but there are probably some other areas the API can be improved as well. -Gul [1] http://code.djangoproject.com/ticket/6657 --~--~-~--~~~---~--~~ 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: API change in set_cookie for 1.0?
On Tue, 2008-07-15 at 18:49 -0500, Jeremy Dunck wrote: > I was using HttpResponse.set_cookie for the first time and annoyed > that expires has to be a properly-formatted string. > > Why not take a datetime and do the formatting in the function? > > Obviously this is a breaking change, unless we have an isinstance for > backwards incompatibility. Yeah, we should do something sensible if passed a datetime. Can you open a ticket? 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: MS SQL pyodbc backend update to trunk
Thanks for that. Turned out the problem I was having was to do with slicing queries where no order_by was explicitly specified. I've uploaded a slightly modified patch to the same place. On Jul 15, 6:19 pm, "Ramiro Morales" <[EMAIL PROTECTED]> wrote: > On Tue, Jul 15, 2008 at 12:53 AM, bob84123 <[EMAIL PROTECTED]> wrote: > > > Yes I am. > > See patch attached to issue #2 I just > opened:http://code.google.com/p/django-pyodbc/issues/detail?id=2 > > Regards, > > -- > Ramiro Morales --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
API change in set_cookie for 1.0?
I was using HttpResponse.set_cookie for the first time and annoyed that expires has to be a properly-formatted string. Why not take a datetime and do the formatting in the function? Obviously this is a breaking change, unless we have an isinstance for backwards incompatibility. Thoughts? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
www.nikeadishoes.com
because our company open no long time,and we have some pro in deals with oredr please make you new order to us ,i think we will have a good beginning !! Our website: www.nikeadishoes.com Choose your favorite products please trust us ,have a good beginning You can look at our Web site. If the products have taken the following product codes put, the size of shoes tell us, we help you identify the newspaper give you a price, because we are now in the development of new customers, so the price is very favourable, We hope that with you because of the long-term cooperation ... ... Email:[EMAIL PROTECTED] MSN:[EMAIL PROTECTED] [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: Getting rid of get_db_prep_lookup on Field subclasses?
On Tue, Jul 15, 2008 at 12:38 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 2008-07-15 at 11:49 -0400, Leo Soto M. wrote:
>> After fixing some corner cases of #7560[1], and realizing that it is
>> too easy to write a wrong get_db_prep_lookup method (example:
>> #7448[2]), I have reached the conclusion that there is no reason to
>> have *two* methods for doing the python -> db conversion
>> (``get_db_prep_save`` and ``get_db_prep_lookup``). Not for most of the
>> fields, at least.
>
> I think it will take me a few days to think through all the implications
> here. However, I suspect the least intrusive change is to keep
> db_prep_lookup and db_prep_save, but have them call a common method
> (which could be called db_prep_value if you like).
Sure, that was what I was proposing.
Seems like I didn't explained myself well, but I don't want to kill
Field.get_db_prep_{save,lookup}. I want to avoid overriding them in
the same repetitive way on the common cases.
So looks like we agree on the general idea, and I'm going to
incorporate it to #7560.
--
Leo Soto M.
http://blog.leosoto.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: Getting rid of get_db_prep_lookup on Field subclasses?
On Tue, 2008-07-15 at 11:49 -0400, Leo Soto M. wrote: > After fixing some corner cases of #7560[1], and realizing that it is > too easy to write a wrong get_db_prep_lookup method (example: > #7448[2]), I have reached the conclusion that there is no reason to > have *two* methods for doing the python -> db conversion > (``get_db_prep_save`` and ``get_db_prep_lookup``). Not for most of the > fields, at least. I think it will take me a few days to think through all the implications here. However, I suspect the least intrusive change is to keep db_prep_lookup and db_prep_save, but have them call a common method (which could be called db_prep_value if you like). I can think of some slightly twisted cases where lookup and insert values will be different. For example, if I make a "month" field type, I would use an underlying date field column and the insert would be a full-fledged date value, whilst the lookup would be a call to a date extraction function in SQL. There quite possibly exist some legitimate cases like this as well (GIS stuff springs to mind as an area to look, for example). So, sharing common code would be good. Forcing everything to use the same code would probably come back and bite us. I think we're too close to an irreversible boundary for the API to make that type of change now. It often takes a few months, or longer, for all the corner cases to fall out. Thus, I'd keep the current API for the boundary between fields and the backends, but factor out the common bits more explicitly. 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 -~--~~~~--~~--~--~---
Getting rid of get_db_prep_lookup on Field subclasses?
After fixing some corner cases of #7560[1], and realizing that it is
too easy to write a wrong get_db_prep_lookup method (example:
#7448[2]), I have reached the conclusion that there is no reason to
have *two* methods for doing the python -> db conversion
(``get_db_prep_save`` and ``get_db_prep_lookup``). Not for most of the
fields, at least.
What I'm talking about is that, to ensure the proper type conversion
before querying the database[3], all of django core Fields should
currently do this:
def get_db_prep_save(self, value):
return some_transformation(value)
def get_db_prep_lookup(self, value, lookup_type):
if hasattr(value, 'as_sql'):
sql, params = value.as_sql()
return QueryWrapper(('(%s)' % sql), params)
if lookup_type in ('range', 'in'):
value = [some_transformation(v) for v in value]
elif lookup_type in ('exact', 'gt', 'gte', 'lt', 'lte'):
value = some_transformation(v)
return Field.get_db_prep_lookup(self, value)
Which blatantly violates DRY.
Also note that the documentation for custom fields, suggest to reuse
get_db_prep_save on get_db_prep_lookup[4]. Following that advice, I
propose to add a ``get_db_prep_value`` method to the Field API, to
make the common case much simpler. Then, almost all field can do:
def get_db_prep_value(self, value):
return some_transformation(value)
[Or just implement the transformation in the body, if it is not
trivial. I didn't want to reuse get_db_prep_save as the generic
transformation method, because the 'save' part seems to imply more
than just value transformation].
Then, on the base Field we would use this method to implement
``get_db_prep_save`` and ``get_db_prep_lookup``, and stop repeating
ourselves.
Does that make sense?
Should I add this change to the patch on #7560?
[1] http://code.djangoproject.com/attachment/ticket/7560
[2] http://code.djangoproject.com/attachment/ticket/7448
[3] This is needed by some backends which are not "string-happy", such
as JDBC backends.
[4]
http://www.djangoproject.com/documentation/custom_model_fields/#get-db-prep-lookup-self-lookup-type-value
--
Leo Soto M.
http://blog.leosoto.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: OneToOne and related models
alex finn wrote: > Hi Mike, > > thanks, this really helps and makes complete sense. > In this case, could it be a feature request for django to implement > bidirectional delete for related models in OneToOne case? I'm not officially connected to the Django project in any way, so you can make such a request as easily as I can. Why not open a new ticket or add the request to the one you created before at http://code.djangoproject.com/ticket/7708? > It is not a complex thing for me to override delete method for the > model and thus get the bidirectional delete, but when you call delete > method on a QuerySet it won't invoke customized delete method and thus > I will need to make sure related OneToOne instances are deleted as > well on my own. --~--~-~--~~~---~--~~ 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: Problems with concurrent DB access and get_or_create()
I'm experiencing the issue with concurrent writes on a low traffic site hosted on a single machine DB and web server. I'm logging reporting events in certain views and everytime I get indexed by a search engine, this error floods into my inbox. If I implement the workaround of hiding the multiple-rows-returned exception, I will end up with multiple rows containing my data instead of one. Until aggregates support comes around this means I would have to sum() the rows with some custom SQL. I suppose I could hide duplicates found by get_or_create and write a script to periodically tidy up duplicates into a single row. That seems rather a hack though. Regarding the prior conversation from December. I think it's important that this "just works," or there is at least a note warning about this possibility in the get_or_create docs. Otherwise the same thing that happened to me will happen to others. They'll build their software merrily and think it's working until one day traffic hits the level at which this problem occurs, then they have to modify code. Ben --~--~-~--~~~---~--~~ 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: OneToOne and related models
Hi Mike, thanks, this really helps and makes complete sense. In this case, could it be a feature request for django to implement bidirectional delete for related models in OneToOne case? It is not a complex thing for me to override delete method for the model and thus get the bidirectional delete, but when you call delete method on a QuerySet it won't invoke customized delete method and thus I will need to make sure related OneToOne instances are deleted as well on my own. Thanks again, Alex. --~--~-~--~~~---~--~~ 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: Views returning data only
On Tue, Jul 15, 2008 at 9:10 AM, vicvicvic <[EMAIL PROTECTED]> wrote:
> On Jul 15, 3:13 pm, Arien <[EMAIL PROTECTED]> wrote:
>> On Tue, Jul 15, 2008 at 7:34 AM, vicvicvic <[EMAIL PROTECTED]> wrote:
>> > On Jul 15, 1:57 pm, Arien <[EMAIL PROTECTED]> wrote:
>> >> On Tue, Jul 15, 2008 at 5:36 AM, vicvicvic <[EMAIL PROTECTED]> wrote:
[...]
> While a view cannot (should not) know the contents of the template
> used to serialize the content, loading a template named
> "whatever.html" couples it to an HTML Content-type. I does not make
> sense to serialize JSON data in a template named .html. I could of
> course use templates named "whatever.serializing_template" and use
>
> {% ifequal content_type "json" %}[1234,3452]{% else %}1234 p>3452{% endif %}
>
> in my template code but I think that looks butt-ugly. Also, how do I
> set the Content-type-header in a Template?
Why not pass the template and the Content-Type to the view? See
django.views.generic for examples of that approach.
>> >> Django is a *Web* framework. Views are the part of the framework that
>> >> generate responses to requests and both of those necessarily use HTTP.
>>
>> > A response-request paradigm is hardly unique to HTTP. Yes, Django is a
>> > web framework and yet, both models and templates are (naturally)
>> > decoupled from HTTP. The documentation even includes a paragraph about
>> > using templates in stand-alone mode!
>>
>> Sure, but that doesn't apply to views.
>
> Why not?
Views are your interface to the outside world, and since Django is a
Web framework that world speaks HTTP.
Arien
--~--~-~--~~~---~--~~
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: OneToOne and related models
alex finn wrote: > Hi Everybody, > > I need some assistance on django's OneToOne mapping implementation. > Several days ago I started a discussion in django-users but didn't get > too much of feedback :( > Here it is: > http://groups.google.com/group/django-users/browse_thread/thread/8b30b3bdc157e2ba/5102e779805b0510#5102e779805b0510 > > Briefly, the issue is that when I'm using multiple OneToOne mappings > in one model and then delete an instance of this model, objects > associated with it as OneToOne are not being deleted. I even opened a > ticket for that (http://code.djangoproject.com/ticket/7708) but again > didn't see any activity around it. So I decided to look into it myself > and try to resolve it, but unfortunately I don't have enough django > and especially python experience (I'm mostly used to C/Java/PHP) to > fix it on my own. I don't know if you discovered this yet, but the delete is working in one direction, but not in the direction you're expecting it to. For instance, using the models you posted in another message: class Place(models.Model): name = models.CharField(max_length = 100) class Restaurant(models.Model): place = models.OneToOneField(Place, primary_key=True) If you create a Place and a Restaurant that is linked to it, deleting the Restaurant will not delete the Place (this is the problem you're reporting here), but deleting the Place will delete the Restaurant. I'm not sure this was an intentional Django design decision or not, and I can see why you expect it to work differently. However, there is also some rationale for it working the way that it does. 1) For example, if I extend your model to include: class GasStation(models.Model): place = models.OneToOneField(Place, primary_key=True) If I have a Place that is both a Restaurant and a GasStation, then decide to close its GasStation but keep the Restaurant open, I would delete the GasStation object but expect the Place and the Restaurant to remain--which is, in fact, what happens. 2) This behavior of Django's OneToOneField is consistent with the behavior of its ForeignKey field: the model containing the OneToOneField or the ForeignKey field is deleted if the model it points to is deleted, but not the other way around. (In fact, if you look at the definition of the OneToOneField class, it turns out that it is actually just a subclass of ForeignKey class, so this isn't surprising). > While looking into the problem I found out that these relationships > don't appear in models _meta._related_objects_cache Consistent with the behavior I described above, it's true that, as you say, the Place doesn't appear in the Restaurant's _meta._related_objects_cache collection; however, the Restauraunt *does* appear in the Place's _meta._related_objects_cache collection. > Now I'm having difficulties trying to understand how this cache is > being built as according to Options._fill_related_objects_cache it > should be filled in with parent models only. But it definitely > contains the ManyToOne relationships (ForeignKeys). Could anyone > please explain me how this part of the ORM is working?\ Hope this helps. Mike --~--~-~--~~~---~--~~ 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: Views returning data only
On Jul 15, 3:13 pm, Arien <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 15, 2008 at 7:34 AM, vicvicvic <[EMAIL PROTECTED]> wrote:
> > On Jul 15, 1:57 pm, Arien <[EMAIL PROTECTED]> wrote:
> >> On Tue, Jul 15, 2008 at 5:36 AM, vicvicvic <[EMAIL PROTECTED]> wrote:
>
> >> If a view picks a template and renders it using some data, the
> >> template is still free to present the data any way it likes (with some
> >> Content-Type related restrictions). But you don't have to hard-wire
> >> the template (and the implicit Content-Type) in the view. Write a
> >> view that has (optional) arguments (with sensible defaults) for the
> >> template (and the Content-Type).
>
> > Indeed I could do that, but I think my pattern is more general and
> > makes sure a view is ONLY responsible for describing what data you
> > see.
>
> That *is* its only responsibility. But the view returns some kind of
> serialization of that data with some HTTP headers, not the data
> itself. Don't read too much into the text from the FAQ.
While a view cannot (should not) know the contents of the template
used to serialize the content, loading a template named
"whatever.html" couples it to an HTML Content-type. I does not make
sense to serialize JSON data in a template named .html. I could of
course use templates named "whatever.serializing_template" and use
{% ifequal content_type "json" %}[1234,3452]{% else %}12343452{% endif %}
in my template code but I think that looks butt-ugly. Also, how do I
set the Content-type-header in a Template?
> >> Django is a *Web* framework. Views are the part of the framework that
> >> generate responses to requests and both of those necessarily use HTTP.
>
> > A response-request paradigm is hardly unique to HTTP. Yes, Django is a
> > web framework and yet, both models and templates are (naturally)
> > decoupled from HTTP. The documentation even includes a paragraph about
> > using templates in stand-alone mode!
>
> Sure, but that doesn't apply to views.
Why not?
--~--~-~--~~~---~--~~
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: Views returning data only
On Jul 15, 3:20 pm, "Waylan Limberg" <[EMAIL PROTECTED]> wrote: > Vicvicvic, > > I think your on to something here. However, we need to remember that > one of the great things about Django views is that they are just > python functions. You can do pretty much anything you want. So, if > someone wants to build up a complete html page in python code without > any templates, they can. It will be a maintenance headache, so it's > not recommended, but its not wrong. > > If you want to build up a library of decorators that simplify your > views (and, no doubt, speed up your work), then you are free to do so. > And if you want to share that library with others, that's even better. > In fact, if you search through djangosnippets.com, I believe you'll > find a few snippets that do some of the same things your talking > about. When I feel confident that my code is clean enough, I will absolutely share it. :) > However, I don't expect that the Django core will take on your > approach as the "preffered" way to do things. The flexibility of the > views to allow various coding styles is one of Django's greatest > strengths. You can do what works for you and I can do what works for > me. > > So keep it up. Share your work and make Django a better place for > others who like that style of coding. Just don't expect the entire > community to embrace it as the "only way". Point taken :) Nevertheless, having a decorator described above would not change anything, it would just add flexibility (in my mind). The decorator would obviously only apply to whichever views you decorate, so it only forces it behavior on the views you want to use. The talk about redefining HttpRequest etc., however, is on a considerably different level. THAT would probably not go in the core until someone says "Hey, let's bring the goodness of Django to the desktop!" and I'm not even interested in doing it myself. The thought just popped up in my head. --~--~-~--~~~---~--~~ 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: Views returning data only
On Tue, Jul 15, 2008 at 8:20 AM, Waylan Limberg <[EMAIL PROTECTED]> wrote: > I think your on to something here. However, we need to remember that > one of the great things about Django views is that they are just > python functions. ... or any other callable. Arien --~--~-~--~~~---~--~~ 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: Views returning data only
On Jul 15, 3:05 pm, "Scott Moonen" <[EMAIL PROTECTED]> wrote:
> Hi Victor,
>
> It sounds like your pattern works well for you, which is good.
>
> Another pattern that can be used is to have the view select off of some of
> the request attributes, and maybe even add your own test functions (such as
> "accepts()") to the request class. For example:
>
> if request.accepts('application/xhtml+xml') : template_ext = "xhtml"
> elif request.is_ajax() : template_ext = "json"
> else : template_ext = "html"
> . . .
I think that's the kind of test I'd like to have in my decorator.
Thanks for the tip :)
> If you think about the broader uses of view functions, I think you may find
> that the apparent elegance of your approach breaks down. You want the view
> functions to be agnostic of whatever output format they use, and I think
> that may be possible to achieve (although you create a little bit of
> overhead in constructing and passing variables for the template that aren't
> used for all output types). However, another purpose of view functions is
> to process input and take corresponding action. In cases like this I don't
> think you can avoid making the view functions much more intimately aware of
> the underlying format (e.g., AJAX or REST request versus vanilla HTTP
> POST). This applies to how the input is parsed, but also to the subsequent
> action that is taken: for HTTP POST you may re-display a form on validation
> error, or else return a redirect on success to view the object; but for AJAX
> you will likely emit some Javascript that updates the page, either to note
> errors or to reflect a successful update.
I've pandered this problem a bit myself. As far as input goes, I think
AJAX can use POST, but yes, it could be a problem. For output, I'm
thinking about maybe making views return something a bit more advanced
than a dictionary of data. It wouldn't be as elegant, but if I return
classes like ValidationFailedResponse(data) or
SuccessfulFormSubmitResponse(data) to the decorator (I hate naming
stuff), it can use them to generate the appropriate HttpResponse. If
the format is JSON, it should return Http200 and render a template, if
it's HTML, redirect. Not as clean, but hopefully it's cleaner than the
other options...
--~--~-~--~~~---~--~~
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: Views returning data only
Vicvicvic,
I think your on to something here. However, we need to remember that
one of the great things about Django views is that they are just
python functions. You can do pretty much anything you want. So, if
someone wants to build up a complete html page in python code without
any templates, they can. It will be a maintenance headache, so it's
not recommended, but its not wrong.
If you want to build up a library of decorators that simplify your
views (and, no doubt, speed up your work), then you are free to do so.
And if you want to share that library with others, that's even better.
In fact, if you search through djangosnippets.com, I believe you'll
find a few snippets that do some of the same things your talking
about.
However, I don't expect that the Django core will take on your
approach as the "preffered" way to do things. The flexibility of the
views to allow various coding styles is one of Django's greatest
strengths. You can do what works for you and I can do what works for
me.
So keep it up. Share your work and make Django a better place for
others who like that style of coding. Just don't expect the entire
community to embrace it as the "only way".
On Tue, Jul 15, 2008 at 6:36 AM, vicvicvic <[EMAIL PROTECTED]> wrote:
>
> In the Django FAQ, we can read this about views:
>
>>In our interpretation of MVC, the "view" describes the data that gets
>>presented to the user. It's not necessarily how the data looks, but which
>>data is presented. The view describes which data you see, not how you see it.
>>It's a subtle distinction.
>
> In my mind, "which data you see" would be equal to a context a view
> returns, not the HttpResponse or the template. Why? Because rendering
> a template is saying "I have this data and I want it presented the way
> this template will present it". If the view is responsible for saying
> that, it is at least partly responsible for telling us how we see the
> data.
>
> Rather, if a view ONLY returned a dataset, something else would be
> responsible for displaying this. In more practical terms, if a view
> returns a dataset, instead of a full response, another mechanism would
> be wholly in charge of formatting the data. This mechanism may then
> choose which template to render, or to not render a template at all,
> and just pass the dataset along.
>
> Why is this useful? For the sake of minimizing views, but provide a
> rich amount of formats. The format-choice mechanism can investigate
> the request (HTTP Requests come with an Accept-header) and see what
> format has been requested. Looking at Accept would be the proper way
> of doing it, but it might be easier to make URLs like /forums/threads.
> (?Phtml|json|xml)
>
> HTML? Render that template. JSON? Render that template (or just
> serialize the dataset). XML? RSS? You get the idea: The formatter
> takes the data and tries to present it, making it a bridge between a
> view and a template.
>
> Furthermore, the same mechanism could be asked to process an
> "internal" request, that is another Python function requesting the
> data. Right now, I have a couple of views which return some data. But
> I'm also building another view, and I want the data from one of the
> first views in this one. I can either duplicate the fetching from the
> first one, or I can send an "internal" request and just get the
> dataset. I pick WHICH data I want and add some to it.
>
> My current solution:
>
> I've written a very crude decorator to demonstrate/use this in my own
> projects, but I'm note sure if posting code looks any good on Google
> Groups. Summarized:
> My decorated views return their dataset as a dictionary.
>
> The decorator takes two parameters: template and formats. template is
> the usual path to a template, but without an extension. formats is a
> tuple of formats (('html','json')) which the view is considered able
> to render.
>
> Upon calling the view, the decorator intercepts its arguments. It
> looks for a format-parameter and an internal-parameter. If internal is
> True, it lets the view run and just returns the resulting dictionary
> to whatever called it. If not, it checks that format is in formats and
> then tries to render_to_response("%s.%s" % (template, format,
> returned_dict, RequestContext(request))
>
> As I said above, the mechanism (in my case, a decorator) should
> probably try to investigate what the request looks like, rather than
> checking for stuff in the URL/other parameters but as I said, it's
> crude. It should also return the proper Content-type.
>
> --
>
> Do you think I have a point? Me not being a Django developer (and not
> a very seasoned Python user at all), I realize I might have
> misunderstood your... philosophy :)
> >
>
--
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
Re: Views returning data only
On Tue, Jul 15, 2008 at 5:51 AM, vicvicvic <[EMAIL PROTECTED]> wrote: > An interesting effect of this whole thing is that it decouples views > from not only formatting but protocol. Django is a *Web* framework. Views are the part of the framework that generate responses to requests and both of those necessarily use HTTP. Arien --~--~-~--~~~---~--~~ 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: Views returning data only
On Tue, Jul 15, 2008 at 5:36 AM, vicvicvic <[EMAIL PROTECTED]> wrote: > > In the Django FAQ, we can read this about views: > >> In our interpretation of MVC, the "view" describes the data that gets >> presented to the user. It's not necessarily how the data looks, but which >> data is presented. The view describes which data you see, not how you see >> it. It's a subtle distinction. > > In my mind, "which data you see" would be equal to a context a view > returns, not the HttpResponse or the template. Why? Because rendering > a template is saying "I have this data and I want it presented the way > this template will present it". If the view is responsible for saying > that, it is at least partly responsible for telling us how we see the > data. If a view picks a template and renders it using some data, the template is still free to present the data any way it likes (with some Content-Type related restrictions). But you don't have to hard-wire the template (and the implicit Content-Type) in the view. Write a view that has (optional) arguments (with sensible defaults) for the template (and the Content-Type). > Right now, I have a couple of views which return some data. But I'm > also building another view, and I want the data from one of the first > views in this one. I can either duplicate the fetching from the first > one, or I can send an "internal" request and just get the dataset. I > pick WHICH data I want and add some to it. Or you could write a function that fetches and returns it, and use that function in both views. Arien --~--~-~--~~~---~--~~ 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: Views returning data only
Maybe I should mention: Since only specially decorated views act this way, the change is completely backwards-compatible. At its current state, it does restrict how you use "internal" and "format" as capturing patterns in URLs, obviously. Also, the format-decorator checks if the view returns a HttpResponse and if so, returns that directly. This is for the sake of supporting HttpResponseRedirect. An interesting effect of this whole thing is that it decouples views from not only formatting but protocol. Further generalized, they might raise NotFound-exceptions rather than Http404. A higher level mechanism would know how we're communicating with the user and make sure the right 'language' is spoken. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Views returning data only
In the Django FAQ, we can read this about views:
>In our interpretation of MVC, the “view” describes the data that gets
>presented to the user. It’s not necessarily how the data looks, but which data
>is presented. The view describes which data you see, not how you see it. It’s
>a subtle distinction.
In my mind, "which data you see" would be equal to a context a view
returns, not the HttpResponse or the template. Why? Because rendering
a template is saying "I have this data and I want it presented the way
this template will present it". If the view is responsible for saying
that, it is at least partly responsible for telling us how we see the
data.
Rather, if a view ONLY returned a dataset, something else would be
responsible for displaying this. In more practical terms, if a view
returns a dataset, instead of a full response, another mechanism would
be wholly in charge of formatting the data. This mechanism may then
choose which template to render, or to not render a template at all,
and just pass the dataset along.
Why is this useful? For the sake of minimizing views, but provide a
rich amount of formats. The format-choice mechanism can investigate
the request (HTTP Requests come with an Accept-header) and see what
format has been requested. Looking at Accept would be the proper way
of doing it, but it might be easier to make URLs like /forums/threads.
(?Phtml|json|xml)
HTML? Render that template. JSON? Render that template (or just
serialize the dataset). XML? RSS? You get the idea: The formatter
takes the data and tries to present it, making it a bridge between a
view and a template.
Furthermore, the same mechanism could be asked to process an
"internal" request, that is another Python function requesting the
data. Right now, I have a couple of views which return some data. But
I'm also building another view, and I want the data from one of the
first views in this one. I can either duplicate the fetching from the
first one, or I can send an "internal" request and just get the
dataset. I pick WHICH data I want and add some to it.
My current solution:
I've written a very crude decorator to demonstrate/use this in my own
projects, but I'm note sure if posting code looks any good on Google
Groups. Summarized:
My decorated views return their dataset as a dictionary.
The decorator takes two parameters: template and formats. template is
the usual path to a template, but without an extension. formats is a
tuple of formats (('html','json')) which the view is considered able
to render.
Upon calling the view, the decorator intercepts its arguments. It
looks for a format-parameter and an internal-parameter. If internal is
True, it lets the view run and just returns the resulting dictionary
to whatever called it. If not, it checks that format is in formats and
then tries to render_to_response("%s.%s" % (template, format,
returned_dict, RequestContext(request))
As I said above, the mechanism (in my case, a decorator) should
probably try to investigate what the request looks like, rather than
checking for stuff in the URL/other parameters but as I said, it's
crude. It should also return the proper Content-type.
--
Do you think I have a point? Me not being a Django developer (and not
a very seasoned Python user at all), I realize I might have
misunderstood your... philosophy :)
--~--~-~--~~~---~--~~
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: OneToOne and related models
Here's the code example that shows the issue: models.py: http://dpaste.com/65040/ tests.py: http://dpaste.com/65041/ This test fails as Place instance was not deleted --~--~-~--~~~---~--~~ 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: MS SQL pyodbc backend update to trunk
On Tue, Jul 15, 2008 at 12:53 AM, bob84123 <[EMAIL PROTECTED]> wrote: > > Yes I am. > See patch attached to issue #2 I just opened: http://code.google.com/p/django-pyodbc/issues/detail?id=2 Regards, -- Ramiro Morales --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
