Ajusta front e implementa SaplGenericRelation, uma customização que
adiciona o atributo fields_search que possibilita passar para qualquer
implementação de busca quais são os campos de busca padrão do do
GenericRelation
- Autor e TipoAutor migrados para app base.
- Foram refatorados para GR - Generic Relations
- Em TipoAutor: passou se a apontar também para um ContentType que
é usado para contextualização de dados da GR em Autor.
- A captura da combo de ContentTypes é feita através do apontamento
reverso nos models que se queira disponibilizar conceitualmente como
Autor
- Em Autor: neste commit, o form de create está em desenvolvimento, com
o buscador de possiveis autores baseados na seleção do usuário de
TipoAutor que, se não possui ContentType, abre o campo nome para
insersão, se possui ContentType, abre caixa de busca com atualização
jquery de radiobox's para o usuário selecionar um possível autor.
- api rest: para a busca funcionar e como objetivo de futuras
implementações em DRF, a app api foi criada, anotada nas configurações
gerais de sapl.urls com o prefixo /api.
- na api foi criada a uma ListAPIView para pesquisa de possiveis autores
baseados no tipo autor enviado, url /api/autor/possiveis/?P<pk>[0-9]*)$
que sem pk devolve a lista de TipoAutor e, com pk, devolve a lista dos
registros ligados ao ContentType, filtrados pelo parametro q
a template tag subnav em sapl.base.templatetags.menu.py foi customizada
para aceitar que urls do request com ou sem pk possa ter subnav, bem como
as urls de dentro do yaml também não necessitarem de pk.
Para os casos em que a url do request não tenha pk, não basta a
existência do arquivo padrão subnav.yaml... mesmo que o subnav a ser
renderizado seja o padrão, a tamplate tag subnav só renderiza,
independente das condições, se existir a variável `subnav_template_name`
no contexto apontando qual o arquivo yaml deve ser renderizado...
Existem exemplos implemetandos dentro do projeto, faça uma busca por
subnav_template_name.