Neo Framework Forum

Xiita Membro desde: 17/04/2007 16:35:03 Mensagens: 275 Offline

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

Xiita Membro desde: 17/04/2007 16:35:03 Mensagens: 275 Offline

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

Olá rogel,

bem concordo com tudo o que você disse, só discordo de você em um ponto:

A implementação de widgets e de funcionalidades sem o apoio de uma biblioteca ocasionaria uma maior custo de implementação:
- Seria mais dificil construir esses widgets sem uma bibioteca de suporte para eles.
- Peso: Não falo só nos componentes ficarem pesados em termos de processamento, mas em tamanho dos arquivos js mesmo: vc precisaria implementar coisas que já estão implementadas e bem definidas na biblioteca: exemplo disso é aquele date picker básico que eu coloquei da mootools: ele tem 9k contra os mais 45k do que foi proposto.

ou seja: implementar widgets sem uma biblioteca(mesmo que não fosse mootools) poderia deixar a aplicação mais pesada, além do que não permitiria que você criasse componentes tão facilmente como com um suporte da mesma, e lembrando de uma coisa: as comunidades dessas bibliotecas sempre tem novidades em termos de widgets, assim teríamos mais pessoas indiretamente fornecendo widgets para o Neo e essas bibliotecas são focadas em JS(!): provavelmente produzem um código com menos erros, maior compatibilidade e mais eficientes que os produzidos por nós

Sobre a questão das bibliotecas terem problemas de incompatibilidade com a Mootools ou outra biblioteca, acho que pode ser estudadas forma de se fazer isso sem altera a compatibilidade: colocar um prefixo nas funções utilitárias como $(), e os demais módulos(no caso da mootools) são implementados em classes especificas separadas (Fx, Ajax, Window, Element, etc) que também podem ser prefixados(como em xml, tipo as taglibs jsp).

Outra coisa: O que seria (ou como seria) a estrutura do Neo4? Vc disse que ele seria totalmente ajax e disse que algumas dos componentes que eu propus precisariam do Neo4, mas o que alteraria no framework? a implementação de uma biblioteca js própria?

Pessoalmente, eu irei utilizar o Neo nas aplicações que estou desenvolvendo, e que necessitam de RIA, então precisam também de widgets e de outras coisas como essas e acredito que os outros desenvolvedores tb irão precisar. Uma biblioteca poderia oferecer uma interface mais intuitiva, de maior suporte de mais fácil aprendizado para que os outros desenvolvedores também contribuam com o Neo.

PS: 1000 checkboxes? cara, que formulário!!! rsrs talvez existisse uma forma de vc marcar esses checkbox (como uma classe css por exemplo) e depois recuperar como uma função (no caso na mootools vc usaria $$(''input.classe")...

vlw

Xiita Membro desde: 17/04/2007 16:35:03 Mensagens: 275 Offline

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')

Xiita Membro desde: 17/04/2007 16:35:03 Mensagens: 275 Offline

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

Xiita Membro desde: 17/04/2007 16:35:03 Mensagens: 275 Offline

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

Talvez esses recursos possam te ajudar...

vou comentar o que vc postou com mais detalhes (foi muita informação de uma vez só rs), mas só uma coisa: se vc vai utilizar o prefixo, pq já não utilizar uma biblioteca??? (desculpa pela insistência...), ai você poderia utilizar dela somente os módulos necessários (novamente no caso da MooTools, vc não precisa baixar ela toda, somente os scripts que vc necessita no caso das widgets e ainda levaria de quebra os de manipulação de DOM e outros...)

E aí pessoal... gostaria de participar da discussão tmb...
rogel.garcia, achei muito interessante a maneira q vc projetou essa questão de "propriedades calculadas"... gostaria de sugerir apenas uma coisa: pelo que entendi nesse exemplo:

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

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

o valor de 'a + b' só seria atualizado depois de você fazer um get('x').reloadFromServer().
Supondo que estejamos lidando com isso num grid de tamanho razoável, seria várias requisições ao servidor que teriam que ser processadas num curto espaço de tempo para que as propriedades fosses atualizadas corretamente. Não seria interessante, criar uma estrutura JS que fizesse essa atualização no cliente e só depois atualizasse o servidor??? Isso evitaria o grande número de requisições, o que tornaria a atualização muito mais rápida já que seria executada diretamente no browser. Tá... mas como fazer isso automático??? Num sei... talvez quando a página fosse processada, o servidor construiria os códigos JS necessários para a tualização das propriedades e mandaria esse JS para o browser, permitindo que ele próprio executasse a atualização.
Bom, você poderia perguntar: e a segurança??? Bem, eu concordo q JS num é a coisa mais segura do mundo... mas poderia ser realizado uma verificação de consistência das propriedades quando essas chegassem ao servidor...
Estou colocando apenas uma sugestão de melhoria... mas continuo afirmando que a sua arquitetura realmente é muito interessante...

vlw...

Xiita Membro desde: 17/04/2007 16:35:03 Mensagens: 275 Offline

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.

vlw rogel eu realmente tinha entendido errado...

sobre a questão de segurança eu fiquei com um dúvida: o NEO possui uma estrutura própria de segurança (além do que você citou, coisas com o Acegi tem hoje) ou eu preciso usar um outro framework com essa finalidade (o próprio Acegi, por exemplo)???

flw

Valdeci.. a autorização o neo já possui uma, quanto a autenticação você pode criar um filtro para gerenciar ele, ou usar o jaas.. caso queira pode usar também o acegi, também funciona.. mais nunca integrei com ele.

té!