Olá, sei que esse não é um site, alias, um grupo sobre php mas antes de mais nada este é
um grupo de tecnologia, no final da história vocês irão entender onde Java entra.
Trabalho em uma empresa que possui um grande sistema desenvolvido em PHP. Este sistema é voltado à área comercial sendo basicamente um ERP. Bem, vocês imaginam a quantidade de módulos que esse sistema deve possuir e todo ele é feito em PHP. Bem vamos dar nome aos bois.
O sistema tem o front, o view, feito em html com javascript, a camada de modelo e controle é feita em php mesmo com diversas classes e tudo isso trabalha com nosso querido e poderoso Oracle 9i. Boas partes das regras de negócio são feitas em oracle para tirar o “peso das costas” da aplicação. Bem, o sistema é realmente bom, vocês não tem idéia da usabilidade alcançada no sistema, faria Kety Price babar. Contudo, nosso lindo terminal burro colorido (browser) nos limita em muito no quisito usabilidade apesar de termos alcançado coisas incríveis(nossos programadores são realmente MUITO bons).
Bem, numa conversa na empresa, foi cogitada a mudança da tecnologia usada. Bem a tecnologia sugerida foi Oracle Forms. Bem, penso nisso como um tiro na cabeça da idéia de “sermos livres” !
Argumentos usados
1o. User-friendly à programação.
2o. look and feel mais profissional
3o. Maior facilidade de controle de interação, ou seja, maior usabilidade
4o. RAD
5o. Possibilidade de desenvolvimento para web também atravéz dele.
São bons argumentos, contudo acho que existem outras possibilidades a serem analisadas antes de pedirmos a oracle em casamento.
1o. Poderíamos trocar a casadinha, Html/JavaScript por GTK, OU NÃO? Alguém aqui usa isso e poderia dar mais detalhes!
2o. Java Swing
Bem, ao usar oracle forms p/ gerar aplicação web não estaríamos gerando aplicações Java através do oracle? Se verdade então pq não usar direto jsp/servlet… ou structs/velocity…?
Bem pessoal, vc’s entenderam onde esta o problema né? Na usabilidade do sistema! Eu particularmente preferiria uma aplicação Desktop em Swing, ainda + agora com as enovações do TIGER que promete tornar aplicações Swing muito mais rápidas.
é possível fazer layouts bastante profissionais com o velho html + javascript
swing não é lento, só precisa dar uma esquentadinha hehe
swt é uma ótima alternativa ao swing
procure no fórum sobre Java Web Start e conhecerá as maravilhas da distribuição de apps em java
e sobre oracle forms, procure por um tópico meu que fala sobre “classes X stored procedures”, a discussão foi muito boa e, apesar de não ser exatamente o que você está perguntando, dá uma boa noção de arquitetura e portabilidade
Teu sistema é interno? Imagino que sim pelas palavras que tu usou. Então não teria muito problema em “casar” com a Oracle. Mas tem o ponto negativo, vc fica dependente de uma empresa, não só do banco, mas sim do front-end o que se torna muito mais trabalhoso se algum dia precisar migar. Tu ja deve saber bem o que to falando hehe vcs estão querendo é justamente isso neh.
Trabalho com Oracle Forms considero uma boa ferramenta, mas sou sincero eu prefiria ele client/server :). Alem dos pontos que tu levantou ali sobre o pq usar ele eu colocaria mais um que é a parte de relatórios. Se vcs tem bastante relatórios, o que é normal em um sistema ERP, ai o developer se torna uma ferramenta muito forte principalmente pq podera usaro reports (IMHO - melhor ferramenta de geração de relatórios).
Ha ia esquecendo o forms converte por debaixo dos panos pra java sim.
Até aqui falou meu lado de desenvolvedor Oracle hehehe
Comecando com o lado Java.
Agora um opção que eu levaria muito a serio é SWT+JWS ainda mais com as novas features do SWT 3 que vc pode integrar Swing no meio e outras coisas mais.
É uma API rica em recursos e muito performatica. Nunca usei em produção mas tenho muita vontade de usar em um sistema de grande porte.
E sobre camadas totalmente Web, ou seja, JSP, Velocity + algum fremawork MVC, eu ainda sou meio retraido para alguns sistema complexos, justamente pelo ponto que vcs estão buscando a troca de tecnologia. Usabilidade.
Ps: Quando decidirem pela technologia poste aqui e diga o pq da escolha.
O sistema não é exatamente interno. O sistema roda numa intranet contudo os servidores são externos. O sistema mistura intranet, extranet e internet tudo com uma única abordagem de interfaces. Onde o sistema peca? peca em tentar ser o que não é. Minha opinião “sou contra” a tentar fazer sistemas como esse dessa forma, web. Acho que aplicação browser é browser e desktop é desktop + vamos lá. O sistema possui grande usabilidade, é muito bom contudo não oferece a usabilidde que uma aplicação feita em Delphi/Swing/SWT/Developer poderia oferecer.
Eu não concordo em migrar para oracle (forms/reporst… developer!!!). Acho que existem soluções melhores para isso. Usar soluções java simplesmente CASARIA a empersa com a oracle.
O segredo esta em dividir melhor a aplicação. A parte que pode ser web, usar interface p/ web. A parte que deve ser intranet, usar interface apropriada p/ tal.
Java oferece tudo isso “di gratiz”! pq pagar p/ ter isso!!!
minha maior dúvida é essa, usando ferramentas oracle como mencionado, quando gerar interfaces p/ web ele não estará gerando em java? sendo assim pq não ir direto p/ java?
Nao eh taaaaao simples assim: voce tem que levar em conta o custo de se desenvolver uma solucao usando SWT, Swing ou o que seja, e comparar com o custo de desenvolver usando o Oracle Forms/Reports.
Eu nao tenho a menooooor ideia de quanto tempo se leva pra fazer algo decente em Forms, mas, serio, as minhas experiencias com Swing em desenvolvimento de aplicacoes corporativas nao foram nada agradáveis. Nunca tentei SWT, mas pode ser que seja mais prático (afinal, pelo tanto de plug-in do Eclipse pipocando por aí, deve ser mais tranquilo :D).
Penso assim , time que esta ganhando não se mexe rs…
p/ q mudar p/ oracle application se se pode arrumar (talvez GTK) a aplicação em PHP!
Agora vc me deixou preocupado CV, SWING morde :roll: :oops:
Diz ae, qual foi teu grande problema, já mete o pé na cara logo! se for p/ ficar tonto é melhor agora rs…
Cara, vc ja mencionou PHP-GTK varias vezes nessa thread… se vc acha mesmo que vai resolver o problema, e os programadores sao bons mesmo, vai fundo! Faz uns testes, e diz pra gente se presta
Mas, voltando ao assunto da Swing… sim, Swing morde. Pergunte pra qualquer um que ja mexeu com JTree e JTable bastante, e com certeza o cara vai te dizer que eh lindo, mas eh complicado. Da pra fazer? Sim, mas…
Java Foundation Classes (JFC) eh um pééééé no saco pra aprender e usar direito.
Swing continua lenta, e o release da JDK 1.5 ainda ta longe, e nao vai resolver isso tanto quanto muitos imaginam. Nao é tão lenta quanto na época da JDK 1.2, mas ainda é lenta. E gasta uma memória inacreditável.
Os que ja usaram IntelliJ IDEA vao concordar comigo quando eu digo que esses problemas se resolvem com boa programacao, mas “boa programacao” nao eh algo que se tem sempre à mao num time
Morde e é arisco…mas com uma boa equipe de adestradores (leia-se programadores) vc consegue algo muito bom.
Eu prefiro SWT ainda ao Swing, mas levando em consideração que o aprendizado pode ser mais lento ainda isso pode-se tornar inviavel.
Alem de escolher a technologia vcs tem que avaliar quanto temos vamos levar para dominar ela? Os programadores aprenderão rapido? Ou vc pretende trocar todos eles e pegar uma equipe nova que não conhece o negocio?
Sobre o forms, se a comparação for para o tempo de desenvolviemento ai fica dificil não pegar ele. Masssssss fazer uma aplicação bem feita com ele requer muito mais do que usar o mouse :D, existem coisas mutio dificeis de fazer dependendo da situação.
Primeiro eu pensei em colar um adesivo na testa escrito “Eu amo o IntelliJ” mas agora tive uma ideia melhor. Vou por o nome do meu primeiro filho “IntelliJ Martins”
Já pensou em criar um editor WYSIWYG para um sistema de gerenciamento de conteúdo usando HTML+JS? Sim, isso é possível. Mas não é viável, pois:
:arrow: código muito complexo (já tentou depurar JavaScript?);
:arrow: só funciona em IE (IE para Windows. IE para MacOSX também costuma dar altos paus).
:arrow: código muito complexo (já tentou depurar JavaScript?);
:arrow: só funciona em IE (IE para Windows. IE para MacOSX também costuma dar altos paus).[/quote]
O que só funciona em IE? Acho que eu perdi alguma coisa…
:arrow: código muito complexo (já tentou depurar JavaScript?);
:arrow: só funciona em IE (IE para Windows. IE para MacOSX também costuma dar altos paus).[/quote]
O que só funciona em IE? Acho que eu perdi alguma coisa…[/quote]
Já entrouno webmail do yahoo ou do hotmail e viu aqueles “textareas” que dá pra mudar a formatação do texto?? Então, é de um desses que ele tá falando…
Dê uma olhadinha nisso: http://www.blueshoes.org/en/javascript/editor/
É disso que eu estou falando. É factível, mas não é viável (a não ser que você queira restringir o seu público a usuários de IE em Windows).
Swing não morde. Aqui vai meu ponto de vista partindo do pressuposto que a equipe ainda não domina nenhuma das tecnologias, inclusive Forms/Oracle:
a) Swing + foxtrot.
Demora mais para para aprender e também para desenvolver, mas os resultados são os melhores desde que rodem em máquinas com no mínimo 64Mb de RAM (melhor com 128Mb). Há muitos livros, inclusive um bom livro free (chama-se Swing).
b) SWT
Aprendizado um pouco mais rápida (não muito), porém a documentação é muito escassa. O desenvolvimento é um pouco mais rápido do que com swing. O resultado visual é mais limitado porém o desempenho promete ser melhor.
c) Thinlet
Rápido para aprender, rápidíssimo para desenvolver, resultados limitados que rodam em qualquer máquina.
d) Forms
É como falou o Fábio. Bom se o usuário não for muito exigente
e) Intellij
US$ 400 / usuário. Até que não é tão caro como o JBuilder ou o WSAD. Mas não acredito que sua aquisição vá fazer milagres na redução dos prazos.
f) Manter html + javascript
Ótimo hoje, dor de cabeça no futuro.
Minha sugestão:
Experimente o thinlet, brinque com ele no fim de semana. Se gostar experimente desenvolver alguns módulos com ele separando ao máximo a view de modo que seja possível no futuro substituir por swing (ou SWT). Meça os tempos de aprendizado e desenvolvimento.
Bom digamos que tem um carinha ai que é um pouco VICIDADO em JavaScript…sem noção as coisa que ele faz,hehe…tem de tudo nesse site, Editor HTML, Calendário, etc etc etc…detalhe: free
[quote=“Daniel Quirino Oliveira”]Dê uma olhadinha nisso: http://www.blueshoes.org/en/javascript/editor/
É disso que eu estou falando. É factível, mas não é viável (a não ser que você queira restringir o seu público a usuários de IE em Windows).[/quote]
Bueno,
Restringir ao IE é questão de preguiça. A linda M$ disponibiliza umas rotininhas JS que fazem o trabalho de um editor ser bricnadeira [copiar, colar, etc] mas você não tem controle nenhum sobre o que é feito, alémd e não ser padrão [como o cv disse: ou é M$, ou é padronizado. Amoba sé paradoxo!].
O Jroller tem um editorzinho legal que funciona muito bem no Mozilla [aí a dúvida é o contrário: não sei se funciona no IE, porque não uso, se possível. Tudo que aparece lá é do Gecko, igual ao NVU…que aliás não faz zorra nenhuma,d eixa tudo pro renderizador, mas isso é outro papo…]. Uma vez, quando o Yahoo! disponibilizada um editor descente [hoje em dia é uma caca] eu peguei o HTML e consegui botar rpa funcionar, e funcionava na maioria dos browser. Tirando a bizarrice dos iFrtames, nada demais…
A grande questão é que o browser volta pro cleinte burro, como alguém aqui já falou. Usabildiade é relativo, eu posso ter usabildiade zero com um aplicatico “desktop” [alguém já tentou aumentar o voilume do som no Kurumin?] ou web, tanto faz. Geralmente desenvolver web é mais barato, programador júnior pra fazer camada de apresentação tem as pencas em tudo quanto é lugar, webdesigner tá usando plaquinha “Will work for food”…
Não vejo muitos motivos para uma aplicação cliente hoje não ser web. Um aplicativo pessoal, sei lá, complica, mas uma aplicação coorporativa rodando em rede? Conheço gente que tá usando ate um Tomcat embeebed na aplicação para usar web em micros sem conexão com a internet…
[quote=“pcalcado”]
Não vejo muitos motivos para uma aplicação cliente hoje não ser web. [/quote]
O que vc considera como aplicação Web?[list]1) Uma interface qualquer usando protocolo http/s para se comunicar com outras camadas;
2) Uma interface baseada principalmente em html usando protocolo http/s para se comunicar com outras camadas;[/list]Para mim (1) é uma aplicação web e é assim que trabalhei nos últimos anos. O Banco Postal é o exemplo que sempre dou, mas na verdade trabalhei com outros aplicativos com interface swing e varias camadas acessadas via web. As aplicações tinham até “web” em seu nome.
Usar swing, além do maior conforto para o usuário, permite melhor consistência dos dados e é mais fácil de interligar com periféricos.
Ok, Luca, uma aplicação por HTTP(S) servindo interfaces XHTML a um renderizador gráfico, foi o que quis dizer.
Dizer que HTML+JS ou qualquer variante é ter problemas no futuro é relativo.
Você realmente acha que o overhead de criar sempre algo em Swing, a torto e a direito, só porque integra com periféricos seria legal? Quem garante que todos os clientes precisam ter periféricos especiais? Os outros não podem trabalhar com HTML? Como rodar Swing num micro com 16MB de RAM? Conheço muitos lugares com este tipo de equipamento em produção…
Existe um problema sempre que se cruza um paradigma… Assim é com mapeamento o-r e com apresentação renderizada em HTML. O que itneressa é: qual a real necessidade de não utilizar HTML? E acho que isso quem poderia responder é o autor do topico, mas eu pergunto: por que alguém que rpecisa de um cliente magro iria usar Swing, AWT, XPTO, podendo usar uma interface como HTML, que nem de uma JVM rpecisa pra rodar?
Existem sim, vários motivos para isso [a questão dos periféricos é uma], mas em termos de custo/benefício, qual a melhor solução? Fazer tudo em Swing conectando por RMI, WS, HTTP sei lá o que com um servidor só apra ter um pouco mais de controle sobre o que é apresentado?
Na época em que a Internet e redes eram novidade, isto tinha argumento, agora não mais. É muito mais barato e prático trabalhar com HTML sempre que possível.
Também não vejo os tais “problemas no futuro” citados numa arquitetura de n camadas bem construída. Desplugue HTML, plugue o que vier.
Phillip, [html + js = possíveis problemas no futuro] porque é mais complicado fazer manutenção em um monte de código espalhado por um monte de páginas.
