Transformar um Widget em padrão

[luan fonceca]

Bom dia galera, tem como eu criar um Widget e dizer ao Django que para todos os campos do tipo X, renderize no forms com este Widget?!

Ex:

Se eu fizer um Widget para campos do tipo data, onde abra um datepicker bobão daqueles, tem como eu dizer ao django que, para todos os campos do tipo DateTime ele renderizar meu forms com este Widget, sem que eu precise dizer no meu Form, que o campo X será renderizado com meu Widget, ou seja, ser um padrão para os campos Datetime.

Obrigado desde já ;D

--

• Software Engineering student at the Universidade Federal do Rio Grande do Norte;
• Front-end Designer and Developer;
• Python/Django Developer at the multmeio.com.br.

[Yuri Piratello]

Não seria mais facil fazer um js aplicando o datepicker nesses campos?

Atenciosamente;

Yuri Zanola Piratello
=====================

about me: http://about.me/yuripiratello

blog: http://yuripiratello.net

gtalk: yuri.pi...@gmail.com
twitter: http://twitter.com/yuri_zpira

--
 
 

[luan fonceca]

Seria, porém como eu saberia qual campo vai ser manipulado pelo js?

De uma forma genérica, ou seja, sem que eu defina no forms o campo que receberá o js.

--
 
 

[Matheus Lima]

Coloca uma class CSS no campo, depois aplica com JS. Acho mais fácil assim.

--
 
 

--

Att,

Matheus dos Santos Lima     

[Luciano Ramalho]

2012/10/31 luan fonceca <luanf...@gmail.com>:

> Bom dia galera, tem como eu criar um Widget e dizer ao Django que para todos
> os campos do tipo X, renderize no forms com este Widget?!

Faça uma subclasse MeuX da classe X na qual vc redefine o atributo
widget. A partir daí, use sempre MeuX para criar campos do tal tipo.

PS. Faltou de dizer se "campos do Tipo X" quer dizer model fields ou
form fields. Uma das piores falhas de projeto do Django é usar o nome
Field para duas coisas tão diferentes e ao mesmo tempo tão intimamente
relacionadas. Os model fields deveriam se chamar properties, pois é
isso que são.

[ ]s
Luciano

>
> Ex:
> Se eu fizer um Widget para campos do tipo data, onde abra um datepicker
> bobão daqueles, tem como eu dizer ao django que, para todos os campos do
> tipo DateTime ele renderizar meu forms com este Widget, sem que eu precise
> dizer no meu Form, que o campo X será renderizado com meu Widget, ou seja,
> ser um padrão para os campos Datetime.
>
> Obrigado desde já ;D
>
> --
>
> Software Engineering student at the Universidade Federal do Rio Grande do
> Norte;
> Front-end Designer and Developer;
> Python/Django Developer at the multmeio.com.br.
>
>

> --
>
>



--
Luciano Ramalho / OFICINAS TURING
Twitter: @ramalhoorg

Autor e professor dos cursos:

* Objetos Pythonicos --> http://turing.com.br/oopy
* Python para quem sabe Python --> http://turing.com.br/ppqsp

[luan fonceca]

Matheus, eu não posso fazer isso pois teria que em cada formlfield do tipo X, eu teria que ir no form adicionar essa classe, o que é exatamente o que estou tentando evitar :D

quero deixar o forms o mais suscinto possível, algo como:

class MinhaClasselForm(forms.ModelForm):

    class Meta:

        model = MinhaClasse

e só =]

Por isso quero ao máximo deixar esse tipo de coisa genérica, apesar de entender que isso "é coisa de forms".

Luciano, imaginei que essa fosse a melhor saída, tanto que já tinha até separado uns links de modelfield customizado, herdando do tipo antigo para manipular o widget, e assinar no modelfield que eu desejo com ele.

Valeu galera!

--

[Felipe Prenholato]

Pois é, isso é um saco no Django.

Vc tem que seguir o workflow.

Ou faz um model field que tem como default um campo que use seu widget, por exemplo o django timedelta field (http://hg.schinckel.net/django-timedelta-field/src/ee0c46d9b136c01e3655ce2581816c940fa45f09/timedelta/fields.py?at=default#cl-45)

Ou faz um form field que tem como default seu widget

Ou usa seu widget forçadamente em cada campo, alterando no form.

A maneira mais limpa, IMO, é alterar os model fields, pois isto acaba se aplicando até no admin.

A maneira mais prática, é normalmente redefinir o campo no form com o novo widget, ou setar o widget no init do form.

E na idéia de acertar o widget no init do form, se for precisar de algo realmente mais genérico você pode fazer uma classe de formulário que no init, altere os widgets de acordo com o campo...por ex uso algo assim aqui:

    for fname, field in self.fields.items():

        if isinstance(field, EmailField):

            self.fields[fname].widget = html5.EmailInput()

        elif isinstance(field, PositiveIntegerField):

            self.fields[fname].widget = html5.NumberField(min_value=field.min_value,

                max_value=field.max_value)

        

Felipe 'chronos' Prenholato.
Linux User nº 405489
Home page: http://devwithpassion.com | http://chronosbox.org/blog
GitHub: http://github.com/chronossc/ | Twitter: http://twitter.com/chronossc

--
 
 

[Felipe Prenholato]

Corrigindo:

    for fname, field in self.fields.items():

        if isinstance(field, EmailField):

            self.fields[fname].widget = html5.EmailInput()

        elif isinstance(field, PositiveIntegerField):

            self.fields[fname].widget = html5.NumberInput(min_value=field.min_value,

                max_value=field.max_value)

Felipe 'chronos' Prenholato.
Linux User nº 405489
Home page: http://devwithpassion.com | http://chronosbox.org/blog
GitHub: http://github.com/chronossc/ | Twitter: http://twitter.com/chronossc

[luan fonceca]

Ah valeu, Felipe, ajudou bastante esse link :D

2012/10/31 Felipe Prenholato <phili...@gmail.com>

--
 
 

[Luciano Ramalho]

2012/10/31 Felipe Prenholato <phili...@gmail.com>:

> Ou faz um model field que tem como default um campo que use seu widget, por
> exemplo o django timedelta field
> (http://hg.schinckel.net/django-timedelta-field/src/ee0c46d9b136c01e3655ce2581816c940fa45f09/timedelta/fields.py?at=default#cl-45)

Grato pelo link, Felipe!

> Ou faz um form field que tem como default seu widget
> Ou usa seu widget forçadamente em cada campo, alterando no form.
>
> A maneira mais limpa, IMO, é alterar os model fields, pois isto acaba se
> aplicando até no admin.

Temos conceitos diferentes de "limpeza", ou então eu não entendi a sua sugestão.

Eu não chamaria de limpa uma solução que envolve alterar o código do
próprio framework. Fazer isso é pedir para ter problemas no futuro,
por exemplo quando tiver que aplicar uma atualização de segurança do
Django na aplicação em produção, como é que fica?

[ ]s
Luciano

[Felipe Prenholato]

Bom Luciano, corremos para acertar não é :).

Eu considero mais limpa, nesse caso por atingir mais locais e a alteração ser minima. Para quem usa o admin para coisas mais sérias alterar o modelfield acaba saindo mais em conta do que alterar form, admin view, etc (não sei bem como ta isso na 1.4, mas na 1.2 e 1.3 era um saco).

De experiências que já tive alterando coisas mais profundas do Framework eu digo que não é tão complicado de arrumar. Tive uma situação recente com FormFields que renderizam apenas um <spam> e um <input type='hidden'> para diversos tipos de campos quando migrei do 1.2.x para 1.4.x.

Por fim penso que quem for alterar nesse nível não só tem que saber o que faz como assumir a responsa de manter :), normalmente não tenho medo.

Felipe 'chronos' Prenholato.
Linux User nº 405489
Home page: http://devwithpassion.com | http://chronosbox.org/blog
GitHub: http://github.com/chronossc/ | Twitter: http://twitter.com/chronossc

--