Navegação

    Fórum Técnico Insoft4

    • Login
    • Pesquisar

    Ordenação de colunas que são FK's nas grids dos sistemas.

    Desenvolvimento
    1
    1
    22
    Carregando Mais Posts
    • Mais Antigo para Mais Recente
    • Mais Recente para Mais Antigo
    • Mais Votados
    Responder
    • Responder como tópico
    Entre para responder
    Este tópico foi deletado. Apenas usuários com privilégios de moderação de tópico podem vê-lo.
    • G
      gustavo_siqueira Desenvolvimento última edição por

      Atualmente os sistemas GT, Akita, Ponto Enterprise e Ex possuem a situação onde em algumas ocasiões a ordenação de uma coluna da grid retorna apenas aqueles registros no qual o valor dessa coluna é "not null".

      Cenário do problema:

      • coluna da grid é uma fk opcional;
      • getSortParam está implementado nessa coluna seguindo o contexto 'tabelaOrigem.campoExibidoNaColuna';
      • mapeamento da domainClass da grid tem associação direta com a domainClass que representa a fk. Ex: TipoPessoa tipoPessoa.

      Notou-se que definir o atributo "tabelaOrigem" como "nullable: true" na domainClass, bem como o fetchMode("tabelaOrigem", FetchMode.JOIN) no getDefaultWhere não resolvem o problema. Durante a execução da consulta a claúsula SQL no console exibe o "inner join" na tabela que possui o campo sendo ordenado, mesmo que esta seja uma fk opcional. O correto nesse caso é "left join".

      Solução para este cenário:

      • grids devem passar a utilizar views na listagem dos registros;
      • a domainClass mapeada dessa view deve conter os atributos necessários da fk como tipo primitivo. Exemplo: tabela X possui fk com TIPOS_PESSOAS. A view da tabela X exibe TIPOS_PESSOAS.TIPO_PESSOA e TIPOS_PESSOAS.DESCRICAO. A domainClass da view deve conter "Long tipoPessoa" e "String descricao" (atualmente é comum encontrar o formato "TipoPessoa tipoPessoa" e "String descricao").
      • getShowModel do controller.groovy utilizado pelo programa deve retornar o registro contendo esses atributos dentro do objeto "tabelaOrigem". Seguindo o exemplo anterior ficaria "tipoPessoa: [id: bean.codigoTipoPessoa, descricao: bean.descricao]".

      Os dois ultimos itens da lista parecem controversos porem isso se dá pelo comportamento do extjs/ext-ui frente as grids/formulários.

      Na classe XXXXGrid.js da tela, é necessário que essas colunas estejam mapeadas como:
      {
      text : 'tipoPessoa',
      name: 'colunaTipoPessoaId',
      dataIndex : 'tipoPessoa',
      renderer: function(v){
      return v ? v.id : null;
      },
      locales : {
      "default" : "default.item.xxxx"
      },
      filter : "numeric"
      },{
      name: 'colunaDescrTipoPessoa',
      text : 'descrTipoPessoa',
      dataIndex : 'descricao',
      locales : {
      "default" : "default.item.xxxx"
      },
      filter : "string"
      }

      explicação dos itens acima:

      dataIndex - quando a grid renderiza o registro, procura no "record" o atributo com o nome definido nesta propriedade. Quando o usuário filtra a coluna, esse nome será passado ao controller para aplicação do filtro: eq("tipoPessoa", params.valorDoUsuario).
      renderer - o formulário dessa grid possui o tipoPessoa como lookup, nesse caso é necessário que o record possua esse atributo como tipo objeto contendo id e descricao (são os campos definidos na lookup). Esse tipo "objeto" é oriundo do getShowModel.

      Abaixo imagens que mostram o cenário atual.

      Antes da ordenação:
      antes ordenação.PNG
      Depois da ordenação:
      depois ordenação.PNG

      1 Resposta Última resposta Responder Citar 2
      • Primeiro post
        Último post
      Powered by NodeBB | Contributors