Sent from my iPad
On 12/06/2010, at 7:15 AM, Simon Meers wrote:
>>> * Permissions - from my initial inspection, it isn't obvious to me
>>> that you are honoring (and/or testing that you are honoring)
>>> permissions. If I don't have permission to edit an object, I shouldn't
>>> get an edit li
Sent from my iPad
On 09/06/2010, at 8:33 PM, Simon Meers wrote:
>> The demo screenshots you provide certainly look good to me; I haven't
>> done a full teardown on the patch, but a from a quick glance it
>> certainly looks promising.
>
> Thanks for your response Russ.
>
>> * Why allow edit
On Saturday, June 12, 2010, Andrew Godwin wrote:
>
>
> On 11/06/2010 17:38, Russell Keith-Magee wrote:
>
> You're not missing anything specific -- it's really just a matter of
> time. Good documentation take time to write; doubly so for good
> tutorials.
>
> The issue you raise - that the current
>> * Permissions - from my initial inspection, it isn't obvious to me
>> that you are honoring (and/or testing that you are honoring)
>> permissions. If I don't have permission to edit an object, I shouldn't
>> get an edit link. Given the addition in 1.2 of object-level
>> permissions, this means
turns out there is a problem, the field looks for "://" anywhere on the
value but according to the RFC the colon is allowed on paths, so an url like
'www.example.com/://' should validate and it fails:
Python 2.6.4 (r264:75706, Jan 25 2010, 08:55:26)
[GCC 4.4.2 20091208 (prerelease)] on linux2
Type
On Fri, Jun 11, 2010 at 3:13 PM, Tom Evans wrote:
> On Fri, Jun 11, 2010 at 11:41 AM, jjmurre wrote:
>> Hi,
>>
>> I am using long living session in the database backend. Because of
>> Robots I am getting a huge amount of sessions. I googled if there is
>> some kind of Session middleware that does
looking at the order in which the methods are called on the Field class it
seems the default "http://"; is added before the validator gets called so it
should work as expected, don't know where the error in validation was coming
from.
On Fri, Jun 11, 2010 at 2:28 PM, Michael Cetrulo wrote:
> hell
On 11/06/2010 17:38, Russell Keith-Magee wrote:
You're not missing anything specific -- it's really just a matter of
time. Good documentation take time to write; doubly so for good
tutorials.
The issue you raise - that the current tutorial is exclusively "app
inside project" has been raised as
hello, something just came up on #django and I think it's worth asking here;
turns out current URLValidator
http://code.djangoproject.com/browser/django/tags/releases/1.2.1/django/core/validators.py#L41forbids
urls without protocol however the URLField that uses it tries to add
a default "http://";
On Fri, Jun 11, 2010 at 7:34 PM, Patryk Zawadzki wrote:
> Maybe something simpler?
Actually you might want to have a couple of instances with different
__init__ params:
8<
from threading import local, Thread
class View(object):
_child = local()
def __new__(cls, *args, **kwar
On Fri, Jun 4, 2010 at 1:53 PM, Roald wrote:
> class my_view(HttpResponse):
> __metaclass__ = ABCMeta
>
> def __init__(self, *args, **kwargs):
> print 'init my_view'
>
> def __new__(cls, *args, **kwargs):
> if some_condition():
> return
On Fri, Jun 11, 2010 at 1:21 AM, Andrew Godwin wrote:
> Hi all,
>
> I noticed today that the tutorial still does imports like "from
> mysite.polls.models import Poll", and URLs like "(r'^polls/$',
> 'mysite.polls.views.index')".
It also says "coming soon" at the end of tutorial 4. It has said tha
Speaking as someone who got up to speed on both Django and python in the last
year or so, I'd have loved to have been pointed to virtualenv, pip and the
stack early on in the learning process. I will say that I am an experienced
developer, so I was used to these kinds of technologies and wanting
On 11/06/10 17:00, Peter Baumgartner wrote:
> Why do your two sites need to share the same python path? Virtualenv
> solves this problem quite gracefully.
>
They don't have to, but bear in mind that:
a) The tutorial is aimed at people new to Django, and often new to
Python. Virtualenv isn't e
On Fri, Jun 11, 2010 at 5:25 PM, Russell Keith-Magee
wrote:
> On Thu, Jun 10, 2010 at 10:18 PM, Waldemar Kornewald
> wrote:
>> That's right. We believe that the long-term advantages of having a
>> common AutoField for everyone outweigh the short-term disadvantage of
>> a few people having to migr
On Fri, Jun 11, 2010 at 9:16 AM, Andrew Godwin wrote:
>
>
> On 11/06/2010 03:28, Peter Baumgartner wrote:
>>
>> In my experience, almost every project has domain-specific
>> applications that don't get reused. If you have a reusable app, you
>> bundle it separately (like South).
>>
>
> I entirely
On Thu, Jun 10, 2010 at 10:18 PM, Waldemar Kornewald
wrote:
> On Thu, Jun 10, 2010 at 2:31 PM, Russell Keith-Magee
> wrote:
>> On Wed, Jun 9, 2010 at 4:25 AM, Waldemar Kornewald
>> wrote:
>>> By not supporting string-based primary keys the MongoDB and SimpleDB
>>> communities will have to maint
On Fri, Jun 11, 2010 at 12:22 AM, Waldemar Kornewald
wrote:
> On Thursday, June 10, 2010, Dj Gilcrease wrote:
>> Wouldnt an autofield like http://dpaste.com/hold/205665/ work where
>> connection.creation.auto_field_base_type is set to int by default in
>> django/db/backends/creation.py but could
On Fri, Jun 11, 2010 at 10:16 AM, Andrew Godwin wrote:
>> I agree that it is confusing that it will work either way, but I'd
>> argue in favor of using the project name everywhere. It is explicit
>> instead of mucking around with the Python path behind the scenes.
>>
>
> Explicitness is good. I li
On 11/06/2010 03:28, Peter Baumgartner wrote:
In my experience, almost every project has domain-specific
applications that don't get reused. If you have a reusable app, you
bundle it separately (like South).
I entirely agree, but there's also a lot of domain-specific apps people
make tha
On Jun 11, 1:11 pm, Russell Keith-Magee
wrote:
> On Fri, Jun 11, 2010 at 6:47 PM, George Sakkis
> wrote:
> > Maybe I'm missing something but I don't see why the lack of of
> > remove() and add() for ManyToManyFields with 'through' model is
> > necessary.
>
> > For remove, the docs say "The remo
On Fri, Jun 11, 2010 at 11:41 AM, jjmurre wrote:
> Hi,
>
> I am using long living session in the database backend. Because of
> Robots I am getting a huge amount of sessions. I googled if there is
> some kind of Session middleware that does user-agent blacklisting and
> does not create new session
Hi,
I am using long living session in the database backend. Because of
Robots I am getting a huge amount of sessions. I googled if there is
some kind of Session middleware that does user-agent blacklisting and
does not create new sessions in the database for Robots accessing the
site. I did not fi
On Fri, Jun 11, 2010 at 6:47 PM, George Sakkis wrote:
> Maybe I'm missing something but I don't see why the lack of of
> remove() and add() for ManyToManyFields with 'through' model is
> necessary.
>
> For remove, the docs say "The remove method is disabled for similar
> reasons (to add)" but it's
Maybe I'm missing something but I don't see why the lack of of
remove() and add() for ManyToManyFields with 'through' model is
necessary.
For remove, the docs say "The remove method is disabled for similar
reasons (to add)" but it's not clear why. All it is required for
"beatles.members.remove(joh
25 matches
Mail list logo
