Re: Next steps for ticket #18150

[Russell Keith-Magee]

On Fri, Feb 1, 2013 at 10:25 AM, Steven Vargas wrote:

> Hi, I'm a student and this is my first contribution to an open source
> project so I am trying to learn along the way.
>
> Anyways, I submitted a patch for 
> #18150and I was looking for 
> input on where to go from here. On the IRC channel it
> was suggested that I upload tests for the patch. Do I have to build an
> django app that utilizes the methods/classes I changed? I was thinking I
> could use unit testing as it seems to make more sense but I'm not exactly
> sure how I would run the unit tests, I have some experience with unit
> testing on simple java applications but nothing like Django, I'm wondering
> where to go from here.
>

In essence, you've got the right idea - you need to write an app that
exercises the new code that you've added. However, you've missed the fact
that Django provides a lot of the testing infrastructure for you.

Django's has it's own test suite -- the code is contained in the top-level
"tests" directory. This test suite consists of a collection of test apps
that exercise much of the functionality of Django.

Instructions for running Django's test suite can be found here:

https://docs.djangoproject.com/en/1.4/internals/contributing/writing-code/unit-tests/

Specifically, if you look in the tests/regressiontests/file_uploads
directory, you'll find a bunch of existing tests for file uploads. What you
need to do is add a new test -- one that fails by default, but passes when
you add your fix. Include that fix as part of your overall patch, and
you're done!

Yours,
Russ Magee %-)

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

Re: Form.set_data method

[Yo-Yo Ma]

With all respect, this seems like a bad idea; there would be little, if any, 
gain from having this method.

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

Next steps for ticket #18150

[Steven Vargas]

Hi, I'm a student and this is my first contribution to an open source 
project so I am trying to learn along the way.

Anyways, I submitted a patch for 
#18150and I was looking for input 
on where to go from here. On the IRC channel it 
was suggested that I upload tests for the patch. Do I have to build an 
django app that utilizes the methods/classes I changed? I was thinking I 
could use unit testing as it seems to make more sense but I'm not exactly 
sure how I would run the unit tests, I have some experience with unit 
testing on simple java applications but nothing like Django, I'm wondering 
where to go from here.

Thanks!

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

Re: cycle in nested loops

[Aymeric Augustin]

Hi Wim,

Le 21 janv. 2013 à 18:01, Wim Feijen  a écrit :
> Actually, the current behaviour is not to reset between loops. Is that 
> intentional? 

Yes, this behavior is intentional. See Malcolm's comment (#4) on the ticket.

> A patch to ticket 5908 adds a reset_cycle tag, which resets the cycle-loop. I 
> am wondering if it is the right way to solve this problem

That's what Malcolm said, and I tend to agree with him. I'm not particularly 
excited by adding a new tag but I don't have a better idea. Something like {% 
cycle row_colors reset %} would conflict with the regular {% cycle %} syntax.

> or whether it would be better to modify cycle's current behaviour to reset 
> the loop after each endfor; or maybe if we want another kind of cycle which 
> allows for setting both options?

I don't think we could justify the backwards incompatibility for the current {% 
cycle %} tag. Besides, introducing coupling between {% cycle %} and {% for %} / 
{% endfor %} sounds like a bad idea.

-- 
Aymeric.



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

Re: [Future feature?] Viewsets

[Wim Feijen]

Hi,

Just wanted to draw your attention to a proposal made by Zachary Voase, 
which you might be unaware of. It has no code, but is just a proposal, 
having a very clean api IMHO.

http://zacharyvoase.com/2013/01/22/django-objviews/

Cheers, Wim

On Saturday, 26 January 2013 04:04:57 UTC+1, Bertrand Bordage wrote:
>
> Hi,
>
> This is my first message here, though I am using Django every day since 
> two years.
>
> Yesterday I read a Ruby on Rails tutorial and this gave me an idea of what 
> could IMO be a nice feature: viewsets.
> I therefore started a tiny project, 
> django-viewsets 
> (djangonauts 
> have weird reflexes… ^^).  *Everything is explained there.*
>
> What do you think?  Could this be an interesting feature?  “The next level 
> of class-based views”?  A *contrib* application?
>
> Regards,
> Bertrand
>

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

Re: Form.set_data method

[Alex Ogier]

The problem is that if you use your idiom, data and files are None when the
class is instantiated. This is currently a sign that the form has no data
attached. Currently, if you want to massage input data before cleaning, you
do it using either form of of overriding __init__ as you describe. But if
you call "form = MyForm(); form.set_data(request.POST, request.FILES)" then
code in __init__ runs while data and files are None, and doesn't have a
chance to run when you set them to proper values.

I'm not sure that this is actually such a concern. It is backwards
compatible, in the sense that any Django site that ran before the change
will continue to run after the change. It would be incompatible to start
using set_data instead of the constructor in Django core when it
instantiates a user-provided form class (maybe the admin does this? I can't
remember). Regardless, it adds complexity to any form subclasses, which
have to handle additional entry points for form data, and understand the
way the constructor calls the set_data method (for example, your patch
calls set_data before setting any of the other fields typically present on
a form, so subclasses may see unexpected things if they override it). So
I'm -0 due to the additional complexity for something which is already
possible and has a widely used idiom, even if it is more verbose.

Best,
Alex Ogier


On Thu, Jan 31, 2013 at 12:13 PM, Byron Ruth  wrote:

> I don't want to belabor our difference in understanding/opinion, but there
> are two ways to extend __init__. Processing before super is called, and
> processing after super is called:
>
> # Common pre-processing..
> class MyForm(forms.Form):
> def __init__(self, request, *args, **kwargs):
> # Use downstream somewhere..
> self.request = request
> super(MyForm, self).__init__(*args, **kwargs)
>
> # Common post-processing..
> class MyForm(forms.Form):
> def __init__(self, *args, **kwargs):
> super(MyForm, self).__init__(*args, **kwargs)
> # tweak various field properties..
>
> In either case, the `data` and `files` attributes are set as they were
> before which means they are still available just like before. Am I missing
> something? Do you or Shai have a real example that would correct
> understanding?
>
> On Jan 31, 2013, at 11:56 AM, Alex Ogier  wrote:
>
> Byron, I think Shai is suggesting that a user's form class may do extra
> processing in __init__ on the data and files fields. If someone starts
> using the new pattern in their views, it will break those classes because
> they expect the initializer to be called with valid data when there is any.
> Your new method will bypass their customizations.
>
> Best,
> Alex Ogier
>
>
> On Thu, Jan 31, 2013 at 8:51 AM, Byron Ruth  wrote:
>
>> I don't understand your argument regarding overriding `__init__`. Nothing
>> has changed in __init__, the logic for setting `data` and `files` is simply
>> moved to a method. You _can_ still pass `request.POST` and `request.FILES`
>> into the constructor. If a user extends __init__ (I do it all the time),
>> you still need (are expected) to call `super` to _finish_ initialization.
>>
>>
>> On Thursday, January 31, 2013 1:08:52 AM UTC-5, Shai Berger wrote:
>>>
>>> On Thursday 31 January 2013, Byron Ruth wrote:
>>> > Here is the ticket: 
>>> > https://code.djangoproject.**com/ticket/19668and
>>> >  the
>>> > pull request 
>>> > https://github.com/django/**django/pull/674
>>> >
>>> > One user commented on the ticket raising a concern that it could
>>> possibly
>>> > be misused if the data is set after it had been used. It is certainly
>>> a
>>> > valid concern, however it should be made clear in the docs when to use
>>> it
>>> > and/or raise an exception if `is_valid` has already been called.
>>> >
>>> > Thoughts?
>>>
>>> While this is backwards-compatible per se, using it in views is
>>> generally not
>>> backwards-compatible with user form classes (you can't tell what they do
>>> in
>>> their initializers); thus, generic views (and also some not-generic
>>> views) are
>>> forced to keep using the "old way" unless the (user) form code is
>>> altered.
>>> Which means, you'll have two ways to do the same thing (in views),
>>> without a
>>> clear preference between them.
>>>
>>> So if you want this judged as a backwards-compatible change, I'm -1.
>>>
>>> As a non-backwards-compatible change, I'd like it, but I don't think
>>> it's
>>> worth the disruption, so I'm -0.
>>>
>>> Either way, I'm not a core dev.
>>>
>>> Shai.
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to 

Re: Simplify the default project template

[Aymeric Augustin]

Le 31 janv. 2013 à 17:46, Josh Cartmell  a écrit :

> I think a little more explanation regarding it's unsuitability would
> make it a lot less scary.  In line with what you have done here it
> might make sense to add a new section to the docs describing how to
> make the default settings production ready and then link to it after
> that statement.


Indeed, that's the plan — we just need someone to write that document :)

https://code.djangoproject.com/ticket/19697

-- 
Aymeric.



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

Re: Possible ORM bug with SQL syntax & generic relations

[Dylan Klomparens]

I have confirmed that removing the ordering line from the Meta class of the
model hides this bug. It looks as though your first assessment was spot on,
Ian :-).


On Thu, Jan 31, 2013 at 11:40 AM, Dylan Klomparens <
dylan.klompar...@gmail.com> wrote:

> Some additional information: here is the error page received.
>
>
> On Thu, Jan 31, 2013 at 11:06 AM, Dylan Klomparens <
> dylan.klompar...@gmail.com> wrote:
>
>> Ah, after a second look, yes you are right, it was a transcription error
>> with the number of parenthesis. Apologies for the confusion! I've attached
>> the model admin. The Django version is:
>>
>> >>> import django
>> >>> django.VERSION
>> (1, 5, 0, 'rc', 1)
>>
>> -- Dylan
>>
>>
>> On Thu, Jan 31, 2013 at 2:04 AM, Ian Kelly  wrote:
>>
>>> On Wed, Jan 30, 2013 at 10:10 PM, Dylan Klomparens
>>>  wrote:
>>> > It's interesting this seems to work with 10g XE. I am not sure if this
>>> is
>>> > relevant, but I am using the Full Oracle Client with Administrative
>>> Tools
>>> > (as oppose to the Oracle Instant Client) and cx_Oracle for Python
>>> access to
>>> > the database. The error I felt was most problematic is that the SQL
>>> > statement has 4 opening parenthesis, and only 3 closing parenthesis.
>>> This
>>> > kind of statement work in Oracle 10g XE?
>>>
>>> I noticed that also, but I thought that perhaps it was a transcription
>>> error, since you said it works with sqlite3.  The Oracle version
>>> should not make any difference for this query.  More likely I just
>>> didn't hit the same query.  What version of Django are you using?
>>> Also it might help if you posted your ModelAdmin, in case that's
>>> affecting the query.  My test used a default ModelAdmin.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at
>>> http://groups.google.com/group/django-developers?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>

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

Re: Form.set_data method

[Byron Ruth]

I don't want to belabor our difference in understanding/opinion, but there are 
two ways to extend __init__. Processing before super is called, and processing 
after super is called:

# Common pre-processing..
class MyForm(forms.Form):
def __init__(self, request, *args, **kwargs):
# Use downstream somewhere..
self.request = request
super(MyForm, self).__init__(*args, **kwargs)

# Common post-processing..
class MyForm(forms.Form):
def __init__(self, *args, **kwargs):
super(MyForm, self).__init__(*args, **kwargs)
# tweak various field properties..

In either case, the `data` and `files` attributes are set as they were before 
which means they are still available just like before. Am I missing something? 
Do you or Shai have a real example that would correct understanding?

On Jan 31, 2013, at 11:56 AM, Alex Ogier  wrote:

> Byron, I think Shai is suggesting that a user's form class may do extra 
> processing in __init__ on the data and files fields. If someone starts using 
> the new pattern in their views, it will break those classes because they 
> expect the initializer to be called with valid data when there is any. Your 
> new method will bypass their customizations.
> 
> Best,
> Alex Ogier
> 
> 
> On Thu, Jan 31, 2013 at 8:51 AM, Byron Ruth  wrote:
> I don't understand your argument regarding overriding `__init__`. Nothing has 
> changed in __init__, the logic for setting `data` and `files` is simply moved 
> to a method. You _can_ still pass `request.POST` and `request.FILES` into the 
> constructor. If a user extends __init__ (I do it all the time), you still 
> need (are expected) to call `super` to _finish_ initialization.
> 
> 
> On Thursday, January 31, 2013 1:08:52 AM UTC-5, Shai Berger wrote:
> On Thursday 31 January 2013, Byron Ruth wrote: 
> > Here is the ticket: https://code.djangoproject.com/ticket/19668 and the 
> > pull request https://github.com/django/django/pull/674 
> > 
> > One user commented on the ticket raising a concern that it could possibly 
> > be misused if the data is set after it had been used. It is certainly a 
> > valid concern, however it should be made clear in the docs when to use it 
> > and/or raise an exception if `is_valid` has already been called. 
> > 
> > Thoughts? 
> 
> While this is backwards-compatible per se, using it in views is generally not 
> backwards-compatible with user form classes (you can't tell what they do in 
> their initializers); thus, generic views (and also some not-generic views) 
> are 
> forced to keep using the "old way" unless the (user) form code is altered. 
> Which means, you'll have two ways to do the same thing (in views), without a 
> clear preference between them. 
> 
> So if you want this judged as a backwards-compatible change, I'm -1. 
> 
> As a non-backwards-compatible change, I'd like it, but I don't think it's 
> worth the disruption, so I'm -0. 
> 
> Either way, I'm not a core dev. 
> 
> Shai. 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

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

Re: Form.set_data method

[Alex Ogier]

Byron, I think Shai is suggesting that a user's form class may do extra
processing in __init__ on the data and files fields. If someone starts
using the new pattern in their views, it will break those classes because
they expect the initializer to be called with valid data when there is any.
Your new method will bypass their customizations.

Best,
Alex Ogier


On Thu, Jan 31, 2013 at 8:51 AM, Byron Ruth  wrote:

> I don't understand your argument regarding overriding `__init__`. Nothing
> has changed in __init__, the logic for setting `data` and `files` is simply
> moved to a method. You _can_ still pass `request.POST` and `request.FILES`
> into the constructor. If a user extends __init__ (I do it all the time),
> you still need (are expected) to call `super` to _finish_ initialization.
>
>
> On Thursday, January 31, 2013 1:08:52 AM UTC-5, Shai Berger wrote:
>>
>> On Thursday 31 January 2013, Byron Ruth wrote:
>> > Here is the ticket: 
>> > https://code.djangoproject.**com/ticket/19668and
>> >  the
>> > pull request 
>> > https://github.com/django/**django/pull/674
>> >
>> > One user commented on the ticket raising a concern that it could
>> possibly
>> > be misused if the data is set after it had been used. It is certainly a
>> > valid concern, however it should be made clear in the docs when to use
>> it
>> > and/or raise an exception if `is_valid` has already been called.
>> >
>> > Thoughts?
>>
>> While this is backwards-compatible per se, using it in views is generally
>> not
>> backwards-compatible with user form classes (you can't tell what they do
>> in
>> their initializers); thus, generic views (and also some not-generic
>> views) are
>> forced to keep using the "old way" unless the (user) form code is
>> altered.
>> Which means, you'll have two ways to do the same thing (in views),
>> without a
>> clear preference between them.
>>
>> So if you want this judged as a backwards-compatible change, I'm -1.
>>
>> As a non-backwards-compatible change, I'd like it, but I don't think it's
>> worth the disruption, so I'm -0.
>>
>> Either way, I'm not a core dev.
>>
>> Shai.
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: Simplify the default project template

[Josh Cartmell]

Long time lurker here.  Anyways, one thing that I think might trip up
beginners is this line:
# Quick-start development settings - unsuitable for production

For a beginner that could be a very daunting statement that could
leave them wondering:
Why is this unsuitable for production and what is suitable for
production?  Is it inefficient or insecure or both?

I think a little more explanation regarding it's unsuitability would
make it a lot less scary.  In line with what you have done here it
might make sense to add a new section to the docs describing how to
make the default settings production ready and then link to it after
that statement.

On Jan 29, 1:01 pm, Aymeric Augustin
 wrote:
> Hello,
>
> I took into account the feedback received here and on IRC (thanks everyone!) 
> and I now have a branch ready for review:
>
> https://github.com/aaugustin/django/compare/simplify-project-template
>
> The commit messages give some hints about the reasoning behind each change. 
> I'll be glad to provide more detailed explanations if necessary.
>
> Like Jacob said, everyone here would certainly do this a bit differently. 
> Let's avoid bikeshedding — if you can't resist, tell me in private — and look 
> for problems such as:
>         - I got the priorities wrong: forgot something important / included 
> something useless,
>         - I missed some best practices,
>         - I did something that's likely to trip up beginners,
>         - etc.
>
> I plan to commit this next week. Let me know if you'd like more time to 
> review.
>
> Thank you,
>
> --
> Aymeric.

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

Re: Possible ORM bug with SQL syntax & generic relations

[Dylan Klomparens]

Ah, after a second look, yes you are right, it was a transcription error
with the number of parenthesis. Apologies for the confusion! I've attached
the model admin. The Django version is:

>>> import django
>>> django.VERSION
(1, 5, 0, 'rc', 1)

-- Dylan


On Thu, Jan 31, 2013 at 2:04 AM, Ian Kelly  wrote:

> On Wed, Jan 30, 2013 at 10:10 PM, Dylan Klomparens
>  wrote:
> > It's interesting this seems to work with 10g XE. I am not sure if this is
> > relevant, but I am using the Full Oracle Client with Administrative Tools
> > (as oppose to the Oracle Instant Client) and cx_Oracle for Python access
> to
> > the database. The error I felt was most problematic is that the SQL
> > statement has 4 opening parenthesis, and only 3 closing parenthesis. This
> > kind of statement work in Oracle 10g XE?
>
> I noticed that also, but I thought that perhaps it was a transcription
> error, since you said it works with sqlite3.  The Oracle version
> should not make any difference for this query.  More likely I just
> didn't hit the same query.  What version of Django are you using?
> Also it might help if you posted your ModelAdmin, in case that's
> affecting the query.  My test used a default ModelAdmin.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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


class ActivityHistoryAdmin(admin.ModelAdmin):
list_display = ('__str__', 'content_type', 'object_id', 'action', 
'date', 'authorizer')
date_hierarchy = 'date'
admin.site.register(ActivityHistory, ActivityHistoryAdmin)

Re: Form.set_data method

[Byron Ruth]

I don't understand your argument regarding overriding `__init__`. Nothing 
has changed in __init__, the logic for setting `data` and `files` is simply 
moved to a method. You _can_ still pass `request.POST` and `request.FILES` 
into the constructor. If a user extends __init__ (I do it all the time), 
you still need (are expected) to call `super` to _finish_ initialization.

On Thursday, January 31, 2013 1:08:52 AM UTC-5, Shai Berger wrote:
>
> On Thursday 31 January 2013, Byron Ruth wrote: 
> > Here is the ticket: https://code.djangoproject.com/ticket/19668 and the 
> > pull request https://github.com/django/django/pull/674 
> > 
> > One user commented on the ticket raising a concern that it could 
> possibly 
> > be misused if the data is set after it had been used. It is certainly a 
> > valid concern, however it should be made clear in the docs when to use 
> it 
> > and/or raise an exception if `is_valid` has already been called. 
> > 
> > Thoughts? 
>
> While this is backwards-compatible per se, using it in views is generally 
> not 
> backwards-compatible with user form classes (you can't tell what they do 
> in 
> their initializers); thus, generic views (and also some not-generic views) 
> are 
> forced to keep using the "old way" unless the (user) form code is altered. 
> Which means, you'll have two ways to do the same thing (in views), without 
> a 
> clear preference between them. 
>
> So if you want this judged as a backwards-compatible change, I'm -1. 
>
> As a non-backwards-compatible change, I'd like it, but I don't think it's 
> worth the disruption, so I'm -0. 
>
> Either way, I'm not a core dev. 
>
> Shai. 
>
>

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

Re: Viewsets

[Amirouche Boubekki]

Héllo Anssi,

2013/1/31 Anssi Kääriäinen 

> On 28 tammi, 21:08, Bertrand Bordage 
> wrote:
> > > I know this answer isn't wanted... But testing different
> > > implementations outside Django core/contrib is IMHO the right way to
> > > go.
> >
> > OK, so, discussion closed.
>
> My intention wasn't to stop discussion about this feature,


Sorry, I'm busy so I was waiting for the weekend to answer to posts.


> just to say
> that it is unlikely to get into Django until there is a proven way to
> implement this feature. And by proven I mean there is a 3rd party app
> that has enough users.
>

Yes...


> It might be that there isn't a single approach to this, and in that
> case multiple different implementations outside core is the way to go.
> If there is something common between most implementations, then core/
> contrib is the right place for those shared bits.
>
> Looking at the discussion history maybe finding those shared bits was
> all you were trying to do...
>

Yes

To give a bit of background on my take on this, it was while experimenting
on a rewrite of the admin that
lead me to UrlCollection.

CompositeView is one part which deals with Composition inside a view and
another part
is UrlCollection which deals with urls and thus views. Both are not needed
for the admin
to work but since it's a rewrite I wanted to take the time to extract
interesting pieces that could
be reused outside of the admin. The other part of the admin that is not
extracted from the admin yet,
is a class that deals with Forms and Formsets so that both ForeignKey and
M2M can be created in one
page.

So it's likely to be a useful pattern...


> So, what I want is:
>   - To use self of the view collection class to bind data to templates
> (that is, one instance per request).
>

I read one instance of «view collection» per request otherwise you break
thread safety

  - To use self to call shared functionality between views. That is, I
> want to implement both history_view() and the update_view() in the
> same class, so that both of them can call shared methods.
>

This can be achieved with inheritance, do you have an example of sharing
data between views
that can not be achieved with View init_kwargs ?

Actually first version of UrlCollection was binding UrlCollection made
available a property on every view part of it,
that was returning a new instance of UrlCollection when accessed... Thus it
was possible to do:

class MyView(View):

   def get_queryset(self, *args, **kwargs):
   return dict('queryset', self.collection.get_queryset())

But I stripped that because not efficient and not needed because I think
it's possible to do everything you need through init_kwargs.


> If I understand this pattern correctly
>
> class HistoryView(View):
> [do something…]
>


> class CustomModelViewSet(ModelViewSet):
> excluded_views = ('create_view', 'update_view', 'delete_view')
> def __init__(self, *args, **kwargs):
> self.views['history_view'] = {
> 'view': HistoryView,
> 'pattern': r'history',
> 'name': 'history',
> 'kwargs': { custom view attributes and methods here },
> }
> super(self, CustomViewSet).__init__(*args, **kwargs)
>
> here HistoryView and UpdateView can't share functionality?
>

Yes.


> I think we are aiming for different use cases, the viewset pattern
> seems to be about tying together multiple existing views, while the
> MultiViews pattern is about creating the views in a single class.
>

Can you describe or give an example of MultiView usage ? Here is an dull
example of 
UrlCollection,
there not declarative API since it's meant to be the base for anything
fancier ;)

Also I still don't agree with the naming, except if I didn't understand
this part, those projects are dealing with views through defining urls for
them. So the Collection class should be UrlCollection or something not
ViewCollection or MultiView.

Regards,

Amirouche

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

Re: Viewsets

[Anssi Kääriäinen]

On 28 tammi, 21:08, Bertrand Bordage 
wrote:
> > I know this answer isn't wanted... But testing different
> > implementations outside Django core/contrib is IMHO the right way to
> > go.
>
> OK, so, discussion closed.

My intention wasn't to stop discussion about this feature, just to say
that it is unlikely to get into Django until there is a proven way to
implement this feature. And by proven I mean there is a 3rd party app
that has enough users.

It might be that there isn't a single approach to this, and in that
case multiple different implementations outside core is the way to go.
If there is something common between most implementations, then core/
contrib is the right place for those shared bits.

Looking at the discussion history maybe finding those shared bits was
all you were trying to do...

So, what I want is:
  - To use self of the view collection class to bind data to templates
(that is, one instance per request).
  - To use self to call shared functionality between views. That is, I
want to implement both history_view() and the update_view() in the
same class, so that both of them can call shared methods.

If I understand this pattern correctly

class HistoryView(View):
[do something…]
class CustomModelViewSet(ModelViewSet):
excluded_views = ('create_view', 'update_view', 'delete_view')
def __init__(self, *args, **kwargs):
self.views['history_view'] = {
'view': HistoryView,
'pattern': r'history',
'name': 'history',
'kwargs': { custom view attributes and methods here },
}
super(self, CustomViewSet).__init__(*args, **kwargs)

here HistoryView and UpdateView can't share functionality?

I think we are aiming for different use cases, the viewset pattern
seems to be about tying together multiple existing views, while the
MultiViews pattern is about creating the views in a single class.

 - Anssi

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