| Autor |
Mensagem |
|
|
Louds, como vc faz com Exceptions que seu runnable tem que lançar? Tudo unchecked?
O esqueminha do Tiny Marbles é exatamente assim, mas ainda não consegui inventar um esquema decente de lançar exceções arbitrárias.
|
 |
|
|
"Brevity is the soul of wit". Acho que eu devia mudar minha sig.
|
 |
|
|
Meu, que pena que so deu pra olhar essa thread agora...
Tava la atras na discussao um uso de commands:
structure a system around high-level operations built on primitives operations. Such a structure is common in information systems that support transactions. A transaction encapsulates a set of changes to data. The Command pattern offers a way to model transactions. Commands have a common interface, letting you invoke all transactions the same way. The pattern also makes it easy to extend the system with new transactions.
Ninguem precisa de commands. Commands tem pros e contras, vc sempre tem um compromisso. Em todos os comentarios do pcalcado existe a suposicao de que os comamnds vao ficar em cima da camada de aplicacao, se eu entendi direito.
Mas os commands podem ser usados pra mais do que apenas ponteiro de funcao, e mais do que apenas ParameterObject. Eles podem ser uma forma consistente de chamar uma funcao que a camada de baixo nao conhece. Esse eh o ponto onde eles brilham.
Voce so consegue entender o command se olhar pro executor:
Bom, eu omiti o bloco finally onde vc fecha a transacao, o socket, etc. Seu command pode fazer muitas suposicoes sobre o estado dos dados.
Thiago, se vc quiser fazer view em Swing, vc vai ter que usar o padrao Command mesmo que vc nao seja explicito:
Esse eh um jeito consistente de executar coisas na thread certa (AWT Dispatcher), sem saber o que eles fazem.
Claro que o seu command nao vai ter a logica, ele tem que ter um comando, uma ordem. Ele nao faz nada, manda fazer.
Bom, vou ficar por aqui, pq eu ja falei pra uma semana!!
Abracos!
|
 |
|
|
Mas uma coisa nao tem nada a ver com outra, tem?
Um comando (do Prevayler ou nao) precisa saber achar o objeto.
Eu acredito que o Command Pattern e um dominio rico nao sao excludentes... mas eu ja tive algumas dores de cabeca com o Hibernate pra dizer que tem vezes que a gente precisa ser condescendente... [ ]
[]s!
|
 |
|
|
quando vc instala o jdk, vêm uns demos. Um dos demos mostra o JEditorPane. Olha o fonte desse demo, tá lá tudo explicadinho, acho que vc pode até copiar o código.
[]s!
|
 |
|
|
Bom, eu acho que posso dar umas dicas.
1. Começa pensando que vc só vai fazer a interface em Swing.
2. Invariavelmente vc vai acabar desenvolvendo MVC, e alguns padões vêm bem a calhar: DAO, por exemplo, e o padrão Command.
3. Se vc usar o padrão command direitinho, vc pode construir fachadas pra criar esses comandos, e essas fachadas podem ser objetos remotos que vc acessa por RMI.
4. Seus servlets (porque não webwork?) podem usar as mesmas fachadas e os mesmos comandos. A lista de objetos que vc puxa da fachada pode ir pro contexto do velocity, ou preencher o modelo na app Swing.
5. Vc pode ter sua app rodando num processo separado, e tanto os clientes em Swing como os servlets (ou actions do webwork) acessam remotamente. Vc tem uma app 3-tier!!
Fui simplista de propósito, pro post não ficar muito grande, e tem vários detalhes que eu nem parei pra pensar. Mas já fiz uma coisa assim e compensa muito. Mas vc tem que saber manejar o tempo legal.
[]s
|
 |
|
|
Aí é que tá. Bani, c não acha que se fosse fácil, já ia ter um monte de aplicação parecida??
Te prometo que em duas semans (quantas pessoas? 6, no melhor caso?) não sai nada assim. Fazer GUI demora. Ainda mais se o seu time não tem muita experiência.
Masssss... se vc conseguir reduzir a especificação pra caber em duas semanas, vc pode implementar algo na linha da GML, e usar aquele grafo básico da faculdade (i.e.) sem atributos, sem algoritmos.
Daí vc serializa com XStream ou Castor ou etc. Essa parte é baba.
Daí vc pega metade do seu time pra trabalhar na GUI. Eles vão ter que implementar MVC, é bom que seja gente com experiência nisso. Nem olha a API de DragNDrop, c só vai perder tempo. C vai ter que implementar também um modelo específico pra sua área de trabalho "infinita".
Acho que vale a pena olhar o SwingBuilder do Groovy. Na beta-4 tá funcionando bunitinho!
Prepare-se para uma semana de 50 horas. E siga os princípios do cronograma encaixotado (com data pra começar e pra terminar):
Se tiver feio, deixa feio
Se quebrar, cola, não conserta
Todo mundo tem culpa se estiver ruim
Todo mundo ganha breja se entregar no prazo
A empresa paga a pizza
Boa sorte, do fundo do coração.
|
 |
|
|
|
Legal!!
|
 |
|
|
Que thread linda, pena que tá em português!!
Eu pensei que o javac gerava as strings internas sempre em UTF-8...
Aqui dá bastante problema com o CVS, a gente comita, e quando volta vem zuado...
[]s
|
 |
|
|
Opa, opa, isso pode ser um fedor de código.
setIgnoreRepaint(boolean) só serve pra ignorar eventos de repaint que venham do SO: minimize/maximize, ou quando outra janela (não-java) passa em cima da sua, coisas assim.
Se não é exatamente isso que vc quer, cheira mal.
[]s!!
|
 |
|
|
Mas se a coisa apertar, Napkin LnF neles!!
A alpha 5 já dá pra usar... antes dava só pau...
http://napkinlaf.sourceforge.net/
[]s!
|
 |
|
|
será que daqui a 6 meses alguém pergunta pra ele o que aconteceu?? Será que eu lembrO??
[]s
|
 |
|
|
|
...e depois ler o javadoc da java.io.Reader e classes relacionadas... : )))
|
 |
|
|
Só posso dizer uma coisa: a palavra futuro está muito mal utilizada aí.
Não por você, cerb, mas recomendo o seguinte: monte um "pauerpointe" explicando por que não vale a pena reinventar a roda. Aliás, pegue um pronto (google?) e traduza (acho que em pt não tem, mas vai que vc dá sorte).
Faça uma apresentação pra eles, mostrando que "futuro" não existe: o preço de adotar uma tecnologia lá na frente vai ser igual ou maior ao de adotá-la desde já. Eles não tão vendo um palmo à frente do nariz e tão morrendo de medo. Não querem usar nada que não seja padrão, mas têm certeza ou tratam com displicência que "O dados de retorno são enviados a uma página JSP".
Isso é, com o perdão da palavra, cagar e sentar em cima. Não basta a não querer usar um framework pronto, não dá a devida importância às decisões que sem muita discussão são tomadas. Acertei ou errei? Me diz se alguém questionou essa frase aí...
Mostra pra eles que, se eles adotam um Hibernate, eles têm você e mais vários outros developers pelo mesmo preço. Que vai ter gente procurando bug, otimizando e adicionando funcionalidade ao software, bugs a menos pra vc, que vc ganha de graça sem pagar nada (talvez o tempo gasto com um upgrade).
Se eles conhecem o Portal Builder do TIBCO, fala que ele é feito em cima do Turbine do jakarta. Se nem assim eles te derem ouvidos, procure outro emprego, vc não vai ser feliz aí.
[]s!
p.s.: eu ano passado forcei a barra com o Hibernate, e hoje a gente não pensa em desenvolver diferente.
|
 |
|
|
Eu diria que o fórum de Padrões, Arquiteturas e Projetos foi pensado para discutir
novidades do mundo da computação que podem vir a ser padões, arquiteturas e projetos
projetos que os usuários do GUJ estão fazendo
discussões sobre quais frameworks usar pra cada coisa. Não sobre como usá-las.
Eu acho que uma nova descrição ia bem...
Mas entendo o problema do pessoal que quer perguntar sobre frameworks. C vai postar uma dúvida de webwork no fórum de JSP? Não parece o frango assado do jantar vegetariano??
Acho que uma sessão é muito, mas um outro fórum sobre "frameworks gerais" podia existir. Eu não sei qual é o movimento no fórum de Servlets, se for pequeno, podia colapsar tudo lá, e renomear o fórum para "Java no servidor", ou "frameworks pra web", ou algo assim. Senão, talvez um fórum próprio.
Há algumas semanas eu acho que esse fórum aqui tá com movimento demais, esse não era pra ser um fórum muito cheio, pq ninguém tem muita paciência de discutir "setter- ou constructor-injection" e coisas assim.
Espero ter ajudado,
Aquelão!!
|
 |
|
|
|
|