Ú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".
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).
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().
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.
Com esta linha, a sequência CRUD DELETE está pronta:
| Arquivo | Edição |
|---|---|
| DepartamentoProdutoDAO | Ganhou o método daoDelete (1 linha de lógica) |
| DepartamentoProdutoList | Coluna col_del com IconButton, inner DeleteFromList, constante CONFIRM_LIST |
| DepartamentoManager | Linha 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.