- 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:
[quote=“pcalcado”]webdesigner tá usando plaquinha “Will work for food”…
[/quote]
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