DepartamentoManager editar arquivo

0:00 / 0:00

Última edição da sequência DELETE. Uma linha regAction no config() do Manager pra registrar a inner class DeleteFromList no mapa global do prédio. Sem essa linha, o framework não enxerga o setor e o clique na lixeirinha daria erro "setor não encontrado".

CÓDIGO COMPLETO
package br.xt.app.departamento;

import br.xt.app.departamento.produto.DepartamentoProdutoList;
import br.xt.app.painel.PnlManager;

public class DepartamentoManager extends PnlManager {

    public static final String F_ACESSO_MODULO = "XT.PAINEL_CONTROLE.ACESSO_MODULO.DEPARTAMENTO";

    @Override
    public void config() throws Exception {

        regFun("PAINEL DE CONTROLE", "Acesso ao Módulo", "DEPARTAMENTO", F_ACESSO_MODULO);

        regAction(DepartamentoHome.class);
        regAction(DepartamentoHome.Title.class);
        regAction(DepartamentoHome.MenuItem.class);
        regAction(DepartamentoHome.MenuInicial.class);

        regAction(DepartamentoProdutoList.class);
        regAction(DepartamentoProdutoList.DeleteFromList.class);

    }
}

Mudança nesta sequência: somente a última linha (verde). Tudo o mais já existia (das sequências Novo Módulo e CRUD READ).

Por que inner classes precisam de regAction separado?

Em Java, uma inner class estática (como DepartamentoProdutoList.DeleteFromList) é, pra o framework, uma classe SEPARADA. O fato do código-fonte colocar uma dentro da outra é só organização de arquivo — em runtime, cada uma é um tipo independente.

Quando um request chega pedindo pra executar DeleteFromList, o framework consulta o mapa global do prédio. Se o setor não foi registrado, a resposta é "setor não encontrado" — erro.

Por isso cada setor (classe ou inner class) precisa da sua própria linha regAction aqui no config().

Quando essa linha roda?

Na fase "prédio acordando" — quando o sistema SOBE (antes de qualquer request). O framework cria uma instância temporária do DepartamentoManager, chama config(), cada regAction grava uma entrada no mapa global. Depois a instância temporária é descartada — só o mapa sobrevive.

Quando o primeiro request chegar querendo DeleteFromList, o framework consulta o mapa, encontra a entrada, e o fluxo todo funciona.

Encerramento — sequência CRUD DELETE completa

Com esta linha, a sequência CRUD DELETE está pronta:

ArquivoEdição
DepartamentoProdutoDAOGanhou o método daoDelete (1 linha de lógica)
DepartamentoProdutoListColuna col_del com IconButton, inner DeleteFromList, constante CONFIRM_LIST
DepartamentoManagerLinha regAction da DeleteFromList

Três arquivos, edições pontuais, nenhum arquivo novo. Resultado: tela de listagem com funcionalidade completa de exclusão (lixeirinha + confirmação + tratamento de erro de constraint).

Próxima sequência: CRUD CREATE — adicionar produtos novos via formulário.