Search Results

Search found 27 results on 2 pages for 'clique'.

Page 2/2 | < Previous Page | 1 2 

  • Oracle WebCenter: uma nova vis&atilde;o para os Portais

    - by Denisd
    O conceito de “Portal” existe há muito tempo, mas está sempre mudando. Afinal de contas, o que é um portal? Nos primórdios da internet, o termo “portal” era utilizado para sites que guardavam muitas páginas (ou seja, muita informação). “Portal de notícias” era um termo comum, embora estes “portais” não passassem de um conjunto de páginas estáticas, que basicamente serviam conteúdo aos usuários. Com a evolução da tecnologia, os web sites passaram a ficar mais dinâmicos, permitindo uma interação maior do usuário. Sites de comunidades sociais são o melhor exemplo disso. Neste momento, o “portal” passou a ser não apenas um grupo de páginas, mas um conjunto de serviços e recursos dinâmicos, como a possibilidade de publicar fotos e vídeos, e compartilhar este conteúdo com amigos on-line. Aqui temos o que podemos chamar de “Portais Sociais”. Ao mesmo tempo, dentro das empresas, outra mudança estava acontecendo: a criação de padrões de comunicação entre aplicativos, sendo o mais famoso destes padrões a tecnologia de Web Services. Com estes padrões, as aplicações podem trocar informações e facilitar a experiência dos usuários. Desta forma, é possível desenvolver mini-aplicativos (chamados “portlets”), que publicam informações dos sistemas corporativos nas páginas dos portais internos. Estes portlets permitem interações com os sistemas, para permitir que os usuários tenham acesso rápido e fácil às informações. Podemos chamar estes portais de “Portais Transacionais”. Aqui temos 2 pontos que eu gostaria de chamar a atenção: 1 – O desenvolvimento de portlets é necessário porque eu não consigo publicar uma aplicação inteira no portal, normalmente por uma questão de padrões de desenvolvimento. Explicando de uma forma simples, a aplicação não foi feita para rodar dentro de um portal. Portanto, é necessário desenvolvimento adicional para criar mini-aplicativos que replicam (ou melhor, duplicam) a lógica do aplicativo principal, dentro do portal. 2 – Os aplicativos corporativos normalmente não incluem os recursos colaborativos de um portal (por exemplo, fóruns de discussão, lista de contatos com sensores de presença on-line, wikis, tags, etc), simplesmente porque este tipo de recurso normalmente não está disponível de forma “empacotada” para ser utilizada em um aplicativo. Desta forma, se eu quiser que a minha aplicação tenha um fórum de discussão para que os meus clientes conversem com a minha equipe técnica, eu tenho que desenvolver todo o motor do fórum de discussão dentro do meu aplicativo, o que se torna inviável, devido ao custo, tempo e ao fato de que este tipo de recurso normalmente não está no escopo da minha aplicação. O que acaba acontecendo é que os usuários fazem a parte “transacional” dentro do aplicativo, mas acabam utilizando outras interfaces para atender suas demandas de colaboração (neste caso, utilizariam um fórum fora da aplicação para discutir problemas referentes ao aplicativo). O Oracle WebCenter 11g vem para resolver estes dois pontos citados acima. O WebCenter não é simplesmente um novo portal, com alguns recursos interessantes; ele é uma nova forma de se pensar em Portais Corporativos (portais que reúnem os cenários citados acima: conteúdo, social e transacional). O WebCenter 11g é extenso demais para ser descrito em um único post, e nem é a minha intenção entrar no detalhe deste produto agora. Mas podemos definir o WebCenter 11g como sendo 3 “coisas”: - Um framework de desenvolvimento, aonde os recursos que as minhas aplicações irão utilizar (por exemplo, validação de crédito, consulta à estoque, registro de um pedido, etc), são desenvolvidos de forma a serem reutilizados por qualquer outra aplicação ou portlet que seja executado neste framework. Este tipo de componente reutilizável é chamado de “Task Flow”. - Um conjunto de serviços voltados à colaboração, como fóruns, wikis, blogs, tags, links, people connections, busca, bibliotecas de documentos, etc. Todos estes recursos colaborativos também estão disponíveis como Task Flows, desta forma, qualquer aplicação que eu desenvolva pode se beneficiar destes recursos. - Um “Portal”, do ponto de vista tradicional, aonde os usuários podem criar páginas, inserir e compartilhar conteúdo com outros usuários. Este Portal consegue utilizar os recursos desenvolvidos no Framework, garantindo o reuso. A imagem abaixo traz uma visão deste Portal. Clique para ver em tamanho maior. A grande inovação que o WebCenter traz é que a divisão entre “portal” e “aplicação” desaparece: qualquer aplicação agora pode ser desenvolvida com recursos de portal. O meu sistema de CRM, por exemplo, pode ter um fórum de discussão para os clientes. O meu sistema de suporte pode utilizar Wikis para montar FAQs de forma rápida. O sistema financeiro pode incluir uma biblioteca de documentos para que o usuário possa consultar os manuais de procedimento. Portanto, não importa se eu estou desenvolvendo uma “aplicação” ou um “portal”; o que importa é que os meus usuários agora terão em uma única interface as funcionalidades dos aplicativos e os recursos de colaboração. Este conceito, dentro da Oracle, é chamado de “Composite Applications”, e é a base para a próxima geração dos aplicativos Oracle. Nos próximos posts iremos falar (é claro) sobre como o WebCenter e o UCM se relacionam, e que tipo de recursos podem ser aproveitados nas aplicações/portais. Até breve!

    Read the article

  • Why JSF Matters (to You)

    - by reza_rahman
          "Those who have knowledge, don’t predict. Those who predict, don’t have knowledge."                                                                                                    – Lao Tzu You may have noticed Thoughtworks recently crowned the likes AngularJS, etc imminent successors to server-side web frameworks. They apparently also deemed it necessary to single out JSF for righteous scorn. I have to say as I was reading the analysis I couldn't help but remember they also promptly jumped on the Ruby, Rails, Clojure, etc bandwagon a good few years ago seemingly similarly crowing these dynamic languages imminent successors to Java. I remember thinking then as I do now whether the folks at Thoughtworks are really that much smarter than me or if they are simply more prone to the Hipster buzz of the day. I'll let you make the final call on that one. I also noticed mention of "J2EE" in the context of JSF and had to wonder how up-to-date or knowledgeable the person writing the analysis actually was given that the term was basically retired almost a decade ago. There's one thing that I am absolutely sure about though - as a long time pretty happy user of JSF, I had no choice but to speak up on what I believe JSF offers. If you feel the same way, I would encourage you to support the team behind JSF whose hard work you may have benefited from over the years. True to his outspoken character PrimeFaces lead Cagatay Civici certainly did not mince words making the case for the JSF ecosystem - his excellent write-up is well worth a read. He specifically pointed out the practical problems in going whole hog with bare metal JavaScript, CSS, HTML for many development teams. I'll admit I had to smile when I read his closing sentence as well as the rather cheerful comments to the post from actual current JSF/PrimeFaces users that are apparently supposed to be on a gloomy death march. In a similar vein, OmniFaces developer Arjan Tijms did a great job pointing out the fact that despite the extremely competitive server-side Java Web UI space, JSF seems to manage to always consistently come out in either the number one or number two spot over many years and many data sources - do give his well-written message in the JAX-RS user forum a careful read. I don't think it's really reasonable to expect this to be the case for so many years if JSF was not at least a capable if not outstanding technology. If fact if you've ever wondered, Oracle itself is one of the largest JSF users on the planet. As Oracle's Shay Shmeltzer explains in a recent JSF Central interview, many of Oracle's strategic products such as ADF, ADF Mobile and Fusion Applications itself is built on JSF. There are well over 3,000 active developers working on these codebases. I don't think anyone can think of a more compelling reason to make sure that a technology is as effective as possible for practical development under real world conditions. Standing on the shoulders of the above giants, I feel like I can be pretty brief in making my own case for JSF: JSF is a powerful abstraction that brings the original Smalltalk MVC pattern to web development. This means cutting down boilerplate code to the bare minimum such that you really can think of just writing your view markup and then simply wire up some properties and event handlers on a POJO. The best way to see what this really means is to compare JSF code for a pretty small case to other approaches. You should then multiply the additional work for the typical enterprise project to try to understand what the productivity trade-offs are. This is reason alone for me to personally never take any other approach seriously as my primary web UI solution unless it can match the sheer productivity of JSF. Thanks to JSF's focus on components from the ground-up JSF has an extremely strong ecosystem that includes projects like PrimeFaces, RichFaces, OmniFaces, ICEFaces and of course ADF Faces/Mobile. These component libraries taken together constitute perhaps the largest widget set ever developed and optimized for a single web UI technology. To begin to grasp what this really means, just briefly browse the excellent PrimeFaces showcase and think about the fact that you can readily use the widgets on that showcase by just using some simple markup and knowing near to nothing about AJAX, JavaScript or CSS. JSF has the fair and legitimate advantage of being an open vendor neutral standard. This means that no single company, individual or insular clique controls JSF - openness, transparency, accountability, plurality, collaboration and inclusiveness is virtually guaranteed by the standards process itself. You have the option to choose between compatible implementations, escape any form of lock-in or even create your own compatible implementation! As you might gather from the quote at the top of the post, I am not a fan of crystal ball gazing and certainly don't want to engage in it myself. Who knows? However far-fetched it may seem maybe AngularJS is the only future we all have after all. If that is the case, so be it. Unlike what you might have been told, Java EE is about choice at heart and it can certainly work extremely well as a back-end for AngularJS. Likewise, you are also most certainly not limited to just JSF for working with Java EE - you have a rich set of choices like Struts 2, Vaadin, Errai, VRaptor 4, Wicket or perhaps even the new action-oriented web framework being considered for Java EE 8 based on the work in Jersey MVC... Please note that any views expressed here are my own only and certainly does not reflect the position of Oracle as a company.

    Read the article

< Previous Page | 1 2