resumo anotacoes certificacao oce weblogic portal 10g developer

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

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

Gilberto Augusto Holms @gibaholms [email protected] 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


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 • Definition Label • Hidden • Packed • Rollover Image • Selected Image • Theme • Title • Unselected Image

� Book Properties • Content Presentation • Default Page • Editable • Navigation • Orientation • Return to Default Page


o Page � Backable Properties

• Backing File • Definition Label • Hidden • Packed • Rollover Image • Selected Image • Theme • Title • Unselected Image

� Page Properties • Layout Type

� Presentation Properties


• Presentation Class • Presentation ID • Presentation Style • 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 • Não possui tooling na IDE • 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 • Não possui tooling na IDE • 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 • Definition Label • 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


• 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 = PortletBackingConte xt. getPortletBackingContext(request); PortletPreferences preferences = context.getPortlet Preferences(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 = PortletBackingConte xt. 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 = ScopedServletUtil s.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" type ="text/css" />

<ns:style content-uri ="window.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:markupDefinition > <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 > </ netuix:markupDefinition >

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:markupDefinition > <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 > </ netuix:markupDefinition >

• 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:markupDefinition> <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 > </ netuix:markupDefinition >

� 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 >0.1 </ netui:treeItem > <netui:treeItem >0.2 </ 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 = DesktopPresentatio nContext. getDesktopPresentationContext(request); HeaderPresentationContext hpc = HeaderPresentationC ontext. 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 ’Jav a*’) 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, Pat hHelper. 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

Documents