PHP + Oracle + Java + ... essas coisinhas lindas ;-)

Este sistema de vocês é interno?

Bem de qualquer maneira alguns pontos:

• é 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

Espero ter ajudado!

Olá,

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.

]['s

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?

ALguém aqui já usou GTK com PHP?

abração pessoal

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…

1. Java Foundation Classes (JFC) eh um pééééé no saco pra aprender e usar direito.

2. 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

Será? :lol:

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.

Eita ferramenta boa

]['s

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”

Uma curiosidade: onde o html+javascript tá deixando a desejar? Pode dar um exemplo real?

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

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

O que só funciona em IE? Acho que eu perdi alguma coisa…

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

Olá

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.

[]s
Luca

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

http://dynarch.com/mishoo/htmlarea.epl

Observem e babem os demos online que o cara fez…

ps: vale a pena conferir o Editor HTML full-loaded dele…

“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).

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…

[]s

Olá

“pcalcado”:

Não vejo muitos motivos para uma aplicação cliente hoje não ser web.

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.

[]s
Luca

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.

[]s

Olá

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.

[]s
Luca

• JavaScript modularizado, só apresentação
• HTML Modularizado, só apresentação
• Regras de negócio no servidor

Não vejo como isso seria diferente com Swing :roll:

[]s

Olá

PC, com swing você pode ter mais de 1200 classes obedecendo às melhores práticas, usando design patterns, usando models, proxies, observers e tudo o mais que o Java lhe permite.

Para entender as vantagens, vá à uma agência dos Correios e dê uma olhada no Banco Postal que só no aplicativo cliente usa mais de 1200 classes. São mais de 10.000 terminais clientes, alguns situados em cidades com acesso só por avião ou só por barco. São mais de 300.00 transações por dia. Cada transação vai do cliente até Brasília, de Brasília até Osasco/SP, volta para Brasília e depois para o cliente. Se o resultado da transação por qualquer motivo não for impresso tudo é desfeito em todos os servidores.

[]s
Luca

Luca,

Estamso falando de clientes magros. Não preciso processar nada no cliente, repciso dar uma interface pra pessoa interagir com um servidor.

HTML é um saco para debugar, JavaScript nem se fala, mas Swing não corre por fora não… Também é problemático que dói. Você pode usar Design Patterns com Swing, mas eu posso dar o HTML prum webdesigner mexer no NVU ou DreamWeaver e o layout vai ficar pronto muito mais rápido. Dificuldade de debugging por dificuldade, fico com o HTML, se encher muito o saco jogo fora e faço outro requerimento de Interface pro design.

Não sou um defensor do HTML, mas não existe jeito mais prático de criar uma interface de usuário hoje em dia. O que falei sorbe paradigmas é válido, passar informação pra HTML é problemático, ams nada de outro mundo. Na minha opinião, só não deveria ser feito em casos extremos.

Este exemplo do Banco Postal não me foi muito claro. Suponho que haja algum periférico especial, mas suponhamos, para efeitos de comparação, que não haja, a aplicação é um cliente magro. Qual o problema do sistema transacional que vai de uma cidade a outra em HTML? O que está em HTML é o que o usuário vê, o que tá atrás não interessa para ele, e é isto que garante toda a transação que você falou, não tem nada a ver com HTML ou Swing

Aliás, e se a agência na primeira mangueira ao lado esquerdo da segunda vila do rio Amazonas quiser usar o Banco, mas não tiver nada mais que um 486 DX 66? Eles choram? Fazem upgrade?

[]s

Olá

Sem querer polemizar, mas já me divertindo na polêmica faz tempo…hehehe

Justamente o que eu estou supondo é que um cliente “gordo” pode oferecer muito mais do que a pobre interface html+js. Este “mais” pode ser em conforto para o usuário, em consistência dos dados, em acesso ao que você quiser inclusive gravando no HD local, etc.

Uma agência de banco obrigatoriamente usa periféricos tais como pinpad, leitor de código de barras, impressora, leitor de cartão magnético. Os correios ainda usam balança e outros mais.

O exemplo do banco poderia ser trocado por uma loja de uma cadeia como a Droga Raia que também usa swing (*). Ou trocado pela tela de captura de transações de cartão de crédito via web ao invés de via o caro X25. Daqui a pouco tempo pode ser que você veja swing em milhares de ATMs. Quem sabe em uma padaria perto da sua casa você não consiga pagar uma conta, carregar seu celular ou comprar (e receber na hora) um ingresso para ver o mengo no maraca? Pode estar certo que há muito espaço para clientes “poderosos” (**) pois todos estes exemplos rodam em máquinas padronizadas especialmente para este tipo de aplicação.

(*) Onde leu swing, pode ler também SWT ou até thinlet (que roda até na JVM da microsoft)
(**) Cliente poderoso = cliente gordo.

[]s
Luca

Ahhhhhhhhh…que que tem chamar o cliente de gordo?

Luca, a questão é: canhões e moscas.

Pense em aplicaktivos CLIPPER, quantos você vê por aí que poderiam ser substituidos por HTML+JS puro? Não disse para fazer TUDO em HTML, mas o que for possível. É mais barato e atende o cliente perfeitamente, pronto.

Não é todo lugar que tem periféricos, ou que precisa de coisas como acesso ao disco [que, dependendo do contexto, podem muito bem ficar no “Save as…” e no <INPUT TYPE=“FILE” ]. Os dois exemplos que você citou [Correios e Droga] utilizam periféricos, logo concordo com você que precisam de interfaces mais elaboradas.

Detalhe que nós estamos falando de algo que nem sabemos: será que o aplicativo/ERP precisa? Talvez sim, talvez não, talvez só o módulo X… Como foi feito em PHP,a credito que já não precise. Se amanhã a logística precisar de um leitor magnético, põe um cliente Swing/AWT/PQP lá, e deixa quem não precisa em paz…

Vem cá, nós somos os únicos doidos que não saíramd e casa no sábado a noite ou é imrpessão minha?

[]s

uehuehuheue - eu acompanho as discussoes.

Marcio Kuchma

Impressão sua. :lol:

“pcalcado”:

webdesigner tá usando plaquinha “Will work for food”…

Senti um certo preconceito nesse comentário…

Diria que todas as etapas no desenvolvimento são importantes… Ou será que o chefe realmente vale mais ?

oazuc,

Sentiu mal, o que disse é que webdesigner tem TANTO no mercado, que o salário não é alto. Não entendi como “WIll work for food” seria preconceituoso, mesmo proque até engenheiro tá assim hoje em dia…

[]s