Vantagens do web2py em relação ao Django

[contatog...@gmail.com]

Olá pessoal,

Tem pouco tempo que estou estudando o web2py e estou gostando. Mas tenho percebido que o Django é muito usado para aplicações web. Eu queria saber o que o web2py se sobrepõem em relação ao Django e se ele tem mais "boas práticas de desenvolvimento" que o Django. Eu mecho também com Rails e fiquei um pouco assustado com o exemplo de loja de carros, que implementa os dados da tabela e junto as validações (sendo que a implementação da tabela e as validações no Rails, são separados). Isso é tranquilo?
_____________________________________________
Gilson Filho

Desenvolvedor Web
Blog: gilson-filho.blogspot.com
Twitter: twitter.com/gilsonfilho

[Bruno Rocha]

Olá Gilson,

Uma das principais vantagens do web2py é a facilidade de uso, ou como diz o slogan da Jquery. 'Write Less, Do More'

Não posso falar muito a respeito de Django pois na verdade não o uso, nem nunca usei para grandes projetos a não ser para testes e estudos.

Uso muito o Pylons (que agora é Pyramid), e o Flask tbm para alguns projetos pequenos. e não posso compara-los com web2py, pois são muito diferente, neste caso o Flask é um micro, o Pylons Glued/middleware based, e o web2py é um FullStacked.

Quanto a boas práticas/facilitadores do web2py que posso citar:

- Segurança: http://www.pythonsecurity.org/wiki/web2py/ 

- RBAC: http://www.web2py.com/book/default/chapter/08

- Componentes e plugins: http://www.web2py.com/book/default/chapter/13

 

E a comunidade também !  -> http://bit.ly/whyweb2py

Eu mecho também com Rails e fiquei um pouco assustado com o exemplo de loja de carros, que implementa os dados da tabela e junto as validações (sendo que a implementação da tabela e as validações no Rails, são separados). Isso é tranquilo?

 O web2py trabalha em um esquema de model bem diferente dos outros frameworks, começando pelo fato de não usar classes para mapear o modelo relacional.

É preciso ficar claro que a DAL não é um ORM, portanto não podemos comparar com as implementações dos ORM's no Django, Rails ou outro framework.

A DAL é simplesmente uma camada de abstração do banco de dados que implementa uma série de helpers e métodos, dentro destes helpers estão os validadores.

Existem 3 tipos de validadores os de banco de dados que atuam diretamente na definição do DB (notunull, ONDELETE, default), os validadores da DAL que atuam na camada de abstração (required), e também os validadores de formulário que atuam apenas nos formulários gerados com FORM e SQLFORM por exemplo (IS_NOT_EMPTY).

Em algumas aplicações é comum definirmos todos juntos, na minha opinião isso facilita as vezes dependendo do tamanho da aplicação, principalmente se for uma app pequena.

Porém você pode fazer diferente, o que é útil também é o fato de você poder sobrepor os validador a qualquer momento, veja um exemplo:

<model>

db.define_table('pessoa',Field('nome',required=True,default='Seu nome aqui'))

</model>

A definição acima gera o SQL para a criação da tabela e no nível do banco de dados inclui DEFAULT='Seu nome aqui', inclui um validador da DAL 'required' que será validado sempre que a DAL interagoir com esta tabela, em uma função ou shell por exemplo.

<controller>

def pessoa():

    #aqui podemos alterar/incluir validadores de formulário antes de gerar o form.

    #criamos uma lista de validadores que podem ser criados condicionalmente

    validapessoa = []

    validapessoa.append(IS_NOT_EMPTY())

    validapessoa.append(IS_NOT_IN_DB(db,db.pessoa.id))

     

    #atribuimos estes validadores

    db.pessoa.nome.requires = validapessoa

    #criamos um form

    form = SQLFORM(db.pessoa)

    #validamos o form

    if form.accepts(request.vars, session):

        #Faça algo aqui se for aceito

    elif form.errors:

        #faça algo se der erro

    else:

        #faça algo por padrão

    #enviamos o form para a view no response

    return dict(form=form)

</controller>

Na view:

<view>

{{=form}}

</view>

Este é apenas um exemplo de como isso pode ser feito, e de como os atributos dos objetos da DAL podem ser alterados a qualquer momento.

Existem muitas outras formas para trabalhar com essas coisas, em um de meus projetos eu utilizo @decorators para implementar validações.

As vezes as pessoas se assustam ao comparar o web2py com Django ou com Rails, mas o fato é que não podemos comparar 100% pois o web2py é muito diferente.

Na minha opinião e experiência com projetos pequenos, médios e grandes o jeito web2py tem sido mais produtivo.

Abraço

Bruno.

--
Você recebeu essa mensagem por estar inscrito no grupo web2py-users-brazil.
Para enviar uma mensagem ao grupo, envie email a: web2py-us...@googlegroups.com
Para se desinscrever, envie email a: web2py-users-br...@googlegroups.com
Para mais opções, visite o site do grupo em: http://groups.google.com/group/web2py-users-brazil?hl=en

--

Bruno Rocha

http://about.me/rochacbruno/bio

[contatog...@gmail.com]

Sinceramente, eu gostei muito do web2py, principalmente porque eu posso desenvolver projetos pequenos a grandes e armazenar todo o ambiente de desenvolvimento em um pen-drive :)

Como eu aprendi Orientação a Objetos em Java e sou programador Java há mais tempo e estou estudando Ruby e Python por precaução (sendo que a situação do Java é incerto querendo ou não), fiquei meio resistente o modo de usar o MVC e o modelo objeto-relacional usado no Python.

Mas fora isso gostei muito e pretendo usar nos meus projetos posteriores, sendo que tem eu e um colega que somos parte da comunidade Python-DF usamos o web2py.

Aproveitando uma coisa. Eu tive dificuldades em entender e como funciona o CRUD no web2py, porque no exemplo ficou um pouco incerto. Não é comparar, mas no Rails quando usar o scaffold para criar a base de algum módulo, ele cria o CRUD normal e o esqueleto do layout. Quando use o CRUD no web2py, ele exibiu links de todos os módulos incluindo o user, e com isso ele exibe a lista de registros, mas não consegui entender como faço para acessar o formulario de cadastro e atualização.

Tem algum outro exemplo de CRUD, que pode ser estudado além do aplicativo de lojas de carros?

_____________________________________________
Gilson Filho

Desenvolvedor Web
Blog: gilson-filho.blogspot.com
Twitter: twitter.com/gilsonfilho

[Ovidio Marinho]

Na minha Observação o Web2py terá avanços mais rapidos do que os
outros frames python, vale a pena apostar, hj mesmo depois de dois
dias de comunidade mais dois sistemas foram para produção , vide
comunidade.

Em 14 de dezembro de 2010 12:42, contatog...@gmail.com
<contatog...@gmail.com> escreveu:

--
        Ovidio Marinho Falcao Neto
             ovid...@gmail.com
         Tecnologia da Informaçao
         Casa Civil do Governador
         83 3214 7885 - 88269088
                  Paraiba

[Bruno Rocha]

Tem algum outro exemplo de CRUD, que pode ser estudado além do aplicativo de lojas de carros?

Alguns aplicativos: http://web2py.com/appliances

Códigos uteis: http://web2pyslices.com

CApitulo Crud do book em http://web2py.com/book/default/chapter/07#CRUD

[Junior Phanter]

O post é um pouco antigo, porém foi muito útil para esclarecer uma dúvida minha e conseguir aprender mais com o exemplo dado pelo rochabruno. Só quero confirmar para ver se meu entendimento é válido, vim reativar a discussão para evitar de abrir um novo tópico já que esse me disse praticamente tudo... Então vamos lá!

Na construção de minha tabela, nos exemplos encontrados sempre vejo algo do tipo:

---------------------------------------------------------------------------------------------------

#definindo a table

meubanco.define_tabel('minha_tabela', Field('um_campo','string',length=100, required=true))

meubanco.define_tabel('minha_tabela2', Field('outro_campo',meubanco.minha_tabela))

#validando

meubanco.minhatabela2.outro_campo.requires=IS_IN_DB(meubanco, meubanco.minha_table.id, '%(um_campo)s')

-----------------------------------------------------------------------------------------------------

Então eu vi num blog (http://www.tuxtilt.com/criando-blog-com-web2py/) que o autor limitava-se apenas, na FIELD do código, em colocar o título e o tipo e abaixo a validação IS_NOT_EMPTY, ou seja, que tinha praticamente o mesmo efeito do "required=true". Isso é correto ou há alguma diferença???

Então depois me ocorreu a dúvida se seria possível colocar os validadores (IS_IN_BD, IS_NOT_EMPYT, etc..) dentro da FIELD, então fiz o seguinte:

---------------------------------------------------------------------------------------------------

#definindo a table e já validando

meubanco.define_tabel('minha_tabela', Field('um_campo','string',length=100, required=true))

meubanco.define_tabel('minha_tabela2', Field('outro_campo',meubanco.minha_tabela, requires=IS_IN_DB(meubanco, meubanco.minha_table.id, '%(um_campo)s')))

-----------------------------------------------------------------------------------------------------

Então vai mais uma pergunta, essa é uma prática legal ou posso ter problemas num futuro? Bem, até o momento estou achando legal, mas num sei se isso trará problemas no futuro... Deixando claro que eu achei legal o exemplo do bruno em colocar os validadores no controller...