On 12 November 2010 03:12, Russell Keith-Magee <russ...@keith-magee.com> wrote:
> 2010/11/12 Łukasz Rekucki <lreku...@gmail.com>:
>> On 12 November 2010 01:45, Ian Lewis <ianmle...@gmail.com> wrote:
>>> 2010/11/12 Łukasz Rekucki <lreku...@gmail.com>
>>>>
>>>> On 12 November 2010 01:16, hcarvalhoalves <hcarvalhoal...@gmail.com>
>>>> wrote:
>>>> > What about having an official 1.3 feedback thread at django-developers
>>>> > list? ;)
>>>> >
>>>> > I'm liking the pack of small improvements coming in this release, and
>>>> > timing is very good, well done. I must say I'm less than happy with
>>>> > the view classes though. Is the API on it frozen already?
>>>>
>>>> IMHO no, but it reached a point where the only way to make it better
>>>> was to have it released to the wild and see how people use it. I'm
>>>> personally interested in all and any feedback on the class based
>>>> views. There's a few thing I would like to improve myself, but just
>>>> didn't have the time to sit down and do the work.
>>>
>>> I'm not sure what is meant by improve and or what you would like to improve
>>> specifically but,
>>> it was my impression that this conversation had been played out and that the
>>> API was pretty much decided.
>>
>> I agree. The base View class is pretty much set in stone for me. So in
>> context of the class based views as a whole the API is frozen. But
>> there are minor things in the generic views and mixins that django
>> provides, that didn't work too well for me while experimenting.
>>
>> For example, the FormMixin assumes that only arguments to your form is
>> "data" and "files". It's not uncommon for forms to require a request
>> object or some other additional objects (or maybe my way of using
>> forms is fundametally broken). To make a CreateView work with such a
>> form, you need to needlessly reimplement the whole get_form() method.
>> I think this should be easier.
>
> If I understand your use case, something like:
>
> class MyFormMixin(object):
> def get_form_class(self)
> def form_factory(self, *args, **kwargs):
> return MyForm(self.request, 'frobnitz', *args, **kwargs)
> return form_factory
>
> should do the job.
It certainly will. You can even do:
from functools import partial
class RequestFormMixin(FormMixin):
def get_form_class(self):
return partial(super(RequestFormMixin, self).get_form_class(),
self.request)
but I don't feel very comfortable with returning a function from
something named "get_form_class". This could be either renamed to
"get_form_factory" and documented as such, which means you most likely
lose the ability to dynamicaly sublass the form or add
get_form_params() method and use it in the default implementation:
class FormMixin(object):
def get_form_params(self):
data = {'initial': self.get_initial()}
if self.request.method in ('POST', 'PUT'):
data.update({'data': self.request.POST, 'files':
self.request.FILES})
return data
def get_form(self):
return self.get_form_class(**self.get_form_params())
And we probably can discuss which is better for an unlimited period of
time. So I'll just shut up and see if it's only a problem of my
personal taste or a valid point. Really, I'm very happy with CBVs and
I appreciate all the hard work of everyone that worked on this.
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
