Should I split ticket #16502 in three tickets or not?

[Silver_Ghost]

There is a comment to ticket ticket #16502 from ptone.  He recommends to create two new tickets, one for get_model patch and one for select_template patch.  In my opinion separating select_template patch is a good idea while separating get_model patch isn't.  This is because adding get_model method fully fixes ticket #16502.

What should I do?  If creating two new tickets as ptone suggests is a right way then how to show relation between this three tickets?

[Aymeric Augustin]

Hello,

Yes, I think ticket #16502 should focus on the problem of CreateView: why doesn't it have a default template and does it need one?

The other issues you discovered while investigating that problem should go into separate tickets.

Best regards,

-- 

Aymeric Augustin.

On 15 sept. 2011, at 09:12, Silver_Ghost wrote:

There is a comment to ticket ticket #16502 from ptone.  He recommends to create two new tickets, one for get_model patch and one for select_template patch.  In my opinion separating select_template patch is a good idea while separating get_model patch isn't.  This is because adding get_model method fully fixes ticket #16502.

What should I do?  If creating two new tickets as ptone suggests is a right way then how to show relation between this three tickets?

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/zQT8_CaxmyUJ.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[TiNo]

I agree. But the problem is this: CreateView has a default template: %app_name%/%model_name%_form.html , however, it should raise an error if no queryset or model is passed. The SingleObjectMixin-get_model.diff patch does this. It just needs tests.

I would create a seperate ticket for handling an empty list of templates.

Tino 

[Silver_Ghost]

I've already started on splitting patches so let me finish a work and separate tickets :)

As I understand the problem, there should be patch without addition of `get_model` to resolve #16502 with tests, patch (and another ticket) which adds `get_model` with tests specially for `get_model` and patch (also in another ticket) for handling an empty list of candidates in `select_template`.  Is it right?

пятница, 16 сентября 2011 г. 15:12:16 UTC+6 пользователь TiNo написал:

[TiNo]

I think the get_model method serves well. As there are multiple ways to define which model should be used (the self.model, self.queryset or self.form_class attributes) it justifies having a utility function for it.

If you write tests for #16502 that pass with #16502 fixed with the get_model method things should be allright in my opinion.

Tino

2011/9/16 Silver_Ghost <silver...@gmail.com>

To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/JNNtKtXZ7LQJ.

[Silver_Ghost]

Yes, there are tests for both #16502 and handling empty list of templates in third patch.  So separating `select_template` issue is only necessary?

On Friday, September 16, 2011 7:24:32 PM UTC+6, TiNo wrote:

I think the get_model method serves well. As there are multiple ways to define which model should be used (the self.model, self.queryset or self.form_class attributes) it justifies having a utility function for it.

If you write tests for #16502 that pass with #16502 fixed with the get_model method things should be allright in my opinion.

Tino

2011/9/16 Silver_Ghost <silver...@gmail.com>

I've already started on splitting patches so let me finish a work and separate tickets :)

As I understand the problem, there should be patch without addition of `get_model` to resolve #16502 with tests, patch (and another ticket) which adds `get_model` with tests specially for `get_model` and patch (also in another ticket) for handling an empty list of candidates in `select_template`.  Is it right?

пятница, 16 сентября 2011 г. 15:12:16 UTC+6 пользователь TiNo написал:

I agree. But the problem is this: CreateView has a default template: %app_name%/%model_name%_form.html , however, it should raise an error if no queryset or model is passed. The SingleObjectMixin-get_model.diff patch does this. It just needs tests.

I would create a seperate ticket for handling an empty list of templates.

Tino 

On Thu, Sep 15, 2011 at 21:51, Aymeric Augustin <aymer...@polytechnique.org> wrote:

Hello,

Yes, I think ticket #16502 should focus on the problem of CreateView: why doesn't it have a default template and does it need one?

The other issues you discovered while investigating that problem should go into separate tickets.

Best regards,

-- 

Aymeric Augustin.

On 15 sept. 2011, at 09:12, Silver_Ghost wrote:

There is a comment to ticket ticket #16502 from ptone.  He recommends to create two new tickets, one for get_model patch and one for select_template patch.  In my opinion separating select_template patch is a good idea while separating get_model patch isn't.  This is because adding get_model method fully fixes ticket #16502.

What should I do?  If creating two new tickets as ptone suggests is a right way then how to show relation between this three tickets?

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/zQT8_CaxmyUJ.

To post to this group, send email to djang...@googlegroups.com.

To unsubscribe from this group, send email to django-develop...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

--
You received this message because you are subscribed to the Google Groups "Django developers" group.

To post to this group, send email to djang...@googlegroups.com.

To unsubscribe from this group, send email to django-develop...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.