Resumo Anotacoes Certificacao OCE WebLogic Portal 10g Developer

Resumo Anotações para Certificação OCE Oracle WebLogic Portal 10g
Developer

Gilberto Augusto Holms
@gibaholms
gibaholms85@gmail.com
http://gibaholms.wordpress.com/

Portal Architecture
• Portal Project Lifecycle
o Architect -> Develop -> Assemble & Deploy -> Manage
• Need for Enterprise Portals
o Rápido desenvolvimento e deploy
o Utiliza tecnologias baseadas em padrões
o Gerenciamento e workflow de conteúdo integrados
o Personalização e customização
o Administração e segurança centralizados
o High availability, performance e scalability
o Flexibilidade e agilidade para futuras mudanças
• WebLogic Portal Services
o Portal application framework
Desktops
Books
Pages
Portlets
Look and Feel
o Federated Portals
Consumo de portal-resources remotos via SOAP sobre HTTP ou HTTPS
o Content management
Conteúdo gerenciável sem retrabalho de desenvolvimento
Temporização de conteúdo
o Communities
Foundation para gerenciar portais colaborativos
É uma extensão do portal framework
Compartilhamento de conteúdo
Pode-se participar por registro e/ou convite
o Unified user profile
Define propriedades que representam características de um usuário
Tais características podem ser mantidas na base do portal ou externamente em bancos
ou diretórios
o Personalization
Capacidade da aplicação de modificar sua aparência e/ou comportamento de acordo
com o usuário ou uma determinada audiência
o Security & administration
Usuários e perfis
Visitor entitlements – diferentes permissões de acesso de acordo com perfis
Delegated administration – diferentes permissões de administração de acordo com perfis
Publicação e aprovação de conteúdo
Portal data propagation
o Enterprise search
Licensa inclusa do produto Autonomy
Engine e APIs de busca, gerenciamento, indexamento de conteúdo, exemplos de
portlets de busca e relatório
Basic WebLogic Server
• WebLogic Server

Gilberto Holms http://gibaholms.wordpress.com/

o Domain
Administration Server
Configuration Repository (pasta config)
Domain Log
Cluster / Managed Servers ( + local logging )

WebLogic Workshop
• WTP
o Editores HTML, CSS, XSD, etc…
o Suporte a maioria dos servidores
o Operações e conexões a bases de dados – Database Explorer
• JDT
o Suporte aos variados módulos J2EE
o Editores JSP e JSF
o Servlet e EJB
• Facets
o Componentes reutilizáveis em várias aplicações J2EE (WAR ou EAR)
o Deployados apenas uma vez no servidor
• Merged Projects View
o Mostra todas os deploys reutilizáveis – shared J2EE libraries
• Apache Beehive
o NetUI Page Flow
o Java Controls (FALTA PAG 106)
o Web Services Metadata
o Framework MVC
View – NetUI JSP
Controller – Page Flow Controller Class (jpf)
Model – Java Control
o System Controls
Padrão do Apache Beehive
• EJB Control
• JDBC Control
• JMS Control
Extensões do Workshop
• Timer Control
• Service Control
• JDBC Control
o Principais annotations
@JdbcControl.ConnectionDataSource
• jndiName
@JdbcControl.ConnectionDriver
• databaseDriverClass
• databaseURL
• password


• username
• properties
@JdbcControl.SQL
o Exemplo
@ControlExtension
@JdbcControl.ConnectionDataSource(jndiName = "LOCAL_ORACLE_TESTE")
public interface ClienteJDBCControl extends JdbcControl {

public static class Cliente {
private int id;
private String nome;

@Override
public String toString() {
return id + " | " + nome;
}

public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public String getNome() {
return nome;
}
public void setNome(String nome) {
this.nome = nome;
}
}

@JdbcControl.SQL(statement="SELECT ID, NOME FROM CLIENTE WHERE ID = {id}")
public Cliente buscar(int id) throws SQLException;

}

• JMS Control
o Principais nnotations
@JMSControl.Destination
• sendType
• sendJndiName
• jndiConnectionFactory
• transacted
• …
@JMSControl.Message
• MessageType (enum)
o Exemplo
@ControlExtension
@JMSControl.Destination(sendType = JMSControl.DestinationType.Auto, sendJndiName = "TesteJMSTopic",
jndiConnectionFactory = "TesteJMSFactory", transacted = false)
public interface TesteJMSControl extends JMSControl {

@Message(JMSControl.MessageType.Text)
public void sendMessage(String body);
}

• Custom Control
o @ControlInterface
Anotar na interface do controle
o @ControlImplementation
Anotar na classe concreta do controle

Building a Portal Application
• Portal Projects
o EAR
o Web
o DataSync
• Propriedades Configuráveis


o Desktop
Backable Properties
• Backing File
Desktop Properties
• Asynchronous Mode
• Definition Label
• Disc Enabled
• DVT Enabled
• Encoding
• Look and Feel
• Scroll to Window
• Shell
• Title
• Tree Optimization
Presentation Properties
• Presentation Class
• Presentation ID
• Presentation Style
• Properties
• Skeleton URI
o Book
Backable Properties
• Backing File
• Hidden
• Packed
• Rollover Image
• Selected Image
• Theme
• Title
• Unselected Image
Book Properties
• Content Presentation
• Default Page
• Editable
• Navigation
• Orientation
• Return to Default Page
• Presentation ID
• Properties
• Skeleton URI
o Page
Backable Properties
• Backing File
• Hidden
• Packed
• Rollover Image
• Selected Image
• Theme
• Title
• Unselected Image
Page Properties
• Layout Type


• Presentation ID
• Properties
• Skeleton URI
Portlet Development
• Tipos de Portlets
o JSP/HTML Portlets
Prós
• Simples para implementação, deploy, teste
• Recomendado para portlets que apenas mostram dados
Contras
• Não prove arquitetura MVC
• Difícil de linkar com outras JSPs
• Difícil de manter e evoluir
o Java Portlet
É baseado na especificação JSR-168
Prós
• Portabilidade entre múltiplos vendedores
• Foundation para construir portlets MVC
Contras
• Não possui tooling na IDE
• Desenvolvimento em baixo nível (similar a servlets)
• O controlador MVC precisa ser codificado pelo desenvolvedor
o Java Page Flow Portlet
Prós
• Rápido desenvolvimento e tooling utilizando a IDE
• Arquitetura MVC
• Integração com Beehive Controls
• Melhora o Struts, utilizando annotations
Contras
• Muitos recursos talvez sejam desnecessários para simples portlets
o Browser (URL) Portlet
Encapsula uma página da Web
Útil para integração com sistemas web legados
o Struts Portlet
Prós
• Pode-se migrar uma aplicação antiga Struts para o portal
• Arquitetura MVC
Contras
• Mais complexo que NetUi (pois contém classes e XML)
o JavaServer Faces (JSF) Portlets
É baseado na especificção JSR-127
Prós
• Componentes de tela podem ser construídos com drag-and-drop
• Arquitetura MVC
Contras
• Mais complexo que NetUi
o Remote Portlet
Consumir portlets deployados em outro servidor (vide WSRP)
o Clipper Portlet
Semelhante ao browser portlet, porém ele incorpora a página dentro do próprio portal,
podendo clipar apenas um determinado conteúdo via xpath
Prós
• O resto do portal pode acessar o conteúdo e compartilhar a mesma sessão da
página clipada
• Permite fazer um request via POST na página remota antes de clipar


Contras
• Não isola o conteúdo clipado, ele roda no contexto do portal
• Autenticação não é criptografada
• JavaScript nas páginas remotas não é garantido que funcione corretamente
• Os cookies são carregados pelo portal, e não persistidos no cliente
• Configuração do Portlet
Backable Properties
• Backing File
Portlet General Properties
• Async Content Rendering
• Cache Expires (seconds)
• Cache Render Dependencies
• Client Classifications
• Default Minimized
• Description
• Event Handlers
• Forkable
• Fork Pre-Render
• Fork Pre-Render Timeout
• Fork Render
• Fork Render Timeout
• LAF Dependencies Path
• Orientation
• Packed
o Se false, ele extenderá na horizontal o máximo que conseguir (width
100%). Se true, ele ocupa o mínimo espaço horizontal possível.
• Render Cacheable
o Se true, o conteúdo de output sera cacheado entre requests
o O cache será recusado se o usuário interagir via links ou forms
o Pode-se usar o WebLogic Portal Cache Manager para controle
programático de caching
• Title
Portlet Properties
• Content Presentation Class
• Content Presentation Style
• Offer As Remote
Portlet Titlebar
• Show Titlebar
• Presentation ID
• Properties
• Skeleton URI
• Backing Files
o JspBacking AbstractJspBacking
o Sempre extender AbstractJspBacking, pois ela implementa os métodos de renderização
o É criada uma instância por request
o Métodos
init(HttpServletRequest, HttpServletResponse) : void
• É sempre executado, em cada request, antes do desktop ser renderizado
handlePostbackData(HttpServletRequest, HttpServletResponse) : boolean
• É executado se o recurso for visível e for “postback” (interação usuário, é
identificado pelo parametro _nfpb=true)
preRender(HttpServletRequest, HttpServletResponse) : boolean
• É executado se o recurso for visível
dispose( ) : void


• É executado sempre, em cada request, depois de o conteudo ser renderizado
isRequestTargeted(HttpServletRequest, HttpServletResponse) : boolean
• É usado para saber se o request foi em um particular portlet
o Ordem de Chamada
Página Abriu
• init
Usuário interagiu fora de um recurso com B.F.:
• init
• handlePostbackData
Usuário interagiu em um recurso com B.F.:
• init
• handlePostbackData
• preRender
• dispose
Usuário interagiu em um recurso interno a um recurso com B.F.:
• (idem ao anterior)
o Observações:
Em caso de portlet, pode ser criada em dois níveis de escopo
• netuix:portlet – atua no nível do portlet
• netuix:jspContent – atua apenas na jsp do portlet (não influencia na renderização
do portlet)
• Depende do recurso netuix_servlet.jar no classpath do projeto
• Portlet File
o Tipos de Content:
jspContent
pageflowContent
facesContent
bookContent
portionContent
strutsContent
uriContent
<portal:root>
<netuix:portlet definitionLabel="homeGeral" title="Homegeral">
<netuix:content>
<netuix:jspContent contentUri="/homeGeral/home.jsp"/>
</netuix:content>
</netuix:portlet>
<netuix:preference description="Descricao do parametro" modifiable="true" multiValued="true"
name="nome" value="giba"/>
</portal:root>
o Portlet Preferences:
Pares de key-value para parametrização de valores
Permite que diferentes instâncias do portlet possam ter esse valor modificado em
runtime
Podem ser configuradas via Workshop (dev) ou via Console Administrativo (prod)
Recuperando os valores via API:
PortletBackingContext context = PortletBackingContext.getPortletBackingContext(request);
PortletPreferences preferences = context.getPortletPreferences(request);
String nome = preferences.getValue("nome", "Giba"); //Giba é o default caso não exista o atributo
Recuperando os valores via TAGLIB:


• Inter-Portlet Communication
o Não suportado para Asynchronous Portlets
o Portlet Event Handlers (recomendado)
Escuta eventos de um ou mais portlets, e responde com uma Event Action
Tipos de Event Handlers
• Handle Generic Event
o Disparado por uma PageFlow Action de mesmo nome ou um custom
event de mesmo nome
• Handle Portal Event
o Portlet states (minimize, maximize, etc)
o Visibility
o Portlet refresh
• Handle Custom Event
o Disparado programaticamente
PortletBackingContext portlet = PortletBackingContext.getPortletBackingContext(request);
portlet.fireCustomEvent("myCustomEvent", myPayloadObject);
• Handle PageFlow Event
o Actions de PageFlows
• Handle Struts Event
o Action do Struts
• Handle Faces Event
o Action de JSF
Tipos de Event Actions
• Change Window Mode
• Change Window State
• Activate Page
• Fire Generic Event
• Fire Custom Event
• Invoke BackingFile Method
• Invoke PageFlow Action
• Invoke Struts Action
• Invoke Faces Action
o Backing Files
o Refresh Actions
PageFlow portlets podem inscrever uma action para ser executada no refresh
É executada quando há refresh do portlet e nenhuma action foi invocada pelo usuário
o listenTo portlet property
Está deprecated
o Compartilhamento de Dados
Request Parameters
• Obter um parametro da URL do browser:
HttpServletRequest outerRequest = ScopedServletUtils.getOuterRequest(this.getRequest());
String nome = outerRequest.getParameter("nome");

Request Attributes
Session Attributes
• Asynchronous Portlets
o Por padrão o portal executa os portlets de forma sincrona
o Todos os portlets precisam ser carregados para que o usuário possa interagir
o Se o portlet for assíncrono, ele será executado em uma thread separada
o Habilitando skeletons para chamada assíncrona: framework/features
Atributo “Async Content Rendering” (a escolha é transparente ao cliente)
• AJAX
o Usa o mesmo documento HTML
o Suporta features como cross-portlet drag-and-drop
o Não suporta XHTML
o Melhor integração look-and-feel
o Necessita JavaScript no browser
• IFRAME
o Usa um documento HTML separado


o Suporta XHTML
Consequências do uso de portlets asíncronos
• Não suporta inter-portlet communication
• Portlet Backing Files são executadas duas vezes
• Comandos HTTP redirect não são suportados no portlet
• Alguns commandos da PortletBackingContext API não são suportados
o Desabilitando request assíncrono em um portlet:
<render:controlContext asyncContentDisabled="true">
<netui:form action="addToCart">
<netui:select dataSource="actionForm.productSku" />
<netui:button value="Submit" type="submit" />
</netui:form>
</render:controlContext>

o Fork Render
É uma alternative ao portlet assíncrono
Os portlets são carregados em paralelo, o que melhora a performance geral
O cliente ainda é obrigado a esperar todos carregarem para interagir
Portlets que suportam:
• JSP
• PageFlow
• Java (JSR-168)
• Remote (WSRP)
Configurando no portlet
• Forkable: true
• Fork Render: true
• Fork Render Timeout: 30

o É possível renderizar um Portlet standalone assincronamente via código, utilizando o mesmo
framework de portlets assíncronos, diretamente na JSP:
<render:portalFacet label="standalone_portlet_cart" path="/portlets/shoppingCart.portlet"/>


Look And Feel
• Look and Feel
o Determina como o conteúdo do portal será renderizado
o É independente do conteúdo do portlet
o Pode ser aplicado genericamente ou de acordo a um tipo de dispositivo (palm, etc)
o Elementos do LAF:
Skeletons
Shells
Skins (incluindo genes)
Layouts
Themes
o Ciclo de Vida do LAF
Portal XML Representation PresentationContext Skeleton + Skin HTML
o Arquivo .laf
É uma associação de um Skeleton e um Skin
<netuix:markupDefinition>
<netuix:locale language="en"/>
<netuix:markup>
<netuix:lookAndFeel title="Teste" description=""
definitionLabel="TesteDefinitionLabel_1"
skin="Teste" skinPath="/framework/skins/"
skeleton="Teste" skeletonPath="/framework/skeletons/"
markupType="LookAndFeel"
markupName="TesteLookAndFeel_1"/>
</netuix:markup>
</netuix:markupDefinition>

• Skeleton
o É um conjunto de JSPs que renderizam o conteúdo do portal em HTML
o Define a estrutura do portal e aplica os elementos do Skin
o Pode ser baseado em um dispositivo
o Cada skeleton JSP é executada duas vezes: beginRender e endRender
<render:beginRender>
<body>
. . Custom Logic . .
<div class="bea-portal-body-content">
</render:beginRender>

<render:endRender>
</div>
. . Custom Logic . .
</body>
</render:endRender>

o Um skeleton para um determinado elemento pode ser “override” através da propriedade
Presentation Properties Skeleton URI
o Skeleton.xml
Indica configurações e locais para procurar por JSPs
<ns:skeleton>
<ns:render-format>
<ns:preset>HTML_4_01_TRANSITIONAL</ns:preset>
</ns:render-format>
<ns:render-strategy>
<ns:search-path>
<ns:path-element>.</ns:path-element>
<ns:path-element>../default</ns:path-element>
<ns:path-element>../shared</ns:path-element>
</ns:search-path>
</ns:render-strategy>
</ns:skeleton>


• Skin
o Oferece cores, imagens, fonts e estilos (CSS e JS) utilizados para renderizar o conteúdo do
portal
o Skin.xml
Indica configurações e locais para serem encontrados imagens, css e js. Indica também
os commandos de link de css e include de javascript a serem renderizados no portal
<ns:skin xmlns:ns="http://www.bea.com/servers/portal/framework/laf/1.0.0">
<ns:target-skeleton>
<ns:skeleton-id>default</ns:skeleton-id>
<ns:skeleton-path>/framework/skeletons</ns:skeleton-path>
</ns:target-skeleton>
<ns:images>
<ns:search-path>
<ns:path-element>images</ns:path-element>
</ns:search-path>
</ns:images>
<ns:render-dependencies>
<ns:html>
<ns:links>
<ns:search-path>
<ns:path-element>.</ns:path-element>
</ns:search-path>
<ns:link href="css/body.css" rel="stylesheet" type="text/css"/>
<ns:link href="css/book.css" rel="stylesheet" type="text/css"/>

</ns:links>
<ns:scripts>
<ns:search-path>
<ns:path-element>js</ns:path-element>
<ns:path-element>../shared/js</ns:path-element>
</ns:search-path>
<ns:script src="console.js" type="text/javascript"/>
<ns:script src="cookies.js" type="text/javascript"/>

</ns:scripts>
</ns:html>
</ns:render-dependencies>
<ns:script-dependencies>
<ns:script-fragments>
<ns:fragment event-handler="onload">initSkin()</ns:fragment>
</ns:script-fragments>
</ns:script-dependencies>
</ns:skin>

o Um CSS para um determinado elemento pode ser “override” através da propriedade
Presentation Properties Presentation Class
o Podemos adicionar atributos CSS inline aos já presentes em um elemento utilizando a
propriedade Presentation Properties Presentation Style (geralmente utilizamos para definer
height – altura e overflow – rolagem)
• Chromosomes and Genes
o É possível definir genes através de ${tokens} em arquivos do skin ou do skeleton (CSS, JS, JSP,
etc) e então definir seus valores através do arquivo chromosome
o Por definição eles devem ser criados nas pastas “Skin” ou “Skeleton”
o Denifido em arquivo.laf Skin Chromosome Name ou Skeleton Chromosome Name

o Arquivo .chromosome
<chromosome>
<genes>
<gene name="titlebar-color">
<value>blue</value>
</gene>
<gene name="titlebar-size">
<value>18px</value>
</gene>
</genes>
</chromosome>

o Atenção: para utilizar chromosomes no skin, é preciso definir no skin.xml o uso de CSS e JS
inlined no html, como indicado na caixa da direita:
<ns:link href="window.css" rel="stylesheet" <ns:style content-uri="window.css"
type="text/css" /> type="text/css" />
<ns:script src="teste.js" type="text/javascript"/> <ns:script type="text/javascript">
alert('teste ${meuGene}');
</ns:script>

o Observações:
Existe conceito de default.chromosome, que é onde o portal localiza os cromossomos default do skin ou
skeleton. Então podemos adicionar outros arquivos .chromosome para sobrescrever parcialmente um gene
particular
Para referenciar um recurso de LAF na JSP sem ficar preso ao caminho e o laf
escolhidos, utilizar o recurso de reescrita wlp_rewrite:
<img src="/framework/skins/classic/img/logo.gif"/> <img src="”wlp_rewrite?logo.gif/wlp_rewrite"/>

• Shell
o Define a estrutura macro do portal, definindo as áreas de Header, Footer e conteúdo
o Arquivo .shell
<netuix:locale language="en" />
<netuix:markup>
<netuix:shell title="Custom JSP Shell"
description="A Custom Shell with Header and Footer."
markupType="Shell" markupName="customJSPHeaderFooter">
<netuix:head />
<netuix:body>
<netuix:header>
<netuix:jspContent contentUri="/resources/jsp/customheader.jsp" />
</netuix:header>
<netuix:break />
<netuix:footer>
<netuix:jspContent contentUri="/resources/jsp/customfooter.jsp" />
</netuix:footer>
</netuix:body>
</netuix:shell>
</netuix:markup>
o Observações
Caso a tag <netuix:header/> esteja vazia, por default serão carregados os arquivos
header.jsp e footer.jsp do skeleton
O header e o footer também podem possuir um layout atrelado
O header e o footer podem ter os mesmos contents que um portlet pode ter (vide seção
de portlets) e ainda pode incluir um portlet através da tag <netuix:portletInstance>
• Layout
o Define o posicionamento dos portlets em uma página
o Tipos básicos de layout:
Flow Layout
• Posicionamento lado a lado, seguindo a ordem left-to-right ou top-to-botton
Grid Layout
• São definidas linhas e colunas
Border Layout
• São definidas 5 áreas geográficas (norte, sul, leste, oeste, centro)
Custom Layout
• Arquivo .layout: define a descrição, o arquivo html de definição e os placeholders


<netuix:locale language="en" />
<netuix:markup>
<netuix:GridLayout title="My Layout"
description="This is my custom layout"
htmlLayoutUri="/framework/markup/layout/myLayout.html.txt"
markupType="Layout" markupName="myLayout">
<netuix:placeholder title="esquerda" description="..."
markupType="Placeholder" markupName="myPlaceholder1" />
<netuix:placeholder title="direita" description="..."
markupType="Placeholder" markupName="myPlaceholder2" />
</netuix:GridLayout>
</netuix:markup>

• Arquivo .html.txt: define o html do layout, onde cada placeholder é identificado
pela ordem em que aparece no arquivo de layout
<table class="portalLayout" id="thePortalLayout" width="100%" height="100%">
<tr>
<td class="placeholderTD" valign="top" width="30%">
<placeholder number="0" />
</td>
<td class="placeholderTD" valign="top" width="70%">
<placeholder number="1" />
</td>
</tr>
</table>
o Observações:
Ao invest de um arquivo .html.txt podemos utilizar um skeleton jsp e renderizar o layout
via código java
• Theme
o É um componente “fine-grained” capaz de sobrescrever partes de um skin ou skeleton
o Pode ser associado a nível de Book, Page e Portlet
o Pode atuar das seguintes formas:
Sobrescrever JSP em um skeleton
Sobrescrever imagens em um skin
Adicionar novos arquivos CSS em um skin
o Criando um Theme
Criar um arquivo de definição .theme
<netuix:locale language="en"/>
<netuix:markup>
<netuix:theme
name="greyout"
title="Grey Out" description="A Theme used to de-emphasise a particular entity."
markupType="Theme" markupName="greyout"/>
</netuix:markup>

Criar pasta em Skin e Skeleton com o mesmo nome do theme
• Os arquivos de skeleton sobrescreverão os skeletons default
Declarar os arquivos de skin em skin.xml
• Os arquivos de skin sobrescreverão os skins default
Opcional: utilizar um arquivo structure.xml
NetUI
• Struts Framework
o Open-source application framework desenvolvido para criar aplicações web baseadas na
arquitetura MVC
o Componentes:
Front-Controller (ActionServlet)
Arquivo de configurações XML
Tags JSP
Classes
• Action – implementa a lógica do controller
• ActionForm – encapsula dados de formulário em JavaBeans
• ActionForward – implementa lógica de navegação
• ActionMapping – binda actions para URIs


• NetUI (Beehive Framework)
o Open-source application framework desenvolvido para criar aplicações web baseadas na
arquitetura MVC, baseado no Struts
o É parte do projeto Apache Beehive
o Componentes:
Java PageFlows
NetUI Tags JSP
Java Controls
Form Beans (POJO)

• Java PageFlow
o É uma classe java com Beehive Annotations
o Podem ser nested ou shared, para melhor permitir modularidade e reuso
o Composição:
Actions
• Definem a lógica de navegação entre JSPs
• Configurados via annotation
• Responde um ou mais forwards
Forward
• Define o próximo elemento (JSP) do fluxo de navegação
• É declarado na action
• Actions
o Dois tipos de action:
Simple Action
• Contém apenas um simples condicional
@Jpf.Controller(simpleActions = {
@Jpf.SimpleAction(name = "someAction", path = "default.jsp", conditionalForwards = {
@Jpf.ConditionalForward(condition = "${pageFlow.advanced}", path = "advanced.jsp"),
@Jpf.ConditionalForward(condition = "${param==’yes’}", path = "alternate.jsp")
})
})
public class ClienteController extends PageFlowController { ... }


Basic Method
• Implementadas em um método
@Jpf.Action(forwards = {
@Jpf.Forward(name = "somePage", path = "somePage.jsp")
})
public Forward someAction() {
return new Forward("somePage");
}

• Java Controls
o Os Java Controls podem ser utilizados no PageFlow
o O controle é injetado pelo container através da annotation @Control
@Control
private ClienteJDBCControl clienteJDBCControl;

• Nested PageFlows
o É um PageFlow completo que pode ser invocado por outro PageFlow
o Retorna ao PageFlow chamador via uma action de saída, que corresponde a uma action do
PageFlow chamador
o Utilização:
Modularidade
Manutenção
Reuso
• Shared PageFlows
o É um PageFlow que contém uma “biblioteca” de actions e JSPs, que não é necessariamente um
fluxo completo
o Seus conteúdos (actions, handlers, etc) podem ser acessados por qualquer PageFlow que o
referencie
o Extende a superclasse SharedFlowController
o É instanciado em qualquer PageFlow, da seguinte forma:
@Jpf.Contoller(sharedFlowsRefs = {
@Jpf.SharedFlowRef(name = "sharedFlowOne", type = example.SharedFlowClassOne.class),
@Jpf.SharedFlowRef(name = "sharedFlowTwo", type = example.SharedFlowClassTwo.class)
})
public class MyController extends PageFlowController { ... }

• NetUI Tags
o Wizards
Create Form
Data Display
Data Grid
Update Form
o Tags que Disparam Actions
Anchor
Anchor Cell
Area
Button
Form
Image Anchor
Image Anchor Cell
Tree Item
o Tags Renderizadoras de Conteúdo


Content – “texto simples”
Span – “texto dentro de uma tag <span>”
Label – “texto para input field”
o Tags para Data Binding
Repeater
• Itera sobre coleções, arrays e FormBeans (não gera html)
<netui-data:repeater dataSource="pageFlow.cartItems">
<netui-data:repeaterHeader>
<table>
</netui-data:repeaterHeader>
<netui-data:repeaterItem>
<tr>
<td>${container.item.name}</td>
<td>
<netui:span value="${container.item.price}">
<netui:formatNumber pattern="$##,###.00" />
</netui:span>
</td>
</tr>
</netui-data:repeaterItem>
<netui-data:repeaterFooter>
</table>
</netui-data:repeaterFooter>
</netui-data:repeater>

Data Grid
• Renderiza coleções, arrays e FormBeans (gera um grid html)
<netui-data:dataGrid dataSource="pageScope.pets" name="petGrid">
<netui-data:configurePager pageSize="5" />
<netui-data:rows>
<netui-data:spanCell value="${container.item.name}" />
<netui-data:spanCell value="${container.item.description}" />
<netui-data:spanCell value="${container.item.price}" />
<netui-data:anchorCell value="Details" action="details">
<netui:parameter name="id" value="${container.item.petId}" />
</netui-data:anchorCell>
</netui-data:rows>
</netui-data:dataGrid>

Tree
• Renderiza uma árvore de itens
<netui:tree dataSource="pageFlow.projectTree" selectionAction="selectTreeNode" tagId="tree">
<netui:treeItem expanded="true">
<netui:treeLabel>0</netui:treeLabel>
<netui:treeItem>0.0</netui:treeItem>
</netui:treeItem>
</netui:tree>

• Data Binding Contexts
o Objetos Expression Language 2.0 (EL) definidos:
requestScope / sessionScope / applicationScope / pageScope
actionForm
• Variáveis do FormBean associado à tag <netui:form> corrente (acessível
apenas dentro dessa tag)
pageFlow
• Variáveis de instância do PageFlow corrente (regra nomes JavaBeans)
Container
• Objeto corrente das tags de iteração (repeater, dataGrid, cellRepeater…)
• Form Bean
o Classe interna definida dentro do controller, anotada com @Jpf.FormBean:
@Jpf.FormBean
public static class BeginFormBean implements java.io.Serializable {...}

o É passada para a action declarando na mesma um parâmetro do tipo do FormBean
o É bindada na JSP através de uma tag netui:form e o elemento EL actionForm
o Validação de FormBeans


Feita de maneira declarativa, via Annotations
No NetUI ela é feita server-side
Regras de validação:

Implementando Validação:
• Definindo a regra de validação (2 modos)
o Na própria action (pode ser específico por action)
@Jpf.Action(
...
validatableProperties = {
@Jpf.ValidatableProperty(propertyName = "idade",
validateRequired = @Jpf.ValidateRequired(message="Campo obrigatório"),
validateType = @Jpf.ValidateType(type=long.class, message="Número inteiro"))
})
public Forward myAction(MyFormBean form) { ... }

o Em cada GETTER do FormBean
@Jpf.ValidatableProperty(
validateRequired = @Jpf.ValidateRequired(message="Campo obrigatório"),
validateType = @Jpf.ValidateType(type=long.class, message="Número inteiro")
)
public BigInteger getIdade() { ... }

• Definindo o fluxo de navegação de erro
@Jpf.Action(
...
validationErrorForward = @Jpf.Forward(name="fail", path="input.jsp")
)
public Forward myAction(MyFormBean form) { ... }
o Obs.: para voltar pra mesma página que submeteu o form utilizamos:
@Jpf.Forward(navigateTo = Jpf.NavigateTo.currentPage)

• Exibindo a mensagem de erro na tela
<netui:error key="idade" />

MessageBundle
• É uma alternativa às mensagens fixas
• Um arquivo properties que serve de repositório de mensagens de erro
• Basta declarar no controller (caminho relativo à pasta “src/” e sem a extensão)
@Jpf.Controller(
...
messageBundles = { @Jpf.MessageBundle(bundlePath = "bundleErros") }
//caminho resolvido: src/bundleErros.properties
)
o Obs.: na tag de validação, ao invés de message, definir o atributo
messageKey, setando a key do properties para a mensagem


• Tratamento de Exceção
o Anotação @Jpf.Catch
Captura um certo tipo de exceção e direciona para uma action/jsp ou para um método
ExceptionHandler (@Jpf.ExceptionHandler)
o Pode ser feita:
A nível de Controller
• Aplica a todas as actions do controller
A nível de Action
o Obs.: uma action pode lançar exceções declaradas (throws Exception), que também serão
tratadas pelo mecanismo de tratamento de exceção
• Internacionalização
o É definida através de MessageBundles
o É carregado dinamicamente de acordo com o idioma do browser do cliente
o Padrão de nomenclatura:
nomeQualquer.properties – bundle default
nomeQualquer_es.properties
nomeQualquer_en.properties
o Utilizando o Message Bundle (2 modos)
No controller
• Declaração:
o Idêntico ao bundle de validação – adicionar no array da annotation
o Caminho relativo à src, porém separado por pontos
• Utilização:
<netui:span value="${bundle.default.message1}"/>

Na própria JSP
• Declaração:
o Caminho relativo à src, porém separado por barras
o Exemplo:
<netui-data:declareBundle name="fooMessages" bundlePath="org/foo/messages" />
• Utilização:
<netui:span value="${bundle.fooMessages.message1}"/>

Tags and API
• Presentation Context
Manipula o estado corrente de um elemento, informando o que é necessário para renderizá-
lo e informações sobre o elemento
Bastante utilizado para renderização no skeleton
• Algumas Subclasses:
o DesktopPresentationContext
o HeaderPresentationContext
o PagePresentationContext
o LayoutPresentationContext
o …
• Alguns Métodos:
o isVisible
o getChildren
o getProperty
o …
• Obtendo via código
DesktopPresentationContext dpc = DesktopPresentationContext.getDesktopPresentationContext(request);
HeaderPresentationContext hpc = HeaderPresentationContext.getHeaderPresentationContext(request);
...
...

• Backing Contexts
o Fornece informações sobre o estado dos elementos e permite que eles sejam modificados
o Possuem a classe pai WindowBackingContext
o Algumas Subclasses:
PortletBackingContext
PageBackingContext


BookBackingContext
o Alguns Métodos:
setTitle / getTitle
setVisible / isVisible
getDefinitionLabel
setupStateChangeEvent


• Portal JSP Tags

WSRP
• Federated Portals
o Permitem que portais compartilhem recursos (portlets) que podem ser utilizados como serviços
por outros portais
o “Um Portal A está interessado em um portlet do Portal B”:
Sem Federação:
• Portal A exporta o portlet
• TI migra e deploya o portlet no Portal B
• Qualquer mudança no portlet precisa fazer tudo denovo
Com federação:
• Portal A publica o portlet como WebService no seu UDDI
• TI do Portal B cria um “Proxy Portlet” e o configura para consumir o portlet
• Qualquer mudança feita no portlet será vista automaticamente no Portal B
o Possui interoperabilidade com portais de outros vendedores e tecnologias (.NET, etc)
o O que é WSRP:
“Web Services for Remote Portlets”
É uma especificação mantida pela OASIS
Define uma interface padronizada para implementação de Federated Portals
Permite que consumidores agreguem remote markups usando SOAP
Conceitos:
• Produtor – fornece recursos via Web Services
• Consumidor – consome e agrega recursos de um ou mais produtores


o Produtor WSRP
Registro de consumidor
Registro de entitlements
Federated portlets / books / pages
WS-Security / SAML
Integração com Service Registry
o Consumidor WSRP
Proxy portlets / books / pages
Visitor Entitlements
User Identity Propagation (SAML)
User Profile Propagation
• Implementando um Produtor WSRP
o Adicionar facet “WSRP Producer”
o Extender o domínio adicionando o template wsrp-simple-producer.jar
o Nos arquivos que deseja oferecer (.portlet / .book / .page), setar propriedade:
Portlet Properties Offer As Remote
o O Producer WSDL se tornará disponível em: http://<host>:<port>/<webapp>/producer?wsdl
o Configuração do Producer

o O Visitor Entitlement é realizado através de “WSRP Properties” setadas no consumidor, que são
enviadas para o produtor no momento do registro:
Criar um “Property Set” no DataSync Project
Adicionar properties no Property Set
Registra o Property Set no arquivo wsrp-producer-config.xml
Entitlement: no Console Administrativo, criar o entitlement utilizando “Role Expression”
associado ao Property Set criado, definindo uma regra com o valor de uma propriedade
• Implementando um Consumidor WSRP
o Configuração do Consumer

o Criar um portlet do tipo “Remote Portlet”
o Digitar a url do Producer WSDL e clicar em “Register”
o Serão exibidos todos os portlets remotos que o produtor oferece para que seja escolhido um
o Serão exibidas todas as propriedades que o Producer declara no seu Property Set, para que elas
sejam preenchidas pelo consumidor


o Atenção: books e pages remotos podem ser adicionados apenas em portais em produção,
através do Console Administrativo (e não no workshop)
• Inter-Protlet Communication
o É feita da mesma forma, criando Event Handlers no portlet proxy e Actions no portlet local
• User Profile
o O consumidor informa as User Profile Properties que o produtor declarar como necessárias, na
hora do registro
• Transferencia de Dados
o Um protlet local pode trocar dados (objeto Serializable) com um portlet remoto, da seguinte
forma:

• Interceptors
o É possível que um consumidor declare interceptors nas chamadas do portlet remoto, para uma
lógica qualquer:
Error handling / validation
Implementação de cache
Mudança de markup
Mudança de HTTP Headers

Content Management
• Motivações:
o O conteúdo de um site é modificado muito frequentemente
o O site precisa ser ágil, sem a necessidade de um desenvolvedor
o Gerenciamento de mudança do conteúdo
• Um Content Management System (CMS) deve prover:
o Ferramentas para administração e desenvolvimento
o Ferramentas para criação / publicação de conteúdo
o Um repositório (storage) estruturado para armazenamento do conteúdo
o Sistema de busca Property-based
• Virtual Content Repository
o É o repositório lógico para acesso e organização de conteúdos no console administrativo
o Pode agrupar vários repositórios físicos logicamente
• Content Repository
o É o repositório físico, onde realmente fica guardado o conteúdo
o Opções de Content Repository
BEA Repository
• Database (default)
• File System
o Mais performático
o Se utilizado com versionamento, o conteúdo antigo é guardado na base
de dados
o Porém, não é transacional
Third-Party Repository
• Repositórios de outros fabricantes (ex. Documentum)
o Por padrão, o versionamento de conteúdo (“Library Services”) vem desabilitado
o Podemos utilizar Content Workflow somente em repositórios versionados
• Content Types
o É o template, a definição de um determinado tipo de conteúdo


o Suas características são definidas a partir de “Properties”, que podem ser:
Boolean
Long Integer
Number Decimal
String
Date/Time
Binary – um arquivo qualquer
Nested Content Type – um sub-elemento complexo (outro Content Type)
Link – algum outro conteúdo já implantado
o Opções gerais para as Properties:
Required
Read Only
Primary Property
• Uma por content-type, podendo ser utilizada para otimizar a busca de conteúdos
Searchable
• Pode ser incluída na busca de conteúdo
Is Explicit
• Mapeia o valor para uma coluna específica na tabela do CMS
Allow Multiple Values
• Uma lista de valores
Restrict Values
• Cria um domínio de valores permitidos
o Hierarquia de Content Types
Abstract Content Types
• Não podem virar conteúdo, serve apenas para ser “herdado” (é um) ou
“agregado” (tem um) por outros Content Types
o Adicionando conteúdo:
Console Administrativo do Portal
Através do Windows Explorer, se o WebDAV estiver configurado
Programaticamente, utilizando CMS Controls e Content API
Usando Propagation Tools
o Content Folders
Pastas utilizadas para agrupar lógicamente conteúdos
Importante pois permite setar Visitor Entitlements e Workflow em folder-lever
• WebDAV
o Web-based Distributed Authoring and Versioning
o É uma extensão do protocolo HTTP
o Permite que administradores publiquem conteúdo através do Windows Explorer
o Pode ser utilizada em um repositório por vez
o O WebDAV determina o Content Type associado ao conteúdo de duas formas:
Utiliza o Content Type default associado ao repositório
Utiliza o Content Type default associado à pasta atual
o Para isso, configurar as seguintes propriedades no repositório:
WEBDAV_ENABLED e WEBDAV_TYPE
• Library Services
o Fornece:
Versionamento
Content Workflow
Content Workspace
Controle de ciclo-de-vida
o Pode ser ativado apenas em repositórios do tipo “BEA Repository”
o Content Workspace
Uma user-view do conteúdo atual
Gerencia check-in / check-out de conteúdo e os Assigned Itens para sua role no caso do
uso de workflow
o Content Workflow
Workflow default:


Criando workflows customizados
• Através de arquivo de configurações XML
• Cada estado do workflow é definido atrave´s de classes de estado default do
produto, chamadas de Workflow Action Class
• Exemplo de uma declaração de transição do status 2 para o status 6:
<transition>
<from-status id="2">
<capabilityConstraint>can_publish</capabilityConstraint>
</from-status>
...
<to-status id="6">
<capabilityConstraint>can_publish</capabilityConstraint>
<action class="examples.workflow.TechnicalAction" />
</to-status>
</transition>

• Selectors e Placeholders
o O Portal fornece aos desenvolvedores alguns recursos para publicação de conteúdo gerenciável:
Content Selectors
Content Placeholders
Campaigns
JSP Tag Libraries
Java API e Controls
o Content Placeholders
A cada request no portal, faz uma busca de conteúdo através de property values
(através de uma query) e randomiza, escolhendo um conteúdo para exibir
Comportamento de um banner
Suporta prioridades e balanceamento de peso
Suporta personalização utilizando properties e campaigns
É criado no projeto DataSync
Exemplo de query
source = ’edudev’ && !(title like ’Java*’)
keywords contains ’bea’ || title = ’bea’
expireDate > now

Existem propriedades pré-definidas pelo portal, que podem ser utilizadas na query:
• cm_nodeName
• cm_path
• cm_objectClass
• cm_createdBy
• cm_modifiedBy
• cm_createdDate
• cm_modifiedDate
Exemplo de content query via TagLib:
<cm:search id="nodes" query="title like ’Java*’ && cm_objectClass = ’books’" />

Exibindo o placeholder na página JSP:
<ph:placeholder name="/placeholders/myPlaceholder.pla" height="100" width="150" />

Propriedades que podemos utilizar na tag ph:placeholder:


o Content Selectors
A cada request no portal, faz uma busca de conteúdo através de property values
(através de uma query) e retorna todos os content nodes localizados
Suporta personalização utilizando properties e segments
Exibindo o selector na página JSP:
• A Tag pz:contentSelector retorna o array de nodes encontrados, e então
utilizamos uma tag netui-data:repeater para iterar sobre os nodes e exibí-los
como necessário:
<pz:contentSelector rule="myContentSelector" id="sampleContent" />
<netui-data:repeater dataSource="sampleContent">
<netui-data:repeaterHeader>
<tr>
<td>Content Title</td>
</tr>
</netui-data:repeaterHeader>
<netui-data:repeaterItem>
<tr>
<td><cm:getProperty node="${container.item}" name="title" /></td>
</tr>
</netui-data:repeaterItem>
</netui-data:repeater>

• Content Management API
o Node
Representa um elemento/conteúdo no CMS
Existem duas categorias de Node:
• Hierarchy Nodes – pastas
• Content Nodes – conteúdos
Um Hierarchy Node pode conter outros Hierarchy Nodes e Content Nodes
Características do Content Node
• Possui um único ID
• É tipado pelo content type (ObjectClass)
• Contém properties
o Property
Representa um par chave/valor, que é associado a um Content Node
o ObjectClass
Representa o Content Type do qual foi criado o Content Node
o ID
É o identificador único do Content Node
o Pacote com.bea.content
o O ponto de partida é sempre uma ContentManagerFactory:
ContentContext contentContext = new ContentContext(this.getRequest());
INodeManager nodeManager = ContentManagerFactory.getNodeManager();
Node node = nodeManager.addNode(contentContext, PathHelper.SEPARATOR
+ "BEA Repository" + PathHelper.SEPARATOR + "newNode", "someType", properties);
Node newNode = nodeManager.getNode(context, "/BEA Repository/newNode");
Obs.: os entitlements necessários para acessar o content são determinados a partir da
identidade do usuário obtida do request: new ContentContext(this.getRequest())


o API Overview

o Content Management Controls
O portal oferece Beehive Content Controls para acessar a CMS API de forma
simplificada
Principais CMS Controls:
• Content Node Control
o Substitui o INodeManager
o Permite:
Adicionar novos Nodes
Gerencias Nodes
Obter Property e ID dos Nodes
Obter Nodes filhos
• Content Search Control
o Substitui o ISearchManager
o Permite:
Buscar conteúdos através de uma content query
Retorna uma SortableFilterablePagedResult, que é uma lista
que pode ser ordenada, filtrada e paginada
o Content Management JSP Tags
Estas funcionalidades também são fornecidas através de tags:
• <cm:search>
• <cm:getNode>
• <cm:getProperty>
Os conteúdos retornados em forma de lista podem ser iterados por qualquer tag iterativa
ou scriptlet
Para mostrar propriedades binárias (ex.: imagens), é preciso utilizar o ShowBinary
servlet
Exemplos:
<cm:getNode path="/BEA Repository/news" id="node" />
<% String nodeName = node.getName(); %>

<cm:getNode path="/BEA Repository/news/news1" id="node"/>
<cm:getProperty id="node" name="title"/>

<cm:search id="nodes" query="source ='edudev'"/>
<% for(int i = 0;i < nodes.length; i++) { ... } %>

<cm:getNode path="/BEA Repository/MyImageContent" id="imageNode"/>
<img src="<%=request.getContextPath()%>/ShowBinary?nodePath=${imageNode.path}/MyBinaryProperty"/>

• Content Management Administration API
o É uma API parecida com a CMS API, porém permite a administração do sistema de Content
Management do portal:


Criar Repository
Criar novo Folder ou Node
Criar novo Content Type
Adicionar um novo Workflow
Check-in e Check-out de conteúdos
o Usuários precisam estar autenticados e possuir permissão para as operações
o Pacote com.bea.federated
com.bea.federated.INodeManager
com.bea.federated.ITypeManager
com.bea.federated.IVersionManager
o Content Administration Controls
Também são fornecidos Beehive Content Administration Controls para simplificar o uso
da API
Principais CMS Administration Controls:
o Content Node Control
o Content Repository Control
o Content Type Control
o Content Workflow Control
• Third-Party CMS Systems Integration
o Arquitetura geral do sistema de CMS da BEA:

o É criado como um Repository, que é associado a um Virtual Content Repository
o Técnicas de integração que podem ser utilizadas:
Implementação do BEA Content Repository Service Provider Interface (SPI)
Implementação da JSR-170 Service Provider Interface (SPI) – “Content Repository for
Java API”
Propagação de conteúdo diretamente para as tabelas da BEA
Portlets de conteúdo customizados
o Se o fabricante optar pela JSR-170, é necessário implantar uma Bridge. O portal fornece esta
bridge


o Fabricantes que já se integram com o BEA Portal
Documentum
Interwoven
FatWire
Stellent
Portal Administration
• Atividades possíveis de administração:
o Usuários e profiles
o Modificações finais em desktops e seus componentes
o Setar permissão para componentes do portal de acordo com roles
o Delegar capacidades administrativas para outros administradores
o Publicar e aprovar conteúdo
o Application deployment
o Portal data propagation
• Um portal tem dois ciclos bem definidos: Development e Administration
o Development
Criação do arquivo .portal, que é apenas o template de um portal
o Administration
Assemblar templates para criar um portal customizado, focado em um tipo de usuário
Aplicar segurança nos recursos do portal
Outras atividades post-development
• Portal Template vs. Portal Desktop Instance
o O arquivo .portal é apenas um template (filesystem portal)
o A partir dele são criadas instâncias reais de portal (database portal)
o Na instância real podemos modificar books, pages, portlets e look-and-feel, sem que o template
.portal original seja alterado
o A instância real (Desktop) é uma “view” do portal direcionada a um determinado publico
• Portal Propagation Tool
o Permite que mudanças de LDAP e base de dados sejam propagadas de um ambiente para outro
o Desta forma, podemos por exemplo replicar no ambiente de produção todas as configurações
realizadas no ambiente de homologação
o Realizado através do Workshop ou script Ant
o Podemos propagar:

• Portal XIP Tool
o Administradores podem fazer mudanças drásticas em um template de portal para criar sua
instância em produção
o O XIP Tool permite recriar template files (.portal, .book, .page) a partir dos últimos desktops
usados em produção, para que as alterações feitas via console administrativo possam ser
replicadas posteriormente
• Portal Library Resources
o São mostrados todos os recursos disponíveis para o portal deployado (books, pages, portlets,
lafs, etc…)
o Recursos que são sincronizados automaticamente durante o desenvolvimento:
.portlet
.shell
.laf
.layout
.theme


o Recursos que precisam ser recarregados explicitamente:
.portal
Books
Pages
• Instância real – Production Desktop
o URLs do production desktop:

o Formas de criar um Production Desktop:
Utilizar um template em uma lista
Assemblar manualmente com os recursos da library
Utilizar um arquivo .portal
o No production desktop podemos setar/modificar:
Details – resumo dos atributos
Contents – gerenciar child resources (boos/pages)
Preferences – gerenciar Portlet Preferences
Visitor Entitlements
Delegated Admin
Portal Security
• WebLogic Security Realm:

• Users and Groups
o Entidades do WebLogic Server Realm
o Podem ser gerenciados pelo console do WebLogic Server ou pelo console administrativo do
Portal
• User Profiles
o Dados adicionais sobre a entidade (ex.: endereço, telefone, emal, etc…)
o São gerenciados pelo console administrativo do Portal
o São agrupados em Property Sets
• Roles
o São classificações (perfis/papéis) para usuários
o Podem ser atribuídos/classificados usuários das seguintes formas:
Grupos
Users
Regras com atributos de User Profile
Regras com atributos gravados na sessão (HttpSession)
Tempo / hora


• Visitor Entitlements
o É um mecanismo para determinar “quem” pode acessar qual recurso e “o quê” ele pode fazer
o É a permissão é concedida a nível de “Role”

o Podem ser aplicados a nível de
Desktops
Book
Page
Portlet
Conteúdo
o Podem ser concedidas permissões de:
View
Minimize
Maximize
Edit
Remove
o Já possui automaticamente dois Entitlements padrão:
Authenticated Visitor – todos que estão autenticados (independente da role)
AnonymousVisitor – todos que não estão autenticados
• Visitor Tools
o Permite que um Desktop seja customizado por cada usuário, para si próprio
o A customização é persistida e permanece ativa para os próximos acessos do usuário
o O usuário pode customizar:
Adicionar/remover Books e Pages
Posição dos Books e Pages
Adicionar/remover Portlets
Posição dos Portlets
Trocar Look-and-Feel
o Pode ser aplicado apenas a um Production Desktop (não a nível de arquivo .portal)
o É preciso adicionar a “facet” chamada Portal Visitor Tools
o É criada uma pasta “/visitorTools” com os componentes necessários e o Visitor Tools Portlet
o Visitor Tools Portlet
É o portlet que permite que o usuário gerencie sua view do desktop
Geralmente é incluído no Header (arquivo .shell)
Requer que o usuário esteja autenticado
Fica em “/visitorTools/visitorMenu.portlet”
o Através do Console Administrativo do Portal, o administrador pode dar LOCK em placeholders, o
que disabilitará a customização daquele placeholder específico
o O Entitlement para definir quem pode customizar qual recurso deve ser atribuído através da
Library, e não da instância do desktop
GroupSpace
• Conceitos de Portais Colaborativos
o Portais que permitem o compartilhamento de conteúdo entre usuários, como discussões,
notificações, anúncios, email, etc.
o Principais requisitos para colaboração:
Interface unificada
Member invitation e gerenciamento automático
Controle de acesso à informação
Ser extensível, para contemplar futuros requisitos
• Weblogic Portal Communities
o Weblogic Portal Community Framework
Base para criar e manter Portais Colaborativos


Extende o core do Weblogic Portal
Community
• É uma coleção de recursos de portal que fornecem implementação dos
requisitos de colaboração
• Suporta compartilhamento de conteúdo
• Suporta member registration / invitation
Uma Community é uma forma especializada de um Portal Desktop
Componentes de uma Community:
• Componentes comuns de portal (como Books, Pages e Portlets)
• Assemblado através do Console Administrativo do Portal
• Pode ser iniciado através de um template criado no Workshop
• Pode ser customizável através de Visitor Tools
Community Templates
• Da mesma forma que portais normais são criados através de templates .portal,
as Communities são criadas por templates .community e .ctmeta
o Gerenciamento de Usuários nas Communities
Os usuários podem se tornar membros de uma community das seguintes formas:
• Respondendo a um link de convite na página do portal
• Respondendo a um email de convite
• Registrando-se sem um convite (communities públicas)
Papéis (roles) das Communities
• Creator
o Cria e gerencia comunidades, todas configurações de portlets,
automaticamente é convidado para fazer parte da community
• Owner
o Apenas gerencia comunidades, todas configurações de portlets,
automaticamente é convidado para fazer parte da community
• Contributor
o Utiliza todas as features dos portlets, exceto deletar conteúdo
• Viewer
o Utiliza apenas features read-only dos portlets
• GroupSpace Community
o É uma aplicação completa pré-definida criada sobre o Community Framework, com vários
recursos prontos para serem customizados e reutilizados
o Arquitetura do GroupSpace

o GroupSpace Portlets
Mail
Calendar
Document Library
Discussion Forums
RSS Reader
Issues
Tasks
Announcements
Search
o Os usuários podem definir a visibilidade do conteúdo que postam nos GroupSpace Portlets:
Community
• Todos os membros da community
Private


• Apenas o usuário que postou
Personal
• Apenas o usuário que postou, e o conteúdo é visível em todas comunidades que
o usuário é membro
o Todo o conteúdo das GroupSpace Communities são modelados através de Content Types, que
são criados automaticamente pelo aplicativo
o Os GroupSpace portlets suportam diversos tipos de customização via código

Content Management – Principais Conceitos

1 – Virtual Content Repository
É o repositório lógico para acesso aos conteúdos pelo console de administração. Independe do tipo de
repositório físico e pode agrupar vários repositórios físicos logicamente.

2 – Repository
É o repositório físico, onde realmente fica guardado o conteúdo. Pode ser dos seguintes tipos:
• BEA Repository
o Tipo Database (é o default)
Já vem pré-configurado, utiliza base de dados tanto para guardar os metadados quanto o
conteúdo.
o Tipo Filesystem
Utiliza base de dados para guardar os metadados e o disco rígido para guardar o conteúdo
binário (tem melhor performance). Se utilizado com versionamento, o conteúdo antigo é
guardado na database, assim se assegurando que se houver problemas no filesystem, os
arquivos anteriores possam ser recuperados. Contra: não é transacional, se a rede cair durante
uma alteração, ela será perdida.
• Third-Party Repository
Integração com repositórios de outros fabricantes.

O versionamento (Library Services) por padrão vem desabilitado. Para habilitar:
Aba “Repositories” > Selecione o repositório > Library Services

Só podemos utilizar workflow em repositórios versionados.

3 – Content Types
É uma definição de um “Tipo de Conteúdo”, que pode ter propriedades de vários tipos “primitivos” (string,
data, binário...) ou ainda um sub-elemento de outro “Content Type” complexo.
Será o template para que a pessoa responsável por publicar conteúdo utilize, portanto deve ser bem
descrito.

4 – Content Folders
São pastas criadas dentro da aba “Content” para organizar o conteúdo. Servem para organizar
logicamente o conteúdo, mas são importantes porque também permitem setar workflow e autorização separados
por pasta (aliás, permite tanto configurações folder-level quanto file-level).

5 – Content Workflow
Permite um fluxo de aprovação para o conteúdo. Lembrete: precisa habilitar o versionamento (Library
Services) do repositório.
O portal fornece um workflow default, mas podemos criar um personalizado:
- Criar um XML de definição de workflow
- Adicionar ele no repositório
- Setar as configurações de autorização dos steps do workflow
- O workflow fica disponível para ser associado a qualquer recurso

Podem ser associados a Content Folders, Content Types e Contents.

6 – Content
É um conteúdo criado (a implementação de um Content Type), pronto para ser carregado e exibido no
portal.


7 – Detalhamento: Content Type
• Property definitions: todo o metadado que possa ser útil obter no portal (como largura da imagem ou
tamanho), ou para utilizar “Interaction Management”.
o Boolean
o Long Integer
o Number Decimal
o String
o Date/Time
o Binary – um arquivo qualquer (como por exemplo uma imagem)
o Nested Content Type – um sub-elemento complexo (outro content type)
o Link – algum outro conteúdo implementado
• Property options: opções gerais da propriedade:
o Required – é obrigatória ao criar o conteúdo
o Read Only – valor não pode ser alterado
o Primary Property – apenas uma por content type, com isso podemos criar uma busca de
conteúdo apenas por esse campo para otimizar a consulta
o Searchable – pode ser incluída na busca de conteúdo
o Is Explicit – mapeia o valor para uma coluna específica da tabela do CMS
o Allow Multiple Values – permite mais de um valor para a propriedade (array)
o Restrict values – cria um choice (domínio) de valores permitidos
• Abstract Content Types: tipos que não podem virar conteúdo diretamente, são apenas pedaços de um
content type maior, ou seja, não têm significado sozinhos.
• Content type inhiterance: é quando você deseja que content types herdem propriedades de um outro
content type
• Content workflow: associa o tipo a um workflow, ou seja, todo o conteúdo criado a partir desse tipo
possuirá este workflow associado.


Resumo Anotacoes Certificacao OCE WebLogic Portal 10g Developer

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Resumo Anotacoes Certificacao OCE WebLogic Portal 10g Developer

Semelhante a Resumo Anotacoes Certificacao OCE WebLogic Portal 10g Developer (20)

Mais de Gilberto Holms

Mais de Gilberto Holms (7)

Resumo Anotacoes Certificacao OCE WebLogic Portal 10g Developer