Web2py - Core
Opções de linha de comando
Aprendemos como iniciar o servidor web2py usando o widget GUI no capítulo anterior.
Este widget pode ser ignorado iniciando o servidor a partir de command line pronto.
python web2py.py -a 'sua senha' -i 127.0.0.1 -p 8000
Sempre que o servidor web2py é iniciado, ele cria um arquivo "parameters_8000.py"onde todas as senhas são armazenadas em um formato hash.
Para fins de segurança adicional, a seguinte linha de comando pode ser usada -
python web2py.py -a '<recycle>' -i 127.0.0.1 -p 8000Para o cenário acima, web2py reutiliza as senhas com hash armazenadas em "parameters_8000.py"
No caso, se o arquivo "parameters_8000.py"for excluído acidentalmente ou devido a algum outro motivo, a interface administrativa baseada na web está desabilitada em web2py.
Mapeamento / envio de URL
O funcionamento do web2py é baseado no model-view-controller, que mapeia a URL de uma forma específica - http://127.0.0.1:8000/a/d/f.html
Rota até a função “f()” mencionado no controlador d.pyestá sob o aplicativo denominado “a”. Se o controlador não estiver presente no aplicativo, web2py usa um controlador padrão chamado“default.py”.
Se a função, conforme fornecida no URL, não estiver presente, a função padrão chamada init()é usado. O funcionamento do URL é mostrado esquematicamente na imagem abaixo.
A extensão .htmlé opcional para o URL. A extensão determina a extensão deViewque renderiza a saída da função definida no controlador. O mesmo conteúdo é servido em vários formatos, nomeadamente html, xml, json, rss, etc.
A solicitação é passada com base nas funções, que aceitam os argumentos e fornecem a saída apropriada para o usuário. É o controlador, que interage com o modelo e visualização da aplicação para dar a saída de acordo com a necessidade do usuário.
web2py - Fluxo de Trabalho
O fluxo de trabalho do web2py é discutido abaixo -
O servidor da web gerencia todas as solicitações HTTP simultaneamente em seu próprio segmento.
O cabeçalho da solicitação HTTP é analisado e passado para o despachante.
O Dispatcher gerencia as solicitações do aplicativo e mapeia o PATH_INFOno URL da chamada de função. Cada chamada de função é representada no URL.
Todas as solicitações de arquivos incluídos na pasta estática são gerenciadas diretamente e os arquivos grandes são transmitidos ao cliente.
As solicitações de qualquer coisa, exceto um arquivo estático, são mapeadas em uma ação.
Se o cabeçalho da solicitação contiver um cookie de sessão para o aplicativo, o objeto de sessão será recuperado; ou então, um id de sessão é criado.
Se a ação retornar um valor como string, ele será retornado ao cliente.
Se a ação retornar um iterável, ela será usada para fazer um loop e transmitir os dados para o cliente.
Modelos Condicionais
No capítulo anterior, vimos a funcionalidade do Controllers. web2py usa modelos, visualizações e controladores em cada uma de suas aplicações. Portanto, também é necessário compreender a funcionalidade doModel.
Ao contrário de qualquer outro aplicativo MVC, os modelos em web2py são tratados como condicionais. Os modelos em subpastas são executados, com base no uso de seu controlador. Isso pode ser demonstrado com o seguinte exemplo -
Considere o URL - http://127.0.0.1:8000/a/d/f.html
Nesse caso, ‘a’ é o nome do aplicativo, ‘d’ é o nome do controlador e f()é a função associada ao controlador. A lista de modelos que serão executados é a seguinte -
applications/a/models/*.py
applications/a/models/d/*.py
applications/a/models/d/f/*.pyBibliotecas
web2py inclui bibliotecas, que são expostas a todos os aplicativos como objetos. Esses objetos são definidos dentro dos arquivos principais no diretório denominado “gluon”.
Muitos dos módulos, como o modelo DAL, não têm dependências e podem ser implementados fora da estrutura do web2py. Ele também mantém os testes de unidade que são considerados boas práticas.
Formulários
Os aplicativos web2py são mostrados abaixo em um formato esquemático.
o Applications desenvolvidos em web2py são compostos das seguintes partes -
Models - Representa dados e tabelas de banco de dados.
Controllers - Descreve a lógica e o fluxo de trabalho do aplicativo.
Views - Ajuda a renderizar a exibição dos dados.
Languages - descreve como traduzir strings no aplicativo para vários idiomas suportados.
Static files - Não requer processamento (por exemplo, imagens, folhas de estilo CSS, etc.).
ABOUT e README - Detalhes do projeto.
Errors - Armazena relatórios de erros gerados pelo aplicativo.
Sessions - Armazena informações relacionadas a cada usuário específico.
Databases - armazene bancos de dados SQLite e informações adicionais da tabela.
Cache - Armazene itens de aplicativo em cache.
Modules - Módulos são outros módulos Python opcionais.
Private - Os arquivos incluídos são acessados pelos controladores, mas não diretamente pelo desenvolvedor.
Uploads - Os arquivos são acessados pelos modelos, mas não diretamente pelo desenvolvedor.
API
Em web2py, models, controllers e views são executados em um ambiente onde certos objetos são importados para os desenvolvedores.
Global Objects - solicitação, resposta, sessão, cache.
Helpers- web2py inclui uma classe auxiliar, que pode ser usada para construir HTML de forma programática. Corresponde a tags HTML, denominadas como“HTML helpers”.
Por exemplo, A, B, FIELDSET, FORM, etc.
Sessão
Uma sessão pode ser definida como um armazenamento de informações do lado do servidor, que é persistente durante toda a interação do usuário em todo o aplicativo da web.
A sessão em web2py é a instância da classe de armazenamento.
Por exemplo, uma variável pode ser armazenada na sessão como
session.myvariable = "hello"Este valor pode ser recuperado como
a = session.myvariableO valor da variável pode ser recuperado desde que o código seja executado na mesma sessão pelo mesmo usuário.
Um dos métodos importantes em web2py para sessão é “forget” -
session.forget(response);Ele instrui o web2py a não salvar a sessão.
Execução de tarefas em segundo plano
Uma solicitação HTTP chega ao servidor web, que lida com cada solicitação em seu próprio encadeamento, em paralelo. A tarefa, que está ativa, ocorre em primeiro plano enquanto as outras são mantidas em segundo plano. Gerenciar as tarefas em segundo plano também é um dos principais recursos do web2py.
Tarefas demoradas são preferencialmente mantidas em segundo plano. Alguns dos mecanismos são listados a seguir, que gerenciam as tarefas em segundo plano -
CRON
Queues
Scheduler
CRON
Em web2py, CRONoferece a capacidade de executar a tarefa dentro dos intervalos de tempo especificados. Cada aplicativo inclui um arquivo CRON, que define suas funcionalidades.
Agendador
O planejador embutido ajuda na execução das tarefas em segundo plano, definindo a prioridade. Ele fornece um mecanismo para criar, agendar e modificar as tarefas.
Os eventos programados são listados em modelos com o nome do arquivo “scheduler.py”.
Construindo um aplicativo
Tivemos uma visão geral da criação de modelos e controladores no web2py. Aqui, vamos nos concentrar na criação do aplicativo chamado“Contacts”. O aplicativo precisa manter uma lista de empresas e uma lista de pessoas que trabalham nessas empresas.
Criação de Modelo
Aqui, a identificação das tabelas para o dicionário de dados é o modelo. O modelo para o aplicativo de contatos será criado sob o “models”Pastas. O arquivo é armazenado emmodels/db_contacts.py.
# in file: models/db_custom.py
db.define_table('company', Field('name', notnull = True, unique = True), format = '%(name)s')
db.define_table(
'contact',
Field('name', notnull = True),
Field('company', 'reference company'),
Field('picture', 'upload'),
Field('email', requires = IS_EMAIL()),
Field('phone_number', requires = IS_MATCH('[\d\-\(\) ]+')),
Field('address'),
format = '%(name)s'
)
db.define_table(
'log',
Field('body', 'text', notnull = True),
Field('posted_on', 'datetime'),
Field('contact', 'reference contact')
)Uma vez criado o arquivo acima, as tabelas podem ser acessadas com a ajuda de URL http://127.0.0.1:8000/contacts/appadmin
Criação do Controlador
o Controller incluirá algumas funções para listar, editar e excluir os contatos.
# in file: controllers/default.py
def index():return locals()
def companies():companies = db(db.company).select(orderby = db.company.name)
return locals()
def contacts():company = db.company(request.args(0)) or redirect(URL('companies'))
contacts = db(db.contact.company == company.id).select(orderby = db.contact.name)
return locals()
@auth.requires_login()
def company_create():form = crud.create(db.company, next = 'companies')
return locals()
@auth.requires_login()
def company_edit():company = db.company(request.args(0)) or redirect(URL('companies'))
form = crud.update(db.company, company, next='companies')
return locals()
@auth.requires_login()
def contact_create():db.contact.company.default = request.args(0)
form = crud.create(db.contact, next = 'companies')
return locals()
@auth.requires_login()
def contact_edit():contact = db.contact(request.args(0)) or redirect(URL('companies'))
form = crud.update(db.contact, contact, next = 'companies')
return locals()
def user():return dict(form = auth())A criação do view junto com sua saída será discutido no próximo capítulo.