Re: NDjango - .Net port of Django template langauage

[Pablo Escobar]

1. Django is Open Source. It is not a problem to find the parsing
algorithm

PS Anyway. I don't see any advantages of django's templates comparing
with ASP.NET MVC Views

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: CSRF proposal and patch ready for review

[Simon Willison]

On Sep 22, 9:24 pm, Luke Plant  wrote:
> > 2. I'm not at all keen on the implementation as a middleware
> > (especially a view middleware, which doesn't play well with generic
> > views and redispatching to other view functions, both patterns I like
> > a lot).
>
> Could you explain a bit more about the difficulties with generic views?  

Sorry, I meant to type "class based generic views" - but actually
that's not really what I meant either. My problem with view middleware
is that it makes it much harder to use the pattern where view
functions re-dispatch to other view functions. The classic example is
a site with a URL structure that looks like this:

/category/sub-category/sub-sub-category/arbitrarily-deep-nesting/news/

I've built stuff like this in the past by essentially discarding
urls.py - I instead map "^(.*)$" to my own view function which then
splits request.path on slashes and re-dispatches based on its own
custom logic. View middleware doesn't really fit that model - it
assumes that the top level URL configuration will resolve to the
callable that's actually going to implement the view, but that isn't
necessarily the case for complex sites.

A more common example is view functions which re-dispatch to other
functions:

def homepage_view(request):
if request.user.is_authenticated():
return logged_in_homepage_view(request)
else:
return default_homepage_view(request)

A view middleware will just see "homepage_view" - it won't know which
of the actual view functions is going to be called.

I'm a big fan of class-based generic views which can involve quite a
bit of subclassing and re-dispatching to other methods (like my
RestView class http://www.djangosnippets.org/snippets/1071/ ) which is
another reason view middleware makes me uncomfortable.

Note that this is a philosophical objection to process_view middleware
as a whole, not anything specific to CSRF.


> 1) Implement your csrf_protect_form method.  That could easily add your
> requirement to lock down to individual forms and timeouts.  It would need
> cooperation from a new template tag, or additional optional arguments to the
> current template tag. It might also need an additional context processor in
> settings, but as an opt-in solution that's OK.
>
> I think the solution that manipulates request.POST sounds OK - yes a hack, but
> providing this method is not the default, most people won't have to deal with
> any problems with it.

Excellent. I'll have a go at building that against your branch and see
how it comes out.

> The only question mark in my mind is what happens with multiple forms on a
> page (e.g. when you have a login box on every page).  It might not be an issue
> - the target of the login box will be another view anyway - but it needs
> thought.

I think that case works OK. It would end up looking something like
this:


  
  
  {% csrf_token "login" %}



  
  {% csrf_token "rate" %}


Cheers,

Simon
--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: NDjango - .Net port of Django template langauage

[Michael Feingold]

On Sep 23, 2:54 am, Pablo Escobar  wrote:
> 1. Django is Open Source. It is not a problem to find the parsing
> algorithm
>
Of course it is And we did go through the code. But reverse
engineering can show you what happens, not what the intention was


--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: CSRF proposal and patch ready for review

[Luke Plant]

On Tuesday 22 September 2009 21:24:48 Luke Plant wrote:

> 2) Get the view to be exempted from the normal CSRF checks done
>  by the middleware.  Thankfully, we already have not one but two
>  ways of doing this - the manual @csrf_exempt decorator on views,
>  and the internal mechanism that allows the decorator and
>  middleware to avoid duplicate checking. Automatically doing the
>  latter in csrf_protect_form is probably the way ahead.

Hmm, had a thinko there. The middleware is run *before* decorators 
have had a chance to modify the request object.  So only the first 
of these will work I think.  That plays badly with your method of 
dispatching from your own view code.  You will have to manually 
csrf_exempt your top level view code, and manully apply 
csrf_protect_form as needed.

Luke

-- 
"Pretension: The downside of being better than everyone else is 
that people tend to assume you're pretentious." (despair.com)

Luke Plant || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: ManyRelatedManager signals

[Andy McKay]

On Tue, 22 Sep 2009 19:10:19 -0700 (PDT), Stephen Sundell
 wrote:
> Is there a reason not to have a signal before and after creating an
> entry into a ManyToMany table.  I have a piece of code i need to call
> when this relationship is created.  I don't know of any signal that
> exists already, so I created my own.  Thought it might be an
> interesting feature to add, unless theres a reason its not there.

There a quite a few tickets on this in Trac eg:
http://code.djangoproject.com/ticket/5390

Fingers crossed for this in 1.2
--
Andy McKay

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Change list default sort modification proposal

[Ben Davis]

I would write the tests though I'm not 100% sure how to write regression
tests for a UI change...   any suggestions on how to go about doing that?

On Thu, Sep 17, 2009 at 2:04 PM, Joshua Russo wrote:

> I don't have any say in what gets accepted or not but I do believe that
> your solution is a decent one. I'm continuing with mine because it addresses
> a current need simply and can be (fairly) easily tested. If you can create
> the regression tests for yours then I believe you might get more traction.
> Then again there may be some hesitation to the level of complexity you are
> introducing. There is always a strong inclination in the the project for
> simplicity.
>
>
> On Thu, Sep 17, 2009 at 5:42 PM, Ben Davis  wrote:
>
>> I'm not sure if anyone's seen this,  but I've written a patch for
>> multi-sort columns in the changelist ui here:
>>
>> http://code.djangoproject.com/ticket/11868
>>
>> Not sure if this is what you guys had in mind, but I'd be interested in
>> your feedback.
>>
>>
>> On Thu, Sep 17, 2009 at 12:57 PM, Joshua Russo wrote:
>>
>>>
>>> Sorry for dragging this back out of the depths but I was reviewing my
>>> code for regression testing and I noticed I had missed this comment
>>> way back when.
>>>
>>> Where is this named sort option documented?
>>>
>>> It seems to me that the implementation that I have here would still be
>>> useful even if you could associate multiple sort columns with a single
>>> displayed column. I think that it's confusing to the developer not to
>>> have the list display using the sort order that is defined within the
>>> model.
>>>
>>>
>>> On Aug 13, 2:49 pm, Rock  wrote:
>>> > My suggestion for handling the UI for multi-column sorts is to allow
>>> > the definition
>>> > of named sorts in a manner similar to the way that the default sorting
>>> > is defined.
>>> > With this in place, additional multi column orders can be accomplished
>>> > simply
>>> > by using this name as a sort selection and applying the corresponding
>>> > named sort.
>>> >
>>> > If this is an acceptable approach, I can flesh out the API for it.
>>> >
>>> > On Aug 11, 10:10 pm, Malcolm Tredinnick 
>>> > wrote:
>>> >
>>> >
>>> >
>>> > > For those, like me, wondering what this proposal was about, it's
>>> > > concerning changing sorting in the admin interface to initially use
>>> the
>>> > > full set of fields specified in Meta.ordering on the model.
>>> >
>>> > > What I can't work out yet, due to difficulty in reviewing the patch,
>>> > > mentioned below, is whether it allow sorting by more than one column
>>> via
>>> > > the column-clicking method. That would almost certainly seem to be a
>>> > > request that is going to arrive 10 seconds after a feature like this
>>> is
>>> > > committed, although the difficulty has always been with how the UI
>>> works
>>> > > for that situation.
>>>
>>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: NDjango - .Net port of Django template langauage

[Stephen Kelly]

Michael Feingold wrote:
> On Sep 23, 2:54 am, Pablo Escobar
>  wrote:
>> 1. Django is Open Source. It is not a problem to find the parsing
>> algorithm
>>
> Of course it is And we did go through the code. But reverse
> engineering can show you what happens, not what the intention was

Usually the unit tests are the best documentation there. However I noticed 
that in this case there are no unit tests for blocks being nested.

I am also the author of a port of the Django system, to C++/Qt in my case.

http://www.gitorious.org/grantlee/pages/Home

I wrote some tests for nesting of blocks here:

http://www.gitorious.org/grantlee/grantlee/commit/85c47cd951e155008a8a5241a7bb2ef8dd018e82

Which I'm sure I'll eventually port back up to django. The end result seems 
to be that {{ block.super }} can behave in ways that you might not expect 
when blocks are nested.

I also found this ticket which probably explains the behaviour I see in the 
tests when using block.super:

http://code.djangoproject.com/ticket/7324

All the best,

Steve.





--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Change list default sort modification proposal

[Joshua Russo]

Take a look in test\regressiontests\admin_views\tests.py
AdminViewBasicTest.testChangeListSortingXXX() methods. They should give you
a good place to start.

On Wed, Sep 23, 2009 at 6:18 PM, Ben Davis  wrote:

> I would write the tests though I'm not 100% sure how to write regression
> tests for a UI change...   any suggestions on how to go about doing that?
>
> On Thu, Sep 17, 2009 at 2:04 PM, Joshua Russo wrote:
>
>> I don't have any say in what gets accepted or not but I do believe that
>> your solution is a decent one. I'm continuing with mine because it addresses
>> a current need simply and can be (fairly) easily tested. If you can create
>> the regression tests for yours then I believe you might get more traction.
>> Then again there may be some hesitation to the level of complexity you are
>> introducing. There is always a strong inclination in the the project for
>> simplicity.
>>
>>
>> On Thu, Sep 17, 2009 at 5:42 PM, Ben Davis  wrote:
>>
>>> I'm not sure if anyone's seen this,  but I've written a patch for
>>> multi-sort columns in the changelist ui here:
>>>
>>> http://code.djangoproject.com/ticket/11868
>>>
>>> Not sure if this is what you guys had in mind, but I'd be interested in
>>> your feedback.
>>>
>>>
>>> On Thu, Sep 17, 2009 at 12:57 PM, Joshua Russo 
>>> wrote:
>>>

 Sorry for dragging this back out of the depths but I was reviewing my
 code for regression testing and I noticed I had missed this comment
 way back when.

 Where is this named sort option documented?

 It seems to me that the implementation that I have here would still be
 useful even if you could associate multiple sort columns with a single
 displayed column. I think that it's confusing to the developer not to
 have the list display using the sort order that is defined within the
 model.


 On Aug 13, 2:49 pm, Rock  wrote:
 > My suggestion for handling the UI for multi-column sorts is to allow
 > the definition
 > of named sorts in a manner similar to the way that the default sorting
 > is defined.
 > With this in place, additional multi column orders can be accomplished
 > simply
 > by using this name as a sort selection and applying the corresponding
 > named sort.
 >
 > If this is an acceptable approach, I can flesh out the API for it.
 >
 > On Aug 11, 10:10 pm, Malcolm Tredinnick 
 > wrote:
 >
 >
 >
 > > For those, like me, wondering what this proposal was about, it's
 > > concerning changing sorting in the admin interface to initially use
 the
 > > full set of fields specified in Meta.ordering on the model.
 >
 > > What I can't work out yet, due to difficulty in reviewing the patch,
 > > mentioned below, is whether it allow sorting by more than one column
 via
 > > the column-clicking method. That would almost certainly seem to be a
 > > request that is going to arrive 10 seconds after a feature like this
 is
 > > committed, although the difficulty has always been with how the UI
 works
 > > for that situation.


>>>
>>>
>>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Let's Talk About ``to_field``

[David Cramer]

I haven't brought this up for quite a while, but ``to_field`` still
does not function properly (at least as of 1.1, I haven't noticed any
changes addressing it though). The issue is that anywhere you do a GET
lookup, it doesn't process the to_field properly::

# TODO: waiting on to_field fix
try:
opt = cls.objects.get(business=business.business_id,
key=key)
except cls.DoesNotExist:
opt = cls.objects.create(business=business, key=key,
value=value)

This seems to have been solved in the admin branch when newforms-admin
landed, but seems mostly ignored in the core field's. This issue has
also existed as far as I can remember, which is quite some time :)

So, what do we need to get the ball rolling on this. I don't have much
time myself to commit, but if it's minor things such as writing some
tests that easily reproduce all errors we've found. We'll glady commit
those. Other than though my day is just filled, but I'd love to see
this get fixed. It's something that's advertised as a core feature,
has been for 3+years, and simply doesn't work.

On a side note, something that I also believe is a bug, is that
ManyToManyRel.get_related_field() returns the primary key field no
matter what. I'm not sure if thats the intended functionality of that
or not, but to me it sounds like this should refer to the field in the
through model (even if that model is virtual) that it's pointing to.
--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: NDjango - .Net port of Django template langauage

[Michael Feingold]

Thank you for the pointers. You have some pretty interesting test
cases in your project. We also have quiet a few test cases in our unit
tests have a peek if you are interested. As to the ticket - this is an
interesting one. The scenario it refers to seems pretty clear to me I
agree with Karen's judjment on the issue. Nested block definitions and
block.super variables in itself seem clear to me and it appears to
work fine in our testing. But here is the scenario I cannot find a
miningful interpretation for:

=== base template ===
{% block b %}
whatever
{% endblock b %}

=== child template ===
{% extends base %}
{% block new %}
{% for k in list %}
{% block b %}
new value: {{k}}
{% endblock %}
{% endfor %}
{% endblock new %}

assuming that there let's say 6 values in the list what is the
expected result here? The child template defines 6 different variants
to be placed in a single hole? which one goes? The first? the last?
all of them? Nested block definition is ok when we define a 'hole',
but when we define a new value to be placed in a hole it creates
ambiguity for which I do not see any real use.

On Sep 23, 2:22 pm, Stephen Kelly  wrote:
> Michael Feingold wrote:
> > On Sep 23, 2:54 am, Pablo Escobar
> >  wrote:
> >> 1. Django is Open Source. It is not a problem to find the parsing
> >> algorithm
>
> > Of course it is And we did go through the code. But reverse
> > engineering can show you what happens, not what the intention was
>
> Usually the unit tests are the best documentation there. However I noticed
> that in this case there are no unit tests for blocks being nested.
>
> I am also the author of a port of the Django system, to C++/Qt in my case.
>
> http://www.gitorious.org/grantlee/pages/Home
>
> I wrote some tests for nesting of blocks here:
>
> http://www.gitorious.org/grantlee/grantlee/commit/85c47cd951e155008a8...
>
> Which I'm sure I'll eventually port back up to django. The end result seems
> to be that {{ block.super }} can behave in ways that you might not expect
> when blocks are nested.
>
> I also found this ticket which probably explains the behaviour I see in the
> tests when using block.super:
>
> http://code.djangoproject.com/ticket/7324
>
> All the best,
>
> Steve.
--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: decorator_from_middleware change

[James Bennett]

On Tue, Sep 22, 2009 at 4:07 PM, Luke Plant  wrote:
> Bummer, I tried hard not to break it - I added backwards
> compatibility tests for the basic different uses.  Could you produce
> a test case?

So, I've worked out what the problem is.

Previously either of these worked:

cache_page(timeout, view)
cache_page(view, timeout)

Now, cache_page assumes that the first positional argument will be the
timeout. So what we're seeing when running some of our code on trunk
is cache_page treating the timeout value (an integer) as the view to
be cached, and failing when trying to find things like __module__
attached to it.

I don't know for certain how many people may be using this idiom,
since it was never documented (AFAICT cache_page always documented
itself as putting the timeout first and the view function second), so
I'm not really sure what (if anything) we should do about it.

There may also be deeper issues with the fact that it's not possible
to call cache_page with explicit keyword args, since it accepts
**kwargs but doesn't do anything with it, always assuming that the
timeout and view can be pulled from positional args.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: NDjango - .Net port of Django template langauage

[Stephen Kelly]

Michael Feingold wrote:

> 
> Thank you for the pointers. You have some pretty interesting test
> cases in your project.

Thanks. Actually most of the credit goes to the django developers, because 
most of my tests are just ported versions of the django tests.

> We also have quiet a few test cases in our unit
> tests have a peek if you are interested.

Yes, I will.

> As to the ticket - this is an
> interesting one. The scenario it refers to seems pretty clear to me I
> agree with Karen's judjment on the issue. Nested block definitions and
> block.super variables in itself seem clear to me and it appears to
> work fine in our testing. But here is the scenario I cannot find a
> miningful interpretation for:
> 
> === base template ===
> {% block b %}
> whatever
> {% endblock b %}
> 
> === child template ===
> {% extends base %}
> {% block new %}
> {% for k in list %}
> {% block b %}
> new value: {{k}}
> {% endblock %}
> {% endfor %}
> {% endblock new %}

The first issue is that the block new is not defined in the base template. 
See the unit test inheritance14:

http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/templates/tests.py#L757
 

That means that the block new will not be rendered, and any variables 
created in that context will not be defined. However, as block b is defined 
in the base, django searches for b in the child anywhere in its node tree. 
It is found and rendered in the right place, but as "k" is undefined, the 
output is simply "\nnew value: \n".

If block new was defined in the base template, the situation would be 
different, and I think it's covered in the tests I posted before where the 
block b would be rendered for each value in the list. I'm not certain 
whether that behaviour is desired or undefined.

All the best,

Steve.


> 
> assuming that there let's say 6 values in the list what is the
> expected result here? The child template defines 6 different variants
> to be placed in a single hole? which one goes? The first? the last?
> all of them? Nested block definition is ok when we define a 'hole',
> but when we define a new value to be placed in a hole it creates
> ambiguity for which I do not see any real use.
> 
> On Sep 23, 2:22 pm, Stephen Kelly
>  wrote:
>> Michael Feingold wrote:
>> > On Sep 23, 2:54 am, Pablo Escobar
>> >  wrote:
>> >> 1. Django is Open Source. It is not a problem to find the parsing
>> >> algorithm
>>
>> > Of course it is And we did go through the code. But reverse
>> > engineering can show you what happens, not what the intention was
>>
>> Usually the unit tests are the best documentation there. However I
>> noticed that in this case there are no unit tests for blocks being
>> nested.
>>
>> I am also the author of a port of the Django system, to C++/Qt in my
>> case.
>>
>> http://www.gitorious.org/grantlee/pages/Home
>>
>> I wrote some tests for nesting of blocks here:
>>
>> http://www.gitorious.org/grantlee/grantlee/commit/85c47cd951e155008a8...
>>
>> Which I'm sure I'll eventually port back up to django. The end result
>> seems to be that {{ block.super }} can behave in ways that you might not
>> expect when blocks are nested.
>>
>> I also found this ticket which probably explains the behaviour I see in
>> the tests when using block.super:
>>
>> http://code.djangoproject.com/ticket/7324
>>
>> All the best,
>>
>> Steve.
> 



--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Session/cookie based messages (#4604)

[David Cramer]

I'm a bit late in here, and it seems we reinvented a wheel as well
(even tho we did this about a year ago), but recently just OS'd our
simply notices system [1]. I'm also +1 for including something like
this in trunk rather than using the current user messages. I had a
brief look at django_notify and its a similar approach, but it seems
much more configurable than what we wrote.

[1] http://github.com/dcramer/django-notices

On Sep 22, 9:49 pm, Tobias McNulty  wrote:
> On Tue, Sep 22, 2009 at 9:51 PM, Russell Keith-Magee 
> > wrote:
> > In reality, I get a ping time closer to 300 ms. And that's to a
> > high-end data center under ideal conditions - it can be much larger if
> > I'm dealing with low end providers.
>
> What?? 200 ms is the average quoted by Mr. Sproutcore himself!
>
> No, in all seriousness, my apologies for making such a broad generalization
> about packet latency.  I could/should have said 500 ms or even a second; the
> argument and corresponding solution, if needed, remain the same.
>
> Anyways..we digress.  I am marking this a non-issue in my own head - please
> pipe up if there's a case to be made.
>
> Tobias
--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Let's Talk About ``to_field``

[Karen Tracey]

On Wed, Sep 23, 2009 at 4:59 PM, David Cramer  wrote:

>
> I haven't brought this up for quite a while, but ``to_field`` still
> does not function properly (at least as of 1.1, I haven't noticed any
> changes addressing it though). The issue is that anywhere you do a GET
> lookup, it doesn't process the to_field properly::
>
># TODO: waiting on to_field fix
>try:
>opt = cls.objects.get(business=business.business_id,
> key=key)
>except cls.DoesNotExist:
>opt = cls.objects.create(business=business, key=key,
> value=value)
>
>
That's supposed to illustrate the problem with to_field?  It's a snippet of
code lacking any context with a cryptic TODO comment.  What is the model
definition here (which would at least give a clue where to_field applies)?
How would this code be different if this "to_field fix" were applied?

This query:

http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&summary=~to_field&order=priority

shows 4 open tickets with the "to_field" in their summary.  Is the problem
you are referring to one of these?


> This seems to have been solved in the admin branch when newforms-admin
> landed, but seems mostly ignored in the core field's. This issue has
> also existed as far as I can remember, which is quite some time :)
>
>
I've not been around as long as you so without reference to a ticket or
something unfortunately I have no idea what problem you are talking about.
I also don't know what you mean by it being fixed in admin but not in "core
fields".  Admin doesn't define fields, so huh?  I can't really parse what
you are trying to say here.



> So, what do we need to get the ball rolling on this. I don't have much
> time myself to commit, but if it's minor things such as writing some
> tests that easily reproduce all errors we've found. We'll glady commit
> those. Other than though my day is just filled, but I'd love to see
> this get fixed. It's something that's advertised as a core feature,
> has been for 3+years, and simply doesn't work.
>
>
The tests you mention filed in a ticket, or attached to one of those tickets
from above if indeed one of those is reporting the problem you are talking
about, would be helpful.  If none of those tickets reflect the problem you
are talking about, then a complete description of the problem would be
helpful; as it is I have no idea what problem you are referring to.


>

On a side note, something that I also believe is a bug, is that
> ManyToManyRel.get_related_field() returns the primary key field no
> matter what. I'm not sure if thats the intended functionality of that
> or not, but to me it sounds like this should refer to the field in the
> through model (even if that model is virtual) that it's pointing to.
>

A filed ticket describing the problem and how to recreate it would have a
better chance of getting remembered and fixed than a side note in an email.

Karen

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Let's Talk About ``to_field``

[David Cramer]

As usual, my apologies for lacking context :)

The problem happens when you try to query with a model containing a foreign
key that references a to_field. It fails to pass the proper attribute.

# Exampe 1, a simple get lookup
class ExampleBrokenModel(models.Model):
user = models.ForeignKey(User, to_field="username")

user = User.objects.get(username="a_username")

# The following will fail due to the fact it's going to try to do user_id=
user.pk, rather
# than user_id=user.username
ExampleBrokenModel.objects.get(user=user)

I will attach additional tests to a ticket, see also [1]

I'm not aware of this ever working properly, but I'm not going to dig up
tickets. You can take my word for it as we've been dealing with it at this
project for a year, and had been working with Django almost 2 years before
that. Either way, it's not a big deal, the fact is it doesn't work as
advertised, and it is advertised.

You would have to talk to the author of newforms-admin, which I believe was
Brian Rosner. There is some special code for handling to_field lookups in
the admin.

[1] http://www.pastethat.com/LUYWh


David Cramer



On Wed, Sep 23, 2009 at 6:27 PM, Karen Tracey  wrote:

> On Wed, Sep 23, 2009 at 4:59 PM, David Cramer  wrote:
>
>>
>> I haven't brought this up for quite a while, but ``to_field`` still
>> does not function properly (at least as of 1.1, I haven't noticed any
>> changes addressing it though). The issue is that anywhere you do a GET
>> lookup, it doesn't process the to_field properly::
>>
>># TODO: waiting on to_field fix
>>try:
>>opt = cls.objects.get(business=business.business_id,
>> key=key)
>>except cls.DoesNotExist:
>>opt = cls.objects.create(business=business, key=key,
>> value=value)
>>
>>
> That's supposed to illustrate the problem with to_field?  It's a snippet of
> code lacking any context with a cryptic TODO comment.  What is the model
> definition here (which would at least give a clue where to_field applies)?
> How would this code be different if this "to_field fix" were applied?
>
> This query:
>
>
> http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&summary=~to_field&order=priority
>
> shows 4 open tickets with the "to_field" in their summary.  Is the problem
> you are referring to one of these?
>
>
>> This seems to have been solved in the admin branch when newforms-admin
>> landed, but seems mostly ignored in the core field's. This issue has
>> also existed as far as I can remember, which is quite some time :)
>>
>>
> I've not been around as long as you so without reference to a ticket or
> something unfortunately I have no idea what problem you are talking about.
> I also don't know what you mean by it being fixed in admin but not in "core
> fields".  Admin doesn't define fields, so huh?  I can't really parse what
> you are trying to say here.
>
>
>
>> So, what do we need to get the ball rolling on this. I don't have much
>> time myself to commit, but if it's minor things such as writing some
>> tests that easily reproduce all errors we've found. We'll glady commit
>> those. Other than though my day is just filled, but I'd love to see
>> this get fixed. It's something that's advertised as a core feature,
>> has been for 3+years, and simply doesn't work.
>>
>>
> The tests you mention filed in a ticket, or attached to one of those
> tickets from above if indeed one of those is reporting the problem you are
> talking about, would be helpful.  If none of those tickets reflect the
> problem you are talking about, then a complete description of the problem
> would be helpful; as it is I have no idea what problem you are referring
> to.
>
>
>>
>
> On a side note, something that I also believe is a bug, is that
>> ManyToManyRel.get_related_field() returns the primary key field no
>> matter what. I'm not sure if thats the intended functionality of that
>> or not, but to me it sounds like this should refer to the field in the
>> through model (even if that model is virtual) that it's pointing to.
>>
>
> A filed ticket describing the problem and how to recreate it would have a
> better chance of getting remembered and fixed than a side note in an email.
>
> Karen
>
> >
>

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Let's Talk About ``to_field``

[David Cramer]

I believe someone had linked a ticket before, but I was unable to find one,
so I went ahead and submitted it here:
http://code.djangoproject.com/ticket/11938

David Cramer



On Wed, Sep 23, 2009 at 6:41 PM, David Cramer  wrote:

> As usual, my apologies for lacking context :)
>
> The problem happens when you try to query with a model containing a foreign
> key that references a to_field. It fails to pass the proper attribute.
>
> # Exampe 1, a simple get lookup
> class ExampleBrokenModel(models.Model):
> user = models.ForeignKey(User, to_field="username")
>
> user = User.objects.get(username="a_username")
>
> # The following will fail due to the fact it's going to try to do user_id=
> user.pk, rather
> # than user_id=user.username
> ExampleBrokenModel.objects.get(user=user)
>
> I will attach additional tests to a ticket, see also [1]
>
> I'm not aware of this ever working properly, but I'm not going to dig up
> tickets. You can take my word for it as we've been dealing with it at this
> project for a year, and had been working with Django almost 2 years before
> that. Either way, it's not a big deal, the fact is it doesn't work as
> advertised, and it is advertised.
>
> You would have to talk to the author of newforms-admin, which I believe was
> Brian Rosner. There is some special code for handling to_field lookups in
> the admin.
>
> [1] http://www.pastethat.com/LUYWh
>
> 
> David Cramer
>
>
>
>
> On Wed, Sep 23, 2009 at 6:27 PM, Karen Tracey  wrote:
>
>> On Wed, Sep 23, 2009 at 4:59 PM, David Cramer  wrote:
>>
>>>
>>> I haven't brought this up for quite a while, but ``to_field`` still
>>> does not function properly (at least as of 1.1, I haven't noticed any
>>> changes addressing it though). The issue is that anywhere you do a GET
>>> lookup, it doesn't process the to_field properly::
>>>
>>># TODO: waiting on to_field fix
>>>try:
>>>opt = cls.objects.get(business=business.business_id,
>>> key=key)
>>>except cls.DoesNotExist:
>>>opt = cls.objects.create(business=business, key=key,
>>> value=value)
>>>
>>>
>> That's supposed to illustrate the problem with to_field?  It's a snippet
>> of code lacking any context with a cryptic TODO comment.  What is the model
>> definition here (which would at least give a clue where to_field applies)?
>> How would this code be different if this "to_field fix" were applied?
>>
>> This query:
>>
>>
>> http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&summary=~to_field&order=priority
>>
>> shows 4 open tickets with the "to_field" in their summary.  Is the problem
>> you are referring to one of these?
>>
>>
>>> This seems to have been solved in the admin branch when newforms-admin
>>> landed, but seems mostly ignored in the core field's. This issue has
>>> also existed as far as I can remember, which is quite some time :)
>>>
>>>
>> I've not been around as long as you so without reference to a ticket or
>> something unfortunately I have no idea what problem you are talking about.
>> I also don't know what you mean by it being fixed in admin but not in "core
>> fields".  Admin doesn't define fields, so huh?  I can't really parse what
>> you are trying to say here.
>>
>>
>>
>>> So, what do we need to get the ball rolling on this. I don't have much
>>> time myself to commit, but if it's minor things such as writing some
>>> tests that easily reproduce all errors we've found. We'll glady commit
>>> those. Other than though my day is just filled, but I'd love to see
>>> this get fixed. It's something that's advertised as a core feature,
>>> has been for 3+years, and simply doesn't work.
>>>
>>>
>> The tests you mention filed in a ticket, or attached to one of those
>> tickets from above if indeed one of those is reporting the problem you are
>> talking about, would be helpful.  If none of those tickets reflect the
>> problem you are talking about, then a complete description of the problem
>> would be helpful; as it is I have no idea what problem you are referring
>> to.
>>
>>
>>>
>>
>> On a side note, something that I also believe is a bug, is that
>>> ManyToManyRel.get_related_field() returns the primary key field no
>>> matter what. I'm not sure if thats the intended functionality of that
>>> or not, but to me it sounds like this should refer to the field in the
>>> through model (even if that model is virtual) that it's pointing to.
>>>
>>
>> A filed ticket describing the problem and how to recreate it would have a
>> better chance of getting remembered and fixed than a side note in an email.
>>
>> Karen
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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, 

Re: decorator_from_middleware change

[Luke Plant]

On Wednesday 23 September 2009 23:40:25 James Bennett wrote:

> So, I've worked out what the problem is.
> 
> Previously either of these worked:
> 
> cache_page(timeout, view)
> cache_page(view, timeout)
> 
> Now, cache_page assumes that the first positional argument will be
>  the timeout. So what we're seeing when running some of our code on
>  trunk is cache_page treating the timeout value (an integer) as the
>  view to be cached, and failing when trying to find things like
>  __module__ attached to it.
> 
> I don't know for certain how many people may be using this idiom,
> since it was never documented (AFAICT cache_page always documented
> itself as putting the timeout first and the view function second),
>  so I'm not really sure what (if anything) we should do about it.
> 
> There may also be deeper issues with the fact that it's not
>  possible to call cache_page with explicit keyword args, since it
>  accepts **kwargs but doesn't do anything with it, always assuming
>  that the timeout and view can be pulled from positional args.

I deliberately wrote it the way it is documented, and only that way. 
So it accepts these forms:

cache_page(timeout, view)
cache_page(timeout)(view)

It shouldn't accept **kwargs though, that's a mistake, because it does 
nothing with them, and it would be better to fail loudly in that case.

I've fixed that, and also added some asserts to get a better error 
message for now unsupported ways of calling it. Do you think this is 
enough?

Luke

-- 
"Pretension: The downside of being better than everyone else is 
that people tend to assume you're pretentious." (despair.com)

Luke Plant || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: decorator_from_middleware change

[Luke Plant]

On Monday 21 September 2009 20:27:50 Jacob Kaplan-Moss wrote:

> No, I think this is precisely correct. I've been meaning to do
>  exactly what you're proposing for a while myself; just haven't
>  gotten around to it.
> 
> > decorator_from_middleware isn't actually documented anywhere
> 
> I actually avoided documenting it because it's broken. Once you fix
> it, we should (i.e. I will, if you don't have time) document it.

OK, it's committed now. (r11586, r11593)

Technically this is a bug fix (#6371), so it ought to get backported 
to 1.1.X.  However, it does actually introduce backwards 
incompatibilities with cache_page (cache_page still works exactly as 
documented, but various people were using various undocumented 
features of it).  Also, you could argue it is a new feature - "these 
decorators now work with methods".

So, in light of those things, should it be backported to 1.1.X or not?

Luke

-- 
"Pretension: The downside of being better than everyone else is 
that people tend to assume you're pretentious." (despair.com)

Luke Plant || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Auth/Session modules and JSON views

[django_fo...@codechimp.net]

This is probably a dumb question, but I am working on some JSON views
that I need to apply authentication too.  I thought maybe I could use
the Django built-in auth/session apps to wrapper the JSON View
methods, but when I do testing I am not seeing the session id being
sent back.  I tried hitting the service from FireFox and from the
iPhone app I am working on, and neither seem to get any headers back
from the server containing anything resembling a session id or cookie
header of any sort.

General rule of thumb: What is the recommended way to secure a JSON
view and where might one find documentation on how this should look?

Again, I do apologize if this is a dumb question and/or there is
documentation somewhere.  I swear I did google and read through the
docs I saw here online and I didn't see any mention of JSON security.

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Auth/Session modules and JSON views

[Alex Gaynor]

On Wed, Sep 23, 2009 at 8:58 PM, django_fo...@codechimp.net
 wrote:
>
> This is probably a dumb question, but I am working on some JSON views
> that I need to apply authentication too.  I thought maybe I could use
> the Django built-in auth/session apps to wrapper the JSON View
> methods, but when I do testing I am not seeing the session id being
> sent back.  I tried hitting the service from FireFox and from the
> iPhone app I am working on, and neither seem to get any headers back
> from the server containing anything resembling a session id or cookie
> header of any sort.
>
> General rule of thumb: What is the recommended way to secure a JSON
> view and where might one find documentation on how this should look?
>
> Again, I do apologize if this is a dumb question and/or there is
> documentation somewhere.  I swear I did google and read through the
> docs I saw here online and I didn't see any mention of JSON security.
>
> >
>

The django-developers mailng list is for the discussion of the
development of django itself.  Please ask this question on the
django-users mailng list.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Django IIS

[Ronn Ross]

Can Django run on IIS?

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django IIS

[Alex Gaynor]

On Wed, Sep 23, 2009 at 9:18 PM, Ronn Ross  wrote:
> Can Django run on IIS?
>
> >
>

The django-developers mailng list is for the discussion of the
developmeny of django itself, not developmeny with Django.  Please ask
the django-users maing list.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---