Resumo Anotacoes Certificacao OCE WebLogic Portal 10g Developer
-
Upload
gilberto-holms -
Category
Documents
-
view
2.421 -
download
2
description
Transcript of 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
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
Gilberto Holms http://gibaholms.wordpress.com/
• 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
Gilberto Holms http://gibaholms.wordpress.com/
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
� Presentation Properties • Presentation Class • Presentation ID • Presentation Style • Properties • Skeleton URI
o Page � Backable Properties
• Backing File • Definition Label • Hidden • Packed • Rollover Image • Selected Image • Theme • Title • Unselected Image
� Page Properties • Layout Type
� Presentation Properties
Gilberto Holms http://gibaholms.wordpress.com/
• 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
Gilberto Holms http://gibaholms.wordpress.com/
� 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
� Presentation Properties • Presentation Class • Presentation ID • Presentation Style • 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
Gilberto Holms http://gibaholms.wordpress.com/
• É 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:
Gilberto Holms http://gibaholms.wordpress.com/
• 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
Gilberto Holms http://gibaholms.wordpress.com/
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" />
Gilberto Holms http://gibaholms.wordpress.com/
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 >
Gilberto Holms http://gibaholms.wordpress.com/
• 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" /> <!-- OUTROS --> </ 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" /> <!-- OUTROS --> </ 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
Gilberto Holms http://gibaholms.wordpress.com/
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
Gilberto Holms http://gibaholms.wordpress.com/
<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
Gilberto Holms http://gibaholms.wordpress.com/
• 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 { ... }
Gilberto Holms http://gibaholms.wordpress.com/
� 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
Gilberto Holms http://gibaholms.wordpress.com/
� 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
Gilberto Holms http://gibaholms.wordpress.com/
� 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
Gilberto Holms http://gibaholms.wordpress.com/
• 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
Gilberto Holms http://gibaholms.wordpress.com/
� BookBackingContext o Alguns Métodos:
� setTitle / getTitle � setVisible / isVisible � getDefinitionLabel � setupStateChangeEvent
Gilberto Holms http://gibaholms.wordpress.com/
• 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
Gilberto Holms http://gibaholms.wordpress.com/
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
Gilberto Holms http://gibaholms.wordpress.com/
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
Gilberto Holms http://gibaholms.wordpress.com/
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:
Gilberto Holms http://gibaholms.wordpress.com/
� 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:
Gilberto Holms http://gibaholms.wordpress.com/
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())
Gilberto Holms http://gibaholms.wordpress.com/
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:
Gilberto Holms http://gibaholms.wordpress.com/
� 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
Gilberto Holms http://gibaholms.wordpress.com/
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
Gilberto Holms http://gibaholms.wordpress.com/
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
Gilberto Holms http://gibaholms.wordpress.com/
• 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
Gilberto Holms http://gibaholms.wordpress.com/
� 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
Gilberto Holms http://gibaholms.wordpress.com/
• 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.
Gilberto Holms http://gibaholms.wordpress.com/
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.