| Autor |
Mensagem |
|
|
Entendi Ricardo, obrigado!
Os sintaxe suggars complicaram um pouco a minha vida ...
Após a sua explicação testei essa sintaxe
Dessa forma funciona e faz sentido pra mim!
Vou seguir em frente no head first, mas é extremamente contra-intuitivo aprender rails (o framework) sem ter uma boa base de ruby (a linguagem), não farei isso novamente, fica a dica pra quem quiser começar a estudar RoR.
Mais uma vez obrigado!
|
 |
|
|
Olá pessoal!
Estou seguindo o livro head first rails e em um dos capítulos me é apresentada a seguinte sintaxe
Já tinha me deparado com sintaxes parecidas nos capítulos anteriores mas até então fui seguindo em frente. Agora eu gostaria de entender realmente o que estou fazendo aqui pois até agora não consegui entender.
Minha dúvida não é em relação as variáveis ou aos símbolos e sim ao hash, pelo que entendi é assim que defino um hash:
mas se a sintaxe é essa, por que isso não está entre chaves?
pior ainda, por que não funciona quando eu adiciono as chaves?
e isso?
pra mim deveria ser um hash onde a chave é :locals e o valor é outro hash, mas se eu escrever dessa forma também não funciona ?
Não entendi essa construção, poderiam me explicar? já verifiquei o capítulo de hashes do livro ?The Ruby way? mas não consegui sanar minha dúvida.
Obrigado!
|
|
|
|
Bom dia!
Vc precisará implementar sua lógica pensando na quantidade de objetos criados e na memória utilizada, vc precisa de todos esses registros na memória ao mesmo tempo?
|
|
|
|
|
Boa noite, esse código pode dar problema caso o valor do BigInteger seja maior do um inteiro suporta, se não for o caso então não tem problema comparar dessa forma mas vc está usando um BigInteger sem necessidade.
|
|
|
|
Boa noite! Dá uma olhada neste tópico.
http://www.guj.com.br/java/241024-pegar-ultimo-id-auto_increment-inserido-na-base-resolvido
|
|
|
|
|
Bom criei minha conta conforme as instruções do site, imagino que o histórico que consta na prometric só será migrado após 01 de junho certo?
|
|
|
|
Bom dia!
Esse seu método listarTodos é um select sem critérios, então não vejo nenhum grande problema a não ser o que vc já mencionou que irá evitar, que é executá-lo em tabelas muito grandes. Veja se consegue simular esse seu pior caso, que é executar esses 20 selects simultaneamente numa tabela com 500 registros.
Sugestão: pq não usa generics para os outros métodos também?
|
|
|
|
Desculpe não tinha visto o código da página direito, ele chama o set sim, porém ele chama antes de chegar ao código do bean.
o ciclo do JSF possui 5 fases, creio que no momento da chamada ao setCidade eles está na fase "update Model Values" que é fazer com que os dados sejam populados nos beans. Creio que uma exception lançada nesta fase não possa ser capturada, pelo menos não no bean.
Como solução só consigo pensar em retirar essa validação do set ou dar uma estudada nas fases do JSF e ver se é possivel capturar essa exceção de alguma forma.
segue um link explicando sobre as fases: http://marcusmazzo.wordpress.com/2008/12/13/ciclo-de-vida-jsf/
|
|
|
|
Provavelmente o seu metodo setCidade não está sendo chamado dentro de um bloco de codigo que trata a exceção.
Em qual momento vc chama o setCidade na sua lógica?
|
|
|
|
Java wrote:
No caso então, FieroddPJ, vc enchega os EJB's como uma camada de "interfaceamento", ou seja, de comunicação entre objetos ou recursos em locais diferentes. Mas mesmo assim, dependendo da aplicação, pode haver regra de negócio no EJB. Claro que não é nada legal, mas pode ser que seja necessário. Eu sinceramente, e me desculpem e me ajudem se eu estiver falando besteira, gosto bastante do conceito de camadas. Uma camada somente para negócio, uma somente para o Banco (Famoso e Conhecido DAO), etc.
Seria correto então guardar todos os meus EJB's em um pacote e determinar que os mesmos são uma camada apenas de comunicação de objetos em locais diferentes?
Eu sugiro colocar seus EJBs em um pacote especifico, mas por organização não por causa de alguma regra ou padrão.
Sim eu vejo os EJB como forma de tornar meus objetos localizáveis e adicionar a eles todos os recursos que a tecnologia EJB oferece, mas isso não quer dizer que eu sempre crio objetos especificos para serem EJBs, muitas vezes o que eu preciso é apenas disponibilizar objetos já existentes, neste caso eu transformo esses objetos em EJBs o que faz que meu EJB tenha regras de negócio, não vejo problema nisso.
|
|
|
|
|
Eu posso usar um design pattern em qualquer situação que seja pertinente usá-lo, acho que fui bastante infeliz no meu exemplo ... mas não acho que possa dizer que eu uso um pattern sempre pra esse caso e outro sempre para aquele caso.
|
|
|
|
|
Coloque um bean no escopo de sessão, após validar o login vc preenche esse bean com as informações que precisar, se eu bem me lembro com JSF 1, vc cria a classe, lá no faces-config vc mapeia ele como sessionscope e cria os get/set na classe que vai usa-lo, a partir daí o IoC do JSF injeta esse bean no seu objeto.
|
|
|
|
|
A solução mais comum é armazenar essa informação na sessão, objeto HttpSession ou ja que está utilizando JSF, coloque um bean no escopo da sessão e utilize as informações quando necessário
|
|
|
|
|
Não entendi sua dúvida, no seu post não tem informações suficientes
|
|
|
|
Concordo com o autor do artigo ao mencionar o MVC com o design de componentes e citando o exemplo do swing, neste contexto aplicando o MVC em um componente faz todo o sentido que o model se comunique com as regras e não as tenha, afinal um botão do swing não teria como saber oq ele teria que fazer até eu codificar.
Agora o artigo reforça ainda mais que os EJBs não estão diretamente relacionados ao MVC e não diz que os EJBs não tem lugar no MVC e eu não entendi como ele ajuda a responder a questão inicial que era "EJB tem Lugar no MVC?"
Pensando dessa forma um EJB (Session ou MDB) corrersponderia a view/controller também pois seriam esses objetos com os quais vc lidaria e eles encapsulariam o model.
|
|
|
|