| Autor |
Mensagem |
|
|
Um dataTable normal renderiza seus componentes filhos com a tags HTML <table>, <tr> e <td>. Portanto, isso foge do escopo do JavaServer Faces e entra no escopo do HTML.
É se se perguntarmos se existe uma maneira de renderizar, através de CSS ou até mesmo de JavaScript, um table de forma horizontal. Isso é algo que não sei.
O que eu posso dizer é que, se você estiver utilizando o Tomahawk, ou puder adicionar o jar deste na sua aplicação, pode usar a tag <t:dataList> para a renderização.
Dê uma olhada em http://myfaces.apache.org/tomahawk/dataList.html pra ver como funciona, e baixe em http://www.apache.org/dyn/closer.cgi/myfaces/binaries/tomahawk-1.1.6-bin.zip.
Até.
|
 |
|
|
rafaelvasconcelos wrote:Ah só uma última coisa que esqueci, tentei pelo link, mas se vcs perceberem tem um botão alterar na última coluna, se conseguir fazer funcionar por este também é válido.
Ah sim! Não é outputLink que você usa, é commandLink. Funciona igualzinho ao commandButton, basta trocar o nome e deixa as propriedades das tags como está.
|
|
|
|
Vixi! Então é mais fácil do que pensei! Você havia falado em uma solução pra pegar a coluna, mas na realidade você quer pegar a LINHA!
Bom, primeiro esquece o que eu falei antes.
Segundo, troque o retorno de um array simples para um DataModel do pacote javax.faces.model, ficando assim:
DataModel é uma classe base, você usa uma de suas classes filhas. Uma das implementações interessantes para o seu caso é ResultSetDataModel que encapsula um ResultSet de java.sql, ficando mais ou menos assim:
Bom, e daí? Qual a diferença em utilizar o DataModel? A diferença é que o DataModel guarda o valor da linha que o usuário selecionou! Então você pode criar uma ação (no mesmo Managed Bean em que está o model) para exibir os dados individuais, por exemplo:
Aí, na nova tela onde exibe os dados (configurado em faces-config.xml para o resultado da ação "exibir"), basta você pegar a propriedade currentPerfil desse mesmo ManagedBean.
Certo?
|
|
|
|
Você está se referindo a uma tag do JavaServer Faces, não é?
Por que se for, prepare-se que a solução é cascuda!
Primeiro, faça um binding no dataTable, ou seja, faça com que o componente seja gerenciável através de um ManagedBean. Assim:
Essa propriedade 'component' será definida no seu managed bean assim:
Agora, quando renderizar o dataTable, o Faces vai olhar a propriedade component pra ver se retorna algum componente, na primeira vez retorna null, então ele vai criar um UIData (na verdade um filho deste) e setar na propriedade component. Se o managed bean for de sessão, nas próximas vezes, como o get não retorna null, será usado este mesmo componente sem criar um novo.
Bom, com o managed bean tendo acesso ao componente, basta pegar o valor do cabeçalho da coluna lembrando que: os filhos de UIData são UIColumn, e cada UIColumn pode ter um header representado por UIOutput. Veja como eu pego os nomes de coluna abaixo:
Era isso a sua dúvida?
|
|
|
|
Cara, antes de fazer um deploy, faça sempre uma validação no xml. Erros de xml vão sempre causar resultados esotéricos. Não sei como é no Eclipse, mas no NetBeans, basta apenas clicar com o botão direito no formulário e selecionar 'Validade Xml'
Os erros que eu vi são dois:
1) Não existe a tag displayname, o que existe é a tag display-name, com hífen
2) A url-pattern tem que começar com / ou *.
Vê se são esses problemas, e procure ver se no Eclipse tem validação de XML.
Ok?
|
|
|
|
Em um padrão MVC, não há dificuldade nenhuma em dizer qual parte é a view, normalmente é o HTML, o JSP, ou a estrutura de componentes visuais em Java. O problema surge na hora de se separar o model do controller: já ouvi gente dizer que o controller são as regras de negócio, e o model são os dados ou os POJO. Não é nada disso. Qualquer coisa que faz sua aplicação funcionar, tanto as regras de negócio quanto os dados, pertence ao model. O controler é apenas aquela parte do código que irá responder a alguma interação do usuário e nada mais. E o model ainda pode ser dividido em camadas também, como os tão badalados DAOs, mas estes ainda não deixam de ser model.
|
|
|
|
O problema é que você está colocando como value de selectOneMenu a mesma propriedade de selectItems. É um erro de lógica. Em selectOneMenu você coloca uma propriedade que armazena o valor que o usuário selecionou, não uma propriedade de lista.
Ficaria assim:
Contando que exista uma propriedade optionSelected no seu ManagedBean.
Ok?
|
|
|
|
O Hibernate tá dentro do Java através da JPA. Agora quanto ao Spring, eu quero que fique fora e nunca entre no Java EE. Até porque hoje, o melhor container de injeção de dependência é o Guice.
E outra coisa. Que mania esse pessoal tem de achar que Struts devia ser oficial, ou que Spring devia ser oficial, ou que o framework X devia ser oficial. Meu, isso não muda nada. O mais importante que um framework deve conseguir é sua padronização de fato, não sua padronização oficial.
|
|
|
|
Cara, há alguns dias eu comentei sobre isso no meu blog. Você pode ver a problemática e a solução que eu criei no link: http://objectzilla.wordpress.com/2007/09/16/nem-tudo-em-java-sao-flores/
Ok?
|
|
|
|
renomoto wrote:Paga mal, mas nao eh toda empresa q te da um notebook, um carro, um 14,15,16 salario, pr. (Nao to defendendo ninguem, muito menos a acc so to expondo q nao eh so pagar mal)
Tem gente q tem ja sua vida formada e vai trabalhar por hobbie como essas pessoas que vc falou.
Pode ate ser mais acredito q tem gente feliz la dentro e considera isso mais importante do q so dinheiro.
Abs!
Olha, notebook não é benefício, é trabalho pra casa. Ainda assim, eu nunca recebi um notebook de lá. As pessoas que eu falei não trabalham por hobbie, eu nem disse isso, dentro do trabalho somos até estressados. O que eu quis dizer é que são pessoas que tem uma vida pessoal além da profissional.
E esse negócio de felicidade é lavagem cerebral da Accenture, os gerentes sempre diziam pra gente que deveríamos estar feliz com o nosso trabalho (é só uma maneira hipócrita de dizer: trabalhe por felicidade, não por dinheiro). Numa outra empresa, ouvia gerente de alto escalão dizer que só tava ali por causa do dinheiro. Não que ele fosse uma pessoa cínica que só se importa com bens materiais, mas era uma pessoa consciente de que existe o conflito entre o capital e o trabalho, e de nós estávamos ali para garantir nosso sustento. Na Accenture não, falar de dinheiro é palavrão.
|
|
|
|
renomoto wrote:Acredito q isso seja ponto de vista para diversas pessoas.
Eu ja vi casos que pessoas entraram la pra ganhar mais por ter mais experiencia. Mas claro estamos falando de salario e nao estamos colocando os beneficios que ela da para os funcionarios e que por acaso ela esta entre as 150 melhores empresas para se trabalhar no BR.
Se for pelo salario talvez a acc nao seja tao atrativa para os olhos das pessoas, mas cada um tem seu ponto de vista. hehe
Abs!
Fato número 1: a Accenture paga mal, uma pessoal pode até entrar ganhando mais por ter mais experiência, mas poderia ganhar de 50 a 100% mais se entrasse em outro lugar.
Fato número 2: Eu só passei a saber o quanto a Accenture é ruim quando eu troquei de emprego e percebi que meus novos colegas conversam sobre os filmes que viram, a sua família, os passeios que tiveram, ou seja, conversam sobre uma vida que as pessoas da Accenture não conseguem ter. Também percebi o quanto a sobrecarga de trabalho é prejudicional pra minha própria carreira, pois passei a ter tempo de fazer um curso ou de ler um livro técnico, que melhoraram a rotina do meu trabalho.
Fato número 3: a Accenture, quando eu trabalhava lá, fazia propaganda ostensiva entre seus funcionários para que estes falassem bem dela pra Revista Exame. Acredito que se não fosse isso, estaria com certeza na última posição.
|
|
|
|
RafaelVS wrote:Mas a idéia da opção A não eh GARANTIR o reuso... é AUMENTAR A POSSIBILIDADE de reuso. Se vc coloca validação no método vc vai estar amarrando a implementação... se não fizer isso, aumenta a possibilidade de reusar a classe em outro banco.
Se a conta de um banco A tem as mesmas propriedades da conta de um banco B mas possuem regras de validação diferentes, eu poderia reusar aquela classe se a validação não estiver na classe Conta... Mas se as contas possuem propriedades diferentes, aí eu n poderia reusar... mas pelo menos eu tenho a chance de reusar no primeiro caso.
E esse exemplo que eu dei foi bem simples, que fica facil de entender.. tem casos onde as propriedades das classes mudam menos do que as regras de negócio.
Além disso, estou dando exemplos que motivem a implementação usando uma arquitetura em camadas (mantendo as camadas: classes basicas, repositorio, regras de negocio, fachada, gui) e separa codigo de negocio da classe basica eh uma boa opcao para aumentar a possibilidade de reuso.
Reusar atributos é um tipo muito pobre de reúso. E quanto a aumentar ou não a possibilidade de reúso, isso é subjetivo demais. A minha crença é não.
A arquitetura em camadas que você fala não é da maneira que eu imagino e costumo fazer. As regras de negócio não ficam em cima da repositorio e das classes básicas. Ficam justamente dentro das classes básicas! E não há razão de não ser assim, as regras de negócio independem de contexto cliente-servidor, de clusterização ou de qualquer que seja. Agora, persistência, camada de serviço (facade) e gui dependem de contexto específico e merecem ficar em cima das classes básicas.
|
|
|
|
RafaelVS wrote:Continuo achando que eh impossivel acessasr os atributos privados... no maximo quando vc mapeia seus atributos usando JPA, vc consegue porque vc tb cria os get/set que sao public... por Reflection vc nao consegue ler/escrever em um atributo privado... se isso fosse possivel, toda a "seguranca" de manter um atributo privado seria jogada fora.
No caso da necessidade de usar um BigDecimal, para nao quebrar o contrato da classe vc precisaria manter o public double getSalario(); e adicionar um public BigDecimal getSalarioNovo();.. em seguida, tornar o antigo getSalario deprecated.
Por increça que parível, a JPA é capaz sim de acessar um atributo privado sem get/set. Só não sei como, mas faz. Eu já fiz esse teste e funciona. Faça você também e verá. Tudo bem que a "segurança" seria jogada fora, mas por mim, seria por uma boa causa.
Agora, quanto a criar um novo método getSalarioNovo() e fazer getSalario() deprecated é uma idéia ridícula! Normalmente, um método deprecated é simplesmente marcado como tal, e não se mexe mais nela. Mas nesse caso não, ou você: a) cria tanto o atributo float e BigDecimal dentro da classe e se vira pra sincronizá-los, ou b) você troca float pra BigDecimal e reimplementa um método que imediatamente vai virar deprecated e não terá serventia nenhuma. Além do mais, você não evita a reescrita de outras classes, apenas posterga para uma data indefinida.
O grande nabo do excesso de getters e setters é que muitas vezes a pessoa cria regras de negócio fora da classe, mas não apenas em uma outras classe, mas em várias, e de maneira desorganizada. Muitas vezes, numa equipe média ou grande, ocorre até repetição de código. A colocação dessas regras dentro da classe é eficiente para que esses problemas não ocorram.
|
|
|
|
RafaelVS wrote:
Então, imagine que Conta tenha duas operações: creditar e debitar. Ambas atualizam o atributo saldo, uma incrementando uma valor e outra decrementando. Além disso, a operação debitar precisa validar se a conta tem saldo suficiente.
A) Dependendo do projeto, podemos na classe Conta criar simplesmente um método setSaldo(double valor) que atualizará o saldo com o valor informado, sem fazer nenhuma validação.
Na classe que trata das regras de negócio (aqui chamada de CadastroConta) deverá ter os métodos creditar() e debitar(). O método creditar() simplesmete somaria o valor e chamaria o setSaldo(novoValor) da conta. O método debitar() faz a validação, verificando se a conta tem saldo suficiente para debitar o valor informado e chama o método setSaldo(novoValor), onde o novoValor já é o valor final, após diminuir o saldo.
B) Outra opção, seria na própria classe Conta ter os métodos creditar() e debitar(), que funcionam como um "setSaldo" só que já contém implementação de regras de validação, se necessário. Aqui simplificaríamos os métodos na classe CadastroConta, que não precisariam fazer validação e simplesmente delegar a operação para a classe básica, que fará a validação.
Uma vantagem em tomar a decisão A é que vc está aumentando a possibilidade de reuso da classe Conta... já que ela não tem nenhum tipo de validação... por exemplo, se vc colocar o sistema em um outro banco onde a validação para a operação debitar é verificar se tem saldo com algum limite especial, a sua classe Conta não seria afetada.. vc só precisaria mudar no método da classe CadastroConta. Uma desvantagem é que vc poderia, sem querer, através de algum método chamar diretamente o setSaldo(valor) podendo passar um valor sem fazer validação (mas se vc tomar a decisão de poder reusar a classe Conta, vc terá que tomar esse cuidado de não utilizar o método de maneira indevida)
Uma vantagem em tomar a decisão B é que ficará mais seguro... a partir de qualquer lugar vc pode chamar o método debitar() passando um valor inválido que o método irá validar corretamente e só atualizará os dados se tal operação for válida. Uma desvantagem é que se vc precisar reutilizar essa classe em um banco que usa uma política diferente para validação (como a que citei acima) vc precisaria escrever uma nova classe Conta para aquele banco.
A mesma idéia serve para o método creditar().. se ele é definido no CadastroConta e eu precisar reusar a classe Conta em um sistema que tem uma política diferente para creditar (por exemplo, se o saldo a ser creditado for maior do que X, será dado algum bônus para o cliente da conta) eu poderei fazer isso. Pois a classe Conta tem apenas um método setSaldo() sem validação e eu posso usa-lo tanto para creditar quanto para debitar (independente da regra envolvida)
Por isso falei que isso é uma questão de decisão de projeto... não tem a forma certa ou errada, vc é quem decide, nesse caso, se vai querer integridade dos dados ou se vai querer maior possibilidade de reuso.
Não é por nada não. Mas o argumento que você usou pra opção A é pouquíssimo convincente. Você acredita que se deva fazer a separação entre uma classe com métodos (CadastroConta) e uma classe com propriedades (Conta), pois a primeira pode variar entre bancos, e a segunda seria estático. Ora, quem garante que as propriedades de Conta também não mudam entre bancos? Isso não faz sentido!
Talvez um jeito de garantir reúso seja a utilização de design patterns como o Template Method, do jeito que você falou, o reúso não acontece.
|
|
|
|
Nãããããããããããããããão.
Brincadeira! Vai precisar sim. Depende so seu banco de dados. Se for Postgres, vai precisar do JDBC do Postgres (normalmente vem junto quando você baixa). Se for MySQL, vai precisar do Connector/J (essa não vem junto, vai ter que baixar depois). E por aí vai.
|
|
|
|
|
|