fluigcli layout — layouts WCM

O grupo layout lista, importa e publica layouts WCM. Um layout é a página-molde do portal. Ele define os slots onde os widgets entram. O layout local é este:

wcm/layout/<código>/
└── src/main/
    ├── resources/          # application.info, layout.ftl, .properties → WEB-INF/classes no WAR
    ├── webapp/WEB-INF/     # web.xml, jboss-web.xml (context-root)
    └── webapp/resources/   # js, css, imagens

A estrutura é a mesma de um widget. A diferença está no application.info: um layout declara application.type=layout.

• list mostra os layouts do servidor. O comando usa a API nativa de page-management.
• import traz o servidor para o projeto local. O comando usa o fluigcliHelper 0.12.0 ou mais novo. A API nativa não informa o arquivo .war do layout.
• export envia o projeto local ao servidor (deploy). O comando é nativo (uploadfile), o mesmo caminho do widget export.

Esta versão não tem layout new.

fluigcli layout list [--all]

Este comando lista os layouts customizados do servidor.

fluigcli layout list --server homolog

• Por padrão, o comando mostra só os layouts customizados. Eles são os layouts que a CLI publica.
• Com --all, o comando inclui os layouts internos da plataforma (Amplo, Público, Constante...). A tabela ganha a coluna Origem, com os valores customizado e plataforma.
• No --json: {layouts: [{code, title, internal}], all}.

fluigcli layout import <código>... | --all

Este comando baixa e desempacota layouts em wcm/layout/<código>/. Ele segue o mesmo mapa do widget import. O layout.ftl volta para src/main/resources/. Os arquivos binários (imagens, fontes) são preservados byte a byte. A pasta META-INF do WAR fica de fora.

fluigcli layout import intranet --server homolog
fluigcli layout import --all --server homolog

O comando precisa do fluigcliHelper na versão 0.12.0 ou mais nova. O arquivo .war de um layout nem sempre se chama <código>.war. Por exemplo, o layout kit_layout mora em wcm-layout-kit.war. Só o helper informa esse nome.

• Sem o helper: exit code 7, com a orientação do server install-helper.
• Helper anterior ao 0.12.0: exit code 7, com a orientação do server install-helper --force.
• Código inexistente no servidor: exit code 4. Em lote, o item com erro falha sozinho e os demais são importados (exit code 6).

O servidor acrescenta a linha application.tenant.code= ao application.info na instalação. O import a preserva, como o widget import faz. O layout export do arquivo importado funciona sem ajuste.

fluigcli layout export <código>

Este comando empacota o WAR em memória (compressão STORE) a partir do layout local. Ele publica via upload nativo. O servidor instala o layout de forma assíncrona.

fluigcli layout export intranet --server homolog

Empacotamento (local → WAR):

No projeto	No WAR
src/main/webapp/WEB-INF/**	WEB-INF/**
src/main/resources/**	WEB-INF/classes/**
src/main/webapp/resources/**	resources/**

Antes de empacotar, a CLI confere o application.info:

• Pasta sem src/main/resources/application.info = exit code 2. O servidor aceitaria o WAR e falharia depois, em silêncio.
• application.type diferente de layout = exit code 2. A mensagem aponta o widget export. Isso evita publicar um widget como layout por engano.

Republicar um layout que já existe no servidor é a atualização normal. O comando não pede --force para isso.

Guarda de colisão com widget

Antes de publicar, a CLI verifica se o código do layout já existe no servidor como widget. O deploy nativo do WCM identifica o destino só pelo nome do arquivo (<código>.war). Por isso um layout com o código de um widget sobrescreve o WAR do widget. Esta guarda é o espelho da guarda do widget export.

Neste caso o comando recusa a publicação com exit code 2:

$ fluigcli layout export alertas --server producao
ERRO: o código "alertas" já existe no servidor como WIDGET ("Alertas").
Publicar o layout sobrescreveria o WAR do widget. Renomeie o layout ou
publique com --force.

Escolha uma das duas saídas:

• Renomeie o layout. É a opção correta quando o código coincidiu por acaso.
• Use --force. Escolha esta opção só quando quiser substituir o artefato de propósito.

A verificação falha em aberto. Se o servidor não responder a consulta, o comando avisa e publica. A guarda protege contra um erro conhecido. Ela não impede a publicação por indisponibilidade.

No clone

O clone tem o tipo layouts. Ele importa todos os layouts customizados com a mesma semântica do layout import --all. Com o helper ausente ou anterior ao 0.12.0, o clone --all pula os layouts com aviso. Veja clone.

No deploy --plan

O passo {"layout": "<código>"} publica o layout dentro de um plano de release. Ele aceita a opção force. O --dry-run confere a pasta, o application.type e a colisão com widget. Veja deploy.

Exit codes

Código	Quando
0	Layout enviado. A instalação segue no servidor
2	application.info ausente ou com tipo diferente de layout. Ou código que já é widget, sem --force
4	Pasta wcm/layout/<código> não existe. Ou código inexistente no servidor, no import
5	O servidor rejeitou o upload
6	import em lote com uma parte dos itens com erro
7	import sem o fluigcliHelper, ou com o helper anterior ao 0.12.0