Category Archive

Bem, digam adeus à abertura à comunidade:

You may not publish or provide the results of any benchmark or comparison tests run on Software to any third party without the prior written consent of Sun.

Detalhes aqui(linha 177), discussão a começar aqui.

É incrível como as maiores inovações no mundo Java raramente são implementadas pela Sun:

Sun found that by embracing standards over implementations, they spent long hours thrashing out specifications, only to provide instant credibility to other vendors’ products while their own languished. Weblogic stole the EJB early adopter window. A number of small vendors provided servlet implementations before Tomcat was born… which, although written by Sun employees, was an open-source project and yielded no financial benefit. JMS… well, JMS was always the redheaded stepchild of the J2EE family, at least until vendors like Sonic and Fiorano rescued it for the common Java programmer. (Those who’d been using IBM MQSeries all the while never really could see why you’d want to program against JMS APIs instead of IBM’s own.) In each and every case, Sun found their product to be the third or fourth entry into the race, usually years after the others had started, and as a result….

Hoje em dia, com a força com que a microsoft está a tentar aliciar os programadores, a Sun tem de mudar qualquer coisa para conseguir acompanhar os ventos de mudança. E apesar de achar que abrir a VM ao open source pode não ser o melhor (qualquer dia temos tantas versões da Java VM como temos de linux), ainda há projectos interessantes a seguir:

Groovy is like a super version of Java. It can leverage Java’s enterprise capabilities but also has cool productivity features like closures, builders and dynamic typing.

(…)

is an agile and dynamic language for the Java Virtual Machine

builds upon the strengths of Java but has additional power features inspired by languages like Python, Ruby and Smalltalk

makes modern programming features available to Java developers with almost-zero learning curve

supports Domain-Specific Languages and other compact syntax so your code becomes easy to read and maintain

makes writing shell and build scripts easy with its powerful processing primitives, OO abilities and an Ant DSL

increases developer productivity by reducing scaffolding code when developing web, GUI, database or console applications

simplifies testing by supporting unit testing and mocking out-of-the-box

seamlessly integrates with all existing Java objects and libraries

compiles straight to Java bytecode so you can use it anywhere you can use Java

Ah…! A nova Silver Bullet do Java!

Desde há uns tempos para cá fui ‘forçado’ a deixar o mundo .net para embarcar numa aventura no magnífico mundo Java… Isto, claro, implica (re-)aprender novas ferramentas, técnicas e bibliotecas.

Ultimamente tenho andado a desenvolver uma aplicação numa empresa sediada em Leamington Spa. O trabalho é em Java (JSP’s), usando, entre outros,  webflow e tiles.

Ontem, ao implementar uma solução vertical para pesquisa de um dado objecto de negócio (vou poupar os detalhes) reparei que, excepção feita ao evento que deveria ser invocado para que o webflow seguisse a pesquisa por outros caminhos, a interface era pouco mais que mudar uma dezena de linhas de código. Dado que a diferenciação já é definida pelo fluxo de execução presente nos ficheiros de configuração, como é que me posso re-utilizar código presente nas jsp’s, sem usar o padrão ‘copy-paste’? :þ

Bom, vendo a configuração do fluxo tenho qualquer coisa do estilo:

<view-state id="home" view="homeView" >
    ...    
    <transition on="search_bar" to="to_action">
        <set attribute="toAction" value="searchBar" scope="request"/>
    </transition>
    <transition on="search_foo" to="to_action">
        <set attribute="toAction" value="searchFoo" scope="request"/>
    </transition>
</view-state>
<view-state id="searchBar" view="searchBarView" >
    ...
</view-state>
<view-state id="searchFoo" view="searchFooView" >
    ...
</view-state>

Até aqui perfeito, com cada evento a seguir o seu caminho, definindo uma view diferente. Agora a primeira abordagem seria fazer as duas views, montando-as com os tiles que acharmos que pertencem a cada uma. Porém, no meu caso, a única diferença que irá existir entre as duas páginas, são os eventos que as várias acções poderão despoletar. Assim, aplicando um pouco de refactoring ao ficheiro de configuração dos tiles, chego ao seguinte resultado:

<definition name=".Standard.Search" extends=".standardPage">
    <put name="title" value="Search" type="string" />
    <put name="pagebody" value="/tiles/body/search.jsp" />
    <put name="pagebottom" value="/tiles/button/search_bottom.jsp" />
</definition><definition name=".Standard.SearchFoo" extends=".Standard.Search">
    <put name="searchType" value="foo" type="string" />
</definition><definition name=".Standard.SearchBar" extends=".Standard.Search">
    <put name="searchType" value="bar" type="string" />
</definition>


(de notar que há um ficheiro que mapeia de searchBarView para .Standard.SearchBar, e o mesmo para o foo)

Assim temos a definição da página, com uma variável a definir o tipo de procura que pretendemos. Porém, agora chegamos ao problema que me levou a escrever esta entrada.. como, dentro da nossa página ’search.jsp’, é que podemos saber que tipo de procura é que pretendemos para que o controlador da página possa decidir que tipo de eventos disparar?

Bom, eu sou mais do tipo de procurar em código do que em documentação mas decidi tentar.. Após procurar um pouco na documentação do tiles e não ter encontrado nada, achei que andava a dar demasiada importância a isto... certamente algo tão usual como isto deveria estar implementado da forma mais fácil e intuitiva que existe.. o que também levaria a que, como é habitual em muitas frameworks, o seu uso esteja fácilmente presente num pequeno canto da documentação (o que geralmente não acontece quando estamos a ler de código, pois quanto mais rudimentar é uma operação, mais fácilmente a encontramos Assim, armado com o meu senso comum, parti à descoberta e tentei:

<tiles:importAttribute name="searchType" />
<%
SearchController controller = new SearchController(request, session);
controller.setSearchType(pageContext.getAttribute("searchType"));
%>

e não é que acertei?