Neo Framework Forum

rogel.garcia, seria bem legal mesmo ter essas opções de visualização para uma mesma aplicação Neo. Quem sabe no futuro??? rsrs

desculpe mas o que vc definiria como proposta? a possibilidade ou a margem que o framework dá para que se implemente a camada de visualização de diversas formas???

mas voltando a parte Web...

Sobre a interface flash, me desculpem mais uma vez se não consigo enxergar ainda, mas pelo que eu já vi de laszlo e flex, ainda acho que o html é mias flexível, dando um maior poder para a aplicação se ele for corretamente conjugado com outras tecnologias(um bom framework JS orientado a objeto, uma boa biblioteca de efitos, uma ampla variedade de widgets, recursos multimidias - inculuindo ai o proprio Flash).

Ou eu tô tendo uma visão limitada das coisas?

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

Quando eu falei proposta eu quis dizer que existe uma idéia concreta de como isso pode ser feito. Existe um racioncínio em torno disso. Não quer dizer que alguém prôpos fazer isso nao.. (está mais para a margem que o framework proporciona para isso, mas algumas modificações teriam que ser feitas)

Mas eu compartilho a opnião sobre o flash. Também prefiro HTML.

Por falar nisso, a vantagem do Mootools na sua visão, seriam os widgets ou as funções utilitárias Javascript?

Eu utilizei o Mootools hoje em um projeto. Acabei utilizando pouco. Mas teve uma função que tive que substituir for falta de performance. Não sei como o framework se comporta no geral, mas a performance é um problema? Porque no caso, talvez fosse interessante implementar as proprias funções utilitárias, e utilizar os widgets do Mootools.

Teria como vc postar a situação com o código pra poder analisar????

Quando eu falo da MooTools, me refiro tanto as funções utilitárias, que são muitas quanto as widgets construidas em cima da biblioteca.
Eu realmente acho que não é necessário ter uma implementação própria, pois acredito que o Pessoal da MooTools tem chances de produzir um código mais eficiente, já que estão focados exclusivamente nela, salvo alguma rara exceção.

Sobre a questão da performance, acho um pouco estranho já que performance é o seu ponto forte. Talvez a abordagem que vc utilizou não seja a mais adequada para a solução do problema,

mas se vc postar a funcão a gente pode analisar junto.

vlw

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

Foi um negócio até simples:

$('meu formulario').toQueryString() <- Isso demorava uma vida pra executar

Depois que tirei esse código rodou bunito

Eu tava usando só as funções de Ajax tb...

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

Estava dando uma analizada nas bibliotecas JS. Notei que elas são bem parecidas, muda basicamente e sintaxe e alguns detalhes.

Acho que não seria o caso de integração com o framework. Pelo seguinte motivo, essas são apenas bibliotecas Javascript. É só uma questão de colocar o arquivo da biblioteca na pasta /js da aplicação e começar a usar.

Não sei se teriam muitas tags a serem feitas no framework para utilizar essas biliotecas.
Acho que adicionando suporte a uma biblioteca também cria o problema de que outra pessoa poderia querer utilizar uma biblioteca diferente da integrada.

Como está agora, a pessoa opta pela ferramenta que desejar e coloca o js na aplicação.

O que vc acha Igor?
Você acha que teria que ser feito algo a mais no framework para integrar? alguma tag? suporte?

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

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

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