Neo Framework Forum

Bem, acho que ainda demora um pouco para o NEO ser utilizado em larga escala. Porque ele existe como opensource há pouco tempo. Pelo meu conhecimento de frameworks, acho que não tem nenhum que se iguala em produtividade ao NEO. O NEO utiliza o Hibernate e o Spring, então, se você já possuir o conhecimento desses 2 frameworks, você consegue aprender o NEO facilmente.
Sobre a utilização pelas empresas, eu acho que elas mudam sim. Eu não sei quanto ao Struts 2, mas em comparação ao Struts 1 o NEO é muito mais produtivo. Na nossa empresa, utilizávamos antes, o struts. O ganho de produtividade foi de no mínimo 30% com a utilização do NEO. É só mostrar para a 'pessoa que decide as coisas' que com o NEO você vai atingir o mesmo resultado em menos tempo.

Mas veja a opnião de outras pessoas também... A minha opnião é meio suspeita.. hehehehhehe

Você se refere a segurança das chamadas ajax?

Bem, existe a segurança das chamadas ajax, que é um caso a parte, não envolve login e senha. Apenas é necessário identificar se o usuário (anonimo ou não) tem permissão para acessar o ajax.

Existe o conceito de segurança no NEO. Com autenticação e autorização, mas não documentei ainda, porque possa sofrer algumas modificações.
Mas se estiver precisando eu posso fazer um tutorial explicando.

Sim, para firebird a configuração simplificada do banco de dados não está ativa. Você terá que fazer a configuração completa via XML. Existe na documentação informações sobre isso.

Valew valdeci...

Só uma correção..

<t:property name="a + b"/>

Seria atualizado apenas no cliente... sem ajax.. só javascript

get('x').reloadFromServer()

Você executaria esse script se desejasse recarregar algum bean

São coisas diferentes.. Acho que ficou meio confuso o que eu escrevi mesmo...

Sobre a segurança.. veja como é feito no neo hoje. Num combo englobado por um comboReloadGroup com useAjax = true
vc pode fazer o seguinte:

<t:property name="curso"/>
<t:property name="aluno" itens="alunoService.findBy(curso)"/>

vc pode utilizar aluno.loadItens() para recarregar o aluno do servidor.
(isso é o que temos hoje)

Mas perceba que alguém, que nao estivesse nem logado, poderia chamar um ajax alunoService.findBy(curso). Certo? Na verdade, nao. Quando o componente é renderizado, ele já registra no servidor, que determinado usuário tem permissao para acessar alunoService.findBy(curso). Se você pode ver a tela.. é porque vc pode chamar esse método. Vc não consegue acessar esse método, se vc nao tiver acessado alguma tela que faça uso desse método. Isso devolve a segurança do sistema, perdida pelo ajax.

Essa nova arquitetura evitaria ao máximo comunicações com o servidor.

Obrigado...

Continuem expressando suas opniões, elas são muito importantes para o desenvolvimento do framework. Toda opnião, crítica ou sugestão é bem vinda. As reclamações também.

Qualquer atributo que vc colocar na tag será copiado para o input.

Exemplo:

<t:property name="x" onclick="alert('click')"/>

O onclick será copiado para a tag input.

Se você colocar

<t:property name="x" style="color:red"/>

será copiado para o input.

Isso funciona com qualquer tag....

No caso do form, o evento onsubmit não será disparado porque o neo nao faz submit direto do form por causa das validações.

Vou adicionar uma tarefa para implementar o onsubmit do form.

É que o Neo foi compilado com versão 6. A proxima versao eu compilo com java 5 e aí vai funcionar nos 2.

Mas acho que a 3.3.14 tá compilada com a 5

No neo tem uns recursos de ajax que ainda nao fiz documentacao porque quero dar uma turbinada neles.

Talvez esses recursos possam te ajudar...

Mas vai me falando o que vc precisa, que eu vou vendo o que eu posso fazer...

Na verdade eram mais de 5000 checkboxes.. Era um datagrid dinamico. Ele colocava todas as linhas quando carregava a página, só que sem dados.
A medida que ia fazendo scroll ia carregando.

Sobre o NEO4 ainda to tendo as ideias. Mas existiria um escopo tanto no servidor quando no cliente, mais ou menos assim..

<bean name="x"> Estamos no escopo do x

<t:property name="a"/>
<t:property name="b"/>
<t:property name="a + b"/>
</bean>

Tanto o servidor quando o cliente entenderiam que o terceiro property é `a + b`. Entao, se trocar o valor de a ou b, seria também trocado o valor do 3º input, que poderia ser output tb. poderiamos pedir que o bean x fosse recarregado do servidor, com algo do tipo.. get('x').reloadFromServer().
Os valores dos inputs seriam recarregados. Isso é só o início.. tem muita coisa bacana ainda que utilizaria essa arquitetura.
Talvez fosse necessário até um parser de javascript no servidor para atualizar o código que o usuário escrever, por um código turbinado..

Parece coisa boba isso, mas hoje vc faria assim:

<bean name="x">
<t:property name="a">
<t:property name="b">
${a + b}
</bean>

${a + b} já iria renderizar o resultado no servidor, trocando-se a e b nao afetaria a soma, que já foi calculada pelo servidor..

Num dataGrid vc teria um escopo em cada linha. Ou seja, cada linha é um bean.
Você poderia montar uma tela de edição para o mesmo bean, puxar ela vazia via ajax e depois editar o bean da seguinte forma.

get('x').copyTo('entrada') (copia o bean da linha para o form de entrada)

Isso faria com que os valores do bean x fossem copiados para o formulário de entrada. Os formulários iriam conhecer os bean e as propriedades e ajustariam seus valores automaticamente.

vc poderia até fazer o seguinte:

<t:property name="a"/>
<t:property name="b"/>
<t:property name="c" value="serviceX.calcularJuros(a, b)" autorefresh="true"/>

Se a ou b fossem alterados o c iria no servidor para calcular o juros. e retornaria o valor. O autorefresh indica que o refresh do valor de c é automático.

Apesar de já ter bolado o funcionamento disso tudo, ainda teriam que ser feitas várias implementações para tornar esse raciocínio bem genérico.

Mas ficaria muito bacana.

Na parte do servidor também poderiam ser feitas algumas mágicas:

Exemplo:
Code:

 ...
 <t:property name="nome"/>
 ....
 <script>
 ...
      controllerX.executarAjax();
 ...
 </script>

No servidor
Code:

 ...
 public void executarAjax(){
     bean.setNome("joao")     //bean é uma variável da classe
 }
 ...

Ao executar a chamada ajax, e setar o nome no servidor. O valor de nome no cliente seria atualizado. Nao seria necessário informar nada.

Talvez algumas implementacoes tenham que ficar um pouco diferentes, para simplificar, ou pra ser possível de implementar. Mas a ideia é essa.

Agora, porque isso não é possível agora?
Imagine o seguinte dataGrid:

<n:dataGrid ...>
<t:property name="nome"/>
<t:property name="valorA"/>
<n:column header="Soma">
${row.valorA + row.indice}
</n:column>
</n:dataGrid>

Como no cliente seria possível setar o valor da coluna soma?
Esse é o problema. Para fazer dataGrids dinamicos hoje, só seria possível se vc só utilizasse t:property.
Se vc quisesse escrever algo diferente, o cliente fica sem saber o que é.

Para o negócio das bibliotecas ajax. O que eu tava pensando é no prefixo mesmo. Tipo Neo.$()
Aí teria um js pequeno, se nao desejasse utilizar bibliotecas de terceiros.. nesse js pequeno as funcoes dentro de neo seriam externalizadas.

tipo
$ = Neo.$

Aí vc pode usar $('meucontrole')

Sobre o toQueryString eu acho que era porque o meu formulário possuia muitos checkboxes (mais de 1000). Como os checkboxes não precisavam ser enviados eu montei a string na mão só com os campos necessários.

Entendi o seu ponto de visa sobre a integração. O mais interessante seria implementar componentes visuais. O caso, é que esses componentes não precisam ser necessariamente do mootools, podem ser simplismente javascript puro. Isso, porque o programador não vai ter que manipular esses javascripts. Então, o que é necessário, são mais widgets.

Colocar uma bilioteca qualquer javascript dentro do NEO nao é conveniente pelo motivo que comentei: outra pessoa poderia querer utilizar outra biblioteca e entraria em conflito com a biblioteca do neo.

Colocar mais componentes de widgets como datePicker e acordion são bem interessantes. Esses componentes podem até externalizar funções para manipulação via javascript, mas nao necessariamente precisa ser de alguma biblioteca específica.

Por exemplo, qualquer combo Ajax no NEO ganha a função loadItens(). Que recarrega os itens do servidor.

Code:

 
 meucombo.loadItens();//isso faz uma chamada ajax no servidor e recarrega os itens desse combo

Os novos widgets poderiam funcionar da mesma forma. E se alguma pessoa desejasse utilizar outra biblioteca não entraria em conflito com o que o NEO utiliza.

Sobre as sugestoes:

- Campos AutoCompleter ligados diretamente a um Pojo ou outra estrutura no servidor - Essa é uma boa idéia, o NEO já oferece estrutura para isso. Vamos implementar em alguma versão futura.

- Um Grid Ajax com cahce (estilo ActiveWidgets com
http://digitarald.de/playground/grid.html) - esse eu acho importantissimo em uma aplicação. - Esse realmente é o cara, mas existem alguns problemas na implementação desse tipo de interface. A estrtura para fazer esse tipo de grid com a mesma facilidade que existe para os grids atuais só seria possível com a estrutura do Neo4. Esse tipo de interface inclusive é um dos incentivos para a estrutura Neo4 que é totalmente baseada em ajax.

-Telas de CRUD com validação AJAX. - Já começei a pensar em algo. Você nem precisaria indicar que deseja validação ajax. Todas já seriam, e inclusive se acontecesse um erro no servidor ao processar a requisição seria informado ao cliente via ajax. Ainda faltam alguns detalhes a ser pensados, e deve ser feita uma atualização da estrutura de mensagens no cliente. Aí podemos implementar essa funcionalidade. (Isso funcionaria para qualquer tela)

Formularios que fossem ligados a POJOs, que pudessem ter atualizações automaticas - com e sem Ajax ( exemplo: um professor inserindo notas dos alunos nas unidades, já existe um campo calculado média e um campo calculado notaNecessariaFInal. Os valores poderiam ser atualizados em quanto o professor digita, poderiam ser submetidos ao servidor ao final ou enquanto digitasse etc) - Também necessitaria a estrutura do Neo4

- Componentes de Upload - Já existem componentes para upload, mas não foi divulgado porque provavelmente sofrerá alterações, talvez até com suporte a ajax.

- Abstração de requisição ao servidor independente do meio de comunicação (XML, JSON, CSV?). O Neo utiliza Spring na camada abaixo, é possível utilizar qualquer um dos recursos do Spring no NEO. Mas acaba que o interessante é o usuário nem saber o que está rolando na camada inferior. Aí sim ficaria bem abstraído. Mas pode ser facilitado no NEO para alguma questão em especifico, se tiver alguma situação que um suporte seria interessante, mande aqui no fórum.

- Date pickers, Abas, Janelas de interação com o usuário, de confirmação que já estivessem ligadas a taglib do Neo(NeoWidgets).
Abas já existem no NEO, tag tabPanel (aceita panels para cada aba). DatePickers serão inseridos. Precisamos montar uma lista dos widgets mais interessantes para poder implementar.

Quando vc se refere a integração com o framework o que vc quer dizer??? em um primeiro momento me vem a mente a questão da criação de templates que fossem interligados a estrutura do Neo (e que talvez precisariam de alguns controllers e commands para dar suporte). Vc está pensando em algo mais profundo que mudaria diretamente a implementação do framework?

Não, não.. Seria criar tags e templates mesmo. Só que a bilioteca javascript exporta funções como $() que podem causar incompatibilidade com outras bibliotecas. Por isso não podemos por a biblioteca diretamente no framework. Ela pode até ser utilizada, mas não deve estar acessivel diretamente para não comprometer a compatibilidade com outras bibliotecas.

Valew Igor

Igor, estou continuando a discução em outro tópico

http://www.neoframework.org/forum/posts/list/69.page

Tópico para discussão de integração de bibliotecas javascript

Enviado por Igor.Costa

oi rogel,

1º: sobre função toQueryString: ela funciona blza comigo, dê uma olhada pra não ver se tem algo mal formado no html. Dê preferência a trabalhar com XHTML e defina o doctype com XHTML STRICT, se tiver alguma duvida passe a pagina em um validador online como o da Web Developer do Firefox.

Sobre a questão da integração:
Concordo parcialmente com você. As bibliotecas JS são semelhantes em alguns pontos mesmo, a grande maioria tem função para localização e manipulação de DOM através do id ou algo parecido com XPath. A maioria implementa efeitos e suporte a Ajax.

A questão é: Quanto tempo você demora para fazer uma interface rica (realmente rica), que seja uma "extensão" do servidor? Quanto tempo nos não gastamos (ou o quão interessante seria ter) em uma aplicação, já pronto validação de campos com Ajax, formulários automaticamente implementados com combos Ajax(q a Neo já tem), janelas de pesquisa interativa para o usuario (estilo aquela que coloquei no exemplo )e outras coisas a mais? Quão interessante seria termos componentes que já abstraissem tanto no servidor como no cliente a comunicação em XML/JSON?

Pensava em colocar no Neo algo que resolvesse o problema de RIA no cliente, já que o Neo resolve os problemas no servidor, como o CRUD por exemplo. Penso em algo que melhorasse a camada V e abstraisse muito do trabalho que nos desenvolvedores Java temos com JS, CSS e Ajax. Assim, poderiamos estar focados mais ainda no que realmente importa na aplicação: as regras de negoci, ao invés de perdermos tempo com janelinhas, json, efeitos, abas... rsrsrs

Coisas que poderiam ser implementadas:

- Campos AutoCompleter ligados diretamente a um Pojo ou outra estrutura no servidor.
- Um Grid Ajax com cahce (estilo ActiveWidgets com
http://digitarald.de/playground/grid.html) - esse eu acho importantissimo em uma aplicação;
- Telas de CRUD com validação AJAX
- Formularios que fossem ligados a POJOs, que pudessem ter atualizações automaticas - com e sem Ajax ( exemplo: um professor inserindo notas dos alunos nas unidades, já existe um campo calculado média e um campo calculado notaNecessariaFInal. Os valores poderiam ser atualizados em quanto o professor digita, poderiam ser submetidos ao servidor ao final ou enquanto digitasse etc)
- Combo conjugados (já feito)
- Componentes de Upload
- Abstração de requisição ao servidor independente do meio de comunicação (XML, JSON, CSV?)
- JSON-RPC
- Date pickers, Abas, Janelas de interação com o usuário, de confirmação que já estivessem ligadas a taglib do Neo(NeoWidgets).
- e a lista continua

Penso em coisas que podem e devem ser integradas com o servidor ou que melhorem a produtividade na parte de cliente promovendo reutilização de codigo ou de componentes(nesse caso, widgets).

Sobre a preferência da Biblioteca, você poderia utilizar o mesmo conceito do Spring faz... Existe o Spring MVC, mas vc pode escolher qual framework mvc quer implementar na aplicação:

Com o Neo seria a mesma coisa: Ele teria os componentes, que seriam implementados com Mootools por recomendação (talvez uma taglib em especial), mas ele(desenvolvedor) teria direito de implementar como quiser e se quiser, sem perder a flexibilidade.

Quando vc se refere a integração com o framework o que vc quer dizer??? em um primeiro momento me vem a mente a questão da criação de templates que fossem interligados a estrutura do Neo (e que talvez precisariam de alguns controllers e commands para dar suporte). Vc está pensando em algo mais profundo que mudaria diretamente a implementação do framework?

flw

Em breve existirá uma atualização no framework que permitirá esrever StatusDAO ou StatusDao

Você vai fazer um relatório utilizando o JasperReports?

César, eu vou fazer um tutorial (screen cast) para fazer detalhes.

Mas vou adiantando o mapeamento:

Supondo que vc tenha:

classe Municipio:

Code:

 ...
 @ManyToOne(....)
 public Uf getUf(){
     return uf;
 }

No Uf vc faz assim:

Code:

 ....
 @OneToMany(mappedBy="uf")
 public List<Municipios> getMunicipios(){
     return municipios;
 }
 ...

Você pode ver a documentação do Hibernate Annotations para mais informações.

Assim que estiver disponível o screen cast eu faço o post aqui