Jump to content
Notícia
  • Junte-se ao clube de Membros VIP e desfrute benefícios

Search the Community

Showing results for tags 'artigo'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Anunciantes
    • Advertise here
    • silvaBR Cheats
    • WoXArea
    • SecureCheats
    • Cheat Gamers Club
  • ################## WEB CHEATS ##################
  • Anúncios/Eventos
    • Regras
    • Anúncios
    • Eventos do fórum
  • Feedback & Suporte
    • Tutoriais WC
    • Suporte
    • Sugestões
    • Denúncias e Reclamações
    • Depósito
  • WebCheats Premium
    • Trackers & Warez
    • Download
    • Cracking & Serviços Pagos
    • MarketPlace
    • Conteúdo Adulto
    • Taverna WebCheats Premium
    • WebCheats Premium - Lixeira
  • Shooter Zone
  • RPG/MOBA Zone
  • Outros Games Zone
  • Design Zone
  • Info Zone
  • Video Games Zone
  • ################## WEB CHEATS ##################
  • Entretenimento & Diversão
  • 【FREE FIRE】▄︻┻┳═一's Fórum do Clube
  • teste's Tópicos

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me


Discord

Found 5 results

  1. Layout Fluído ou Responsivo Muitas pessoas confundem os layout fluídos com os responsivos, pensam que tudo que é responsivo apenas estica e diminui, mas não é bem assim. Layouts fluídos são bem diferentes de responsivos, pois o Fluído (como o nome diz) flui com o tamanho da tela do usuário, enquanto o Responsivo responde ao tamanho. Layout Responsivos Os layouts responsivos são aqueles que precisam ter uma atenção maior da área de UX, quando é analisada toda a usabilidade do site, contemplando todos os dispositivos e se possível partindo do princípio “mobile first”, onde toda a arquitetura começa sendo pensada a partir do menor dispositivo utilizável seguindo em ordem crescente e adequando as informações. O layout não segue a mesma estrutura em todos os dispositivos, muitos trocam as informações de lugar para melhor visualização, as vezes escondem e mostram a partir de um click, mudam os tamanhos das fontes, ícones e qualquer outro elemento. Para esse tipo de desenvolvimento são utilizadas as media queries css e algumas libs como bootstrap, groundwork e o LazyLoad. A seguir você confere 3 estados diferentes para layout e sua respectiva reação com a página. Monitores com resolução de 1024px de largura ou superior e Internet Explorer 8 e inferior. Foi declarado uma largura absoluta de 960 px para o corpo do site. Largura igual ou inferir a 900px. Aqui declaramos que existem apenas larguras relativas de 100%. Largura igual ou inferir a 400px. Ocultamos a sidebar do lado esquerdo (apenas para ilustrar o exemplo). Neste exemplo podemos ver claramente como o efeito cascata do CSS funciona corretamente com o Media Queries, desta forma o CSS que fizemos como padrão é mantido normalmente por todo o documento, sendo alterado apenas quando declaramos alguma modificação com o Media Queries. Note também que o css declarado para a largura de janela de 900px é mantido para o de 400px. Layouts Fluídos Os layouts fluídos são aqueles que acompanham o tamanho da tela, apenas aumentando e diminuindo, não trocando estrutura e não pensando muito na usabilidade, vamos pensar em acessar um site em uma tv de 50″ e acessar o mesmo site em um celular onde esse site é visto da mesma forma pelos 2 dispositivos, é claro que ficará horrível em um dos casos se não nos dois, para construir esse tipo de layout não se pensa muito em “px” e sim em “%”, para que o elemento se estique de acordo com o pai tendo assim a sua “fluidez”. Aqui tem um exemplo simples de como ele funciona: 960.gs. Para ilustra melhor o que estamos dizendo, a imagem a seguir exemplifica um layout construído em “%”. Veja que caso o usuário tenha a tela muito grande o texto ficará praticamente em apenas uma linha e quando diminuímos a tela o texto fica totalmente espremido na sidebar. Layouts Fluídos Híbridos Temos também os layouts fluídos híbridos onde seguem o mesmo padrão dos fluídos, porém com uma limitação de largura, nesse caso utilizamos o “max-width” e “min-width” assim conseguimos ter certo controle do layout. Para demonstrar como funciona o Fluído Híbrido, é aplicado um max-width de 960px e min-width de 600px no exemplo anterior. Para conferir na prática a diferença entre cada layout, na lista abaixo abaixo você pode acessar um exemplo de página para cada tipo layout. Apenas altere o zoom da página para testemunhar o efeito de cada layout em diferentes resoluções de tela. Página Responsiva; Página com layout Fluído; Página com layout Fluído Híbrido. Fonte: https://www.turbosite.com.br/blog/layout-fluido-ou-responsivo/
  2. Características de C# ausentes em Java C# inclui tipos mais primitivos e a funcionalidade para capturar exceções aritméticas. Inclui um grande número de conveniências de notação em Java, muitas das quais, como a sobrecarga do operador e os moldes definidos pelo usuário, já são familiares para a grande comunidade de programadores C++. O manuseio de eventos é um "cidadão de primeira classe"; É parte do próprio idioma. Permite a definição de "estruturas", que são semelhantes às classes, mas podem ser alocadas na pilha (ao contrário de instâncias de classes em C# e Java). O C# implementa propriedades como parte da sintaxe do idioma. C# permite que as instruções de troca funcionem em strings. C# permite métodos anônimos que fornecem funcionalidades de encerramento. C# permite iteradores que empregam co-rotinas através de uma palavra-chave de rendimento de estilo funcional. O C# possui suporte para parâmetros de saída, auxiliando no retorno de vários valores, caracterizado por C++ e SQL. C# tem a capacidade de alias namespaces. C# tem "Implementação de membro explícito" que permite que uma classe implemente especificamente métodos de uma interface, separada para seus próprios métodos de classe. Isso permite que ele também implemente duas interfaces diferentes que tenham um método do mesmo nome. Os métodos de uma interface não precisam ser "públicos"; Eles podem ser feitos para serem acessíveis somente através dessa interface. C# fornece integração com o COM. Seguindo o exemplo de C e C++, C# permite chamada por referência para tipos primitivos e de referência. Características de Java ausentes em C# Características de Java ausentes em C# A palavra-chave strictfp do Java garante que o resultado das operações de ponto flutuante permaneçam iguais em todas as plataformas. O Java suporta exceções verificadas para uma melhor aplicação da captura e tratamento de erros. Diferenças filosóficas entre as línguas Diferenças filosóficas entre as linguagens Não há tipos numéricos primitivos não assinados em Java. Embora seja universalmente acordado que a mistura de variáveis assinadas e não assinadas no código é ruim, a falta de suporte de Java para os tipos numéricos não assinados torna algo inadequado para a programação de baixo nível. C# não inclui exceções verificadas. Alguns argumentariam que as exceções verificadas são muito úteis para boas práticas de programação. Outros, incluindo Anders Hejlsberg, arquiteto principal de linguagem C#, argumentam que eles foram até certo ponto um experimento em Java e que eles não mostraram valer a pena [1] [2]. Os espaços de nome C# são mais parecidos com aqueles em C++. Ao contrário de Java, o namespace não especifica a localização do arquivo de origem. (Na verdade, não é estritamente necessário para um local de arquivo de origem Java para refletir sua estrutura de diretório de pacote). C# inclui delegados, enquanto Java não. Alguns argumentam que os delegados complicam o modelo de invocação do método, porque são manipulados através da reflexão, o que geralmente é lento. Por outro lado, eles podem simplificar o código removendo a necessidade de declarar novas classes (possivelmente anônimas) para se conectar aos eventos. Java exige que um nome de arquivo de origem deve corresponder à única classe pública dentro dele, enquanto C# permite múltiplas classes públicas no mesmo arquivo. C# permite o uso de ponteiros, que alguns designers de idiomas consideram inseguro, mas certos recursos de idioma tentam garantir que esta funcionalidade não seja usada incorretamente acidentalmente. Os ponteiros também complicam muito as tecnologias, como o RMI de Java (Remote Method Invocation), onde os objetos do programa residentes em um computador podem ser referenciados dentro de um programa executado em um computador completamente separado. Alguns especularam que a falta de ponteiros de memória em Java (substituído pela noção mais abstrata de referências de objetos) foi um aceno para a chegada da computação em grade, onde um único aplicativo pode ser distribuído em muitas peças físicas de hardware. O C# suporta a palavra-chave goto. Isso ocasionalmente pode ser útil, mas o uso de um método de fluxo de controle mais estruturado geralmente é recomendado. C# possui arrays multidimensionais verdadeiros, bem como a matriz de arrays que está disponível para Java (esse C# chama arrays irregulares). As matrizes multidimensionais são sempre rectangulares (no caso 2D ou análises para mais dimensões), enquanto uma matriz de arrays pode armazenar linhas (novamente no caso 2D) de comprimentos variáveis. Arrays rectangulares podem acelerar o acesso se a memória for um gargalo (há apenas uma referência de memória em vez de duas, este benefício é muito dependente do comportamento do cache), enquanto as matrizes irregulares economizam memória se não estiver cheia, mas custam (na penalidade de um ponteiro por linha ) Se for. Arrays retangulares também evitam a necessidade de alocar memória para cada linha de forma explícita. O Java não inclui a sobrecarga do operador, porque o abuso da sobrecarga do operador pode levar a um código que é mais difícil de entender e depurar. C# permite a sobrecarga do operador, que, quando usado com cuidado, pode tornar o código mais fácil e legível. A falta de sobrecarga de Java torna um pouco inadequado para certos programas matemáticos. Por outro lado, os tipos numéricos do .NET não compartilham uma interface ou superclasse comum com som, restrição e assim por diante, restringindo a flexibilidade das bibliotecas numéricas. Os métodos em C# não são virtuais por padrão. Em Java no entanto, os métodos são virtuais por padrão. Os métodos virtuais garantem que o método mais substituído de um objeto será chamado que é determinado pelo tempo de execução. Você sempre precisa ter isso em mente ao ligar ou escrever qualquer método virtual! Se o método for declarado como não virtual, o método a invocar será determinado pelo compilador. Esta é uma grande diferença de filosofia entre os designers das plataformas Java e .NET. Genéricos do Java 1.5 usam o tipo de apagamento. A informação sobre os tipos genéricos é perdida quando a origem Java é compilada para bytecode. Os genéricos do .NET 2.0 são preservados após a compilação devido ao suporte de genéricos começando na versão 2.0 do .NET Common Language Runtime (CLR). A abordagem de Java permite que os binários Java 1.5 sejam executados no 1.4 JRE, ao custo de verificações de tempo de execução adicionais. C# é definido pelos padrões ECMA e ISO, enquanto o Java é proprietário, embora largamente controlado através de um processo aberto da comunidade. A API C# é completamente controlada pela Microsoft, enquanto que a API Java é gerenciada através de um processo aberto da comunidade. O tempo de execução do .NET permite o código gerenciado e não gerenciado, permitindo certas classes de erros que não existem no ambiente de código gerenciado puro do Java, mas também permitem a interface com o código existente.
  3. [CENTER][SIZE=6][B]O que é Spring MVC?[/B][/SIZE] Gostaria de facilidade e flexibilidade para trabalhar com requisições web? O [B]Spring MVC[/B] é a ferramenta que dá isso para você! Hoje é difícil conceber uma aplicação sem a parte web, concorda? Além das numerosas aplicações web, a maioria dos aplicativos móveis (para Android e iOS, por exemplo) precisam de uma APIs RESTful para consumir. Por isso, conhecer um framework que ajuda nesse trabalho [B]é vantajoso para qualquer programador[/B]. Essa é a ideia de agora: explicar como o Spring MVC funciona. Continue lendo para [B]aprender sobre[/B]: [LIST] [*]O que é Spring MVC? [*]Criação de controladores web [*]Novas anotações de mapeamento [*]Recebendo dados de um formulário [*]Enviando dados para a página [*]Como configurar o ViewResolver [*]Como usar o Spring MVC para criar uma API RESTful [/LIST] “Vambora”!? [SIZE=5][B]O que é Spring MVC?[/B][/SIZE] O Spring MVC é um framework que ajuda no desenvolvimento de aplicações web. Com ele nós conseguimos construir [B]aplicações web robustas e flexíveis[/B]. Ele já tem todas as funcionalidades que precisamos para (1) atender as requisições HTTP, (2) delegar responsabilidades de processamento de dados para outros componentes e (3) preparar a resposta que precisa ser dada. É uma excelente implementação do [B]padrão MVC[/B]. MVC é acrônimo de Model, View e Controller, e é bacana entender o papel de cada um deles dentro do sistema. Esse entendimento vai te ajudar a trabalhar com Spring MVC de forma a construir aplicações mais organizadas e de fácil manutenção. Vamos começar com a imagem abaixo que representa o fluxo de uma requisição do ponto de vista do Spring MVC: [URL='http://s3.amazonaws.com/algaworks-blog/wp-content/uploads/Fluxo-do-Spring-MVC.png'][IMG]http://s3.amazonaws.com/algaworks-blog/wp-content/uploads/Fluxo-do-Spring-MVC.png[/IMG][/URL] Detalhadamente, os passos mostrados na imagem acima, são: 1. Acessamos uma URL no browser que envia a requisição HTTP para o servidor que roda a aplicação web com Spring MVC. Perceba que quem recebe a requisição é o controlador do framework, o Spring MVC. 2. O controlador do framework irá procurar qual classe é responsável por tratar essa requisição, entregando a ela os dados enviados pelo browser. Essa classe faz o papel do controller. 3. O controller passa os dados para o model, que por sua vez executa todas as regras de negócio, como cálculos, validações e acesso ao banco de dados. 4. O resultado das operações realizadas pelo model é retornado ao controller. 5. O controller retorna o nome da view, junto com os dados que ela precisa para renderizar a página. 6. O Framework encontra a view que processa os dados, transformando o resultado em um HTML. 7. Finalmente, o HTML é retornado ao browser do usuário. Na prática, o [I]controller[/I] é a classe Java com os métodos que tratam essas requisições. Portanto, tem acesso a toda informação relacionada a ela como parâmetros da URL, dados submetidos através de um formulário, cabeçalhos HTTP, etc. Veja um exemplo simples: [CODE]@Controller public class HomeController { @RequestMapping("/") public String index() { return "index.jsp"; } }[/CODE] O método index() atende a requisição para / (que é a raiz da aplicação) e devolve a página index.jsp na resposta. Fique tranquilo, ainda veremos mais detalhes. O [I]model[/I] seria algo como as famosas classes de serviços, repositórios e as entidades de banco de dados. Um pequeno exemplo poderia ser: [CODE]@Autowired private Funcionarios funcionarios; // <<< Nosso repositório. @RequestMapping(method = RequestMethod.GET) public ModelAndView listar() { ModelAndView modelAndView = new ModelAndView("funcionario-lista.jsp"); modelAndView.addObject("funcionarios", funcionarios.findAll()); return modelAndView; }[/CODE] Não se assuste. Olhe o código acima com calma e no decorrer da nossa conversa isso ficará mais claro. Por ora, veja nosso [I]model[/I] entrando em ação nas linhas 2 e 7. Por fim temos nossa [I]view[/I]. Essa dispensa exemplos aqui, pois, são nossas páginas JSP que irão tornar-se em HTML para chegar aos usuários. [SIZE=5][B]Criação de controladores web[/B] [B][/B][/SIZE] Agora nós vamos estudar as opções que temos para criar e configurar nossos controladores. Contudo, vamos precisar de uma aplicação já configurada com o [URL='http://projects.spring.io/spring-framework/']Spring Framework[/URL]. Você pode escolher dentre duas opções na hora de configurar. A primeira opção é utilizar a configuração de um projeto web comum. Um exemplo disso será o [URL='http://github.com/algaworks/artigo-spring-mvc']código fonte que irei disponibilizar para você[/URL]. Você vai observar o pacote com.algaworks.mvc. Nele tem as classes de configuração que criei. Em especial, veja as classes SpringWebInitializer e WebConfig, pois, elas representam o mínimo para o Spring MVC funcionar. Não deixe de olhar também o pom.xml. De qualquer forma vou deixar aqui o mínimo de dependências para trabalhar com Spring MVC: [CODE]<dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>4.3.4.RELEASE</version> </dependency> <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>3.1.0</version> <scope>provided</scope> </dependency> <dependency> <groupId>javax.servlet</groupId> <artifactId>jstl</artifactId> <version>1.2</version> </dependency>[/CODE] A segunda é criar uma aplicação com o Spring Boot. Com o projeto configurado, podemos continuar. ;) A primeira coisa é criar uma classe comum e anotá-la com @controller. Essa anotação fará com que o Spring reconheça a classe como um controlador. Depois disso criamos nossas ações. Elas são métodos Java comuns que, através de anotações, serão configuradas para responder as requisições web. [CODE]@Controller @RequestMapping("/funcionarios") public class FuncionariosController { @Autowired private Funcionarios funcionarios; @RequestMapping(method = RequestMethod.GET) public ModelAndView listar() { ModelAndView modelAndView = new ModelAndView("funcionario-lista.jsp"); modelAndView.addObject("funcionarios", funcionarios.findAll()); return modelAndView; } }[/CODE] Vamos começar a analisar o código acima linha a linha, mais especialmente a ação listar(), para entendermos tudo isso melhor: Na primeira linha temos, como já falamos, a anotação que torna nossa classe um controlador. A segunda linha, com a anotação @RequestMapping, configura qual o [I]path[/I] inicial para todas as ações do nosso controlador. Já nas linhas 5 e 6 vemos nossa propriedade funcionarios, referente ao nosso repositório, anotada com @Autowired e, portanto, será injetada pelo Spring Framework. Nós temos aqui, no blog, um artigo sobre injeção de dependências para quem quiser saber mais sobre o assunto. Essa parte não é diretamente relacionada ao Spring MVC. Pulando para a linha 8, vemos novamente a anotação @RequestMapping que está especificando como será a requisição que a ação listar() vai atender. [CODE]@RequestMapping(method = RequestMethod.GET)[/CODE] A primeira coisa a se observar é que a propriedade method da nossa anotação está especificando um método HTTP que é o GET, ou seja, para a ação atender a requisição, a mesma deve ser do tipo GET. A propriedade method pode ser omitida. Se assim fosse, a ação passaria a responder a todos os métodos HTTP (GET, POST, PUT, DELETE, etc.). Veja também que a anotação não tem um [I]path[/I] configurado. Isso quer dizer que o método listar() é a ação padrão do nosso controlador e vai responder para uma requisição do tipo GET com o [I]path[/I] /funcionarios. Para configurar um, poderíamos utilizar as propriedades value ou path da anotação: [CODE]@RequestMapping(method = RequestMethod.GET, path = "/lista")[/CODE] Agora o mais importante: nossa ação que começa na linha 9: [CODE]public ModelAndView listar() { ModelAndView modelAndView = new ModelAndView("funcionario-lista.jsp"); modelAndView.addObject("funcionarios", funcionarios.findAll()); return modelAndView; }[/CODE] Ela começa instanciando a classe ModelAndView. Essa classe foi utilizada para especificar a [I]view[/I] que será renderizada para o usuário final e para informarmos quais os dados ela utilizará para isso. Repare que no construtor temos a nossa página funcionario-lista.jsp e o método addObject é utilizado para adicionarmos uma lista de objetos que serão exibidos por ela. Por fim, o objeto do tipo é ModelAndView retornado. Você pode implementar essa ação de outra maneira se quiser. Veja uma alternativa: [CODE]public String lista(Model model) { model.addAttribute("funcionarios", funcionarios.findAll()); return "funcionario-lista.jsp"; }[/CODE] Neste caso, recebemos a interface Model como parâmetro (ela é passada pelo Spring MVC) e utilizamos o método addAttribute para adicionar nossa lista de objetos. A página foi, simplesmente, colocada como retorno. [SIZE=5][B]Recebendo dados de um formulário[/B][/SIZE] Vou te mostrar agora como fazer com que os dados de um formulário cheguem até a ação do nosso controlador. Preparei um formulário, para cadastro de funcionários, e a ação que receberá essa submissão. Como temos uma classe importante envolvida, que é a classe Funcionario, então quero mostrá-la pra você. São os dados dela que serão submetidos pelo formulário e recebidos pela ação: [CODE]public class Funcionario { private Long id; private String nome; private String cpf; //getters e setter omitidos }[/CODE] Agora tenho aqui o formulário construído em duas versões. Uma com as tags do Spring: [CODE]Formulário de cadastroXHTML <s:url value="/funcionarios/salvar" var="acao" /> <sf:form method="post" modelAttribute="funcionario" action="${acao}"> <div> <label for="nome">Nome:</label> <sf:input path="nome" /> </div> <div> <label for="cpf">CPF:</label> <sf:input path="cpf" /> </div> <button type="submit">Salvar</button> </sf:form> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 <s:url value="/funcionarios/salvar" var="acao" /> <sf:form method="post" modelAttribute="funcionario" action="${acao}"> <div> <label for="nome">Nome:</label> <sf:input path="nome" /> </div> <div> <label for="cpf">CPF:</label> <sf:input path="cpf" /> </div> <button type="submit">Salvar</button> </sf:form> [/CODE] E outra, para quem preferir, em HTML puro: [CODE]<form id="funcionario" action="/app/funcionarios/salvar" method="post"> <div> <label for="nome">Nome:</label> <input id="nome" name="nome" type="text"/> </div> <div> <label for="cpf">CPF:</label> <input id="cpf" name="cpf" type="text"/> </div> <button type="submit">Salvar</button> </form>[/CODE] A vantagem do formulário com as tags Spring é que ele já irá exibir as informações do funcionário caso elas já venham preenchidas. Isso é útil no caso de edição de registros. Já a ação para capturar os dados, referentes a submissão desse formulário, fica assim: [CODE]@Controller @RequestMapping("/funcionarios") public class FuncionariosController { @Autowired private FuncionarioService funcionarioService; @RequestMapping(method = RequestMethod.POST, path = "/salvar") public RedirectView salvar( Funcionario funcionario, RedirectAttributes redirectAttributes) { funcionarioService.salvar(funcionario); redirectAttributes.addFlashAttribute( "mensagem", "Cadastro feito com sucesso!"); return new RedirectView("/funcionarios", true); } }[/CODE] Da forma como fizemos com a ação listar(), deixa eu mostrar agora a ação salvar(). Nossa ação está recebendo dois parâmetros sendo que o primeiro – do tipo Funcionario – será preenchido com os dados que virão do formulário e o segundo – do tipo RedirectAttributes – utilizaremos para incluir o atributo com a mensagem que será exibida após o redirecionamento. Com nossa instância do tipo Funcionario preenchida podemos manipulá-la como quisermos. No caso, simplesmente, salvamos ela: [CODE]funcionarioService.salvar(funcionario);[/CODE] Como já dei a entender, não será renderizada uma página após essa ação, será feito um redirecionamento. Para isso, foi utilizado um objeto do tipo RedirectView. [CODE]new RedirectView("/funcionarios", true);[/CODE] O primeiro argumento do construtor desse objeto é a URL, ou [I]path[/I] de destino e o segundo é somente para quando utilizamos um [I]path[/I]. Passando true, a classe entende que é para incluir o contexto de nossa aplicação ao [I]path[/I] informado. O resultado seria algo como: [URL]http://localhost:8080/app/funcionarios[/URL]. Acima mostrei o formulário e a ação que recebe os dados, mas qual ação criar para imprimir o formulário para o usuário? Pode usar essa daqui: [CODE]@RequestMapping(method = RequestMethod.GET, path = "/novo") public ModelAndView novo() { ModelAndView modelAndView = new ModelAndView("funcionario-formulario.jsp"); modelAndView.addObject("funcionario", new Funcionario()); return modelAndView; }[/CODE] E, se o seu formulário for em HTML puro, pode trocar por essa: [CODE]@RequestMapping(method = RequestMethod.GET, path = "/novo") public String novo() { return "funcionario-formulario.jsp"; }[/CODE] [SIZE=5][B]Enviando dados para a página[/B][/SIZE] Como já sabemos receber dados de um formulário, vamos entender como enviar dados para as nossas páginas. Na verdade, a gente já fez isso quando utilizamos os métodos addAttribute da interface Model, addObject da classe ModelAndView e até no método addFlashAttribute da classe RedirectAttributes. Mas agora quero fazer isso formalmente simulando a função de edição. Aqui o formulário construído com as tags do Spring MVC é importante, pois, já vai mostrar os dados do objeto que a gente passar para ser utilizado na nossa [I]view[/I]. Quanto ao formulário, ele teve uma leve mudança para incluir também o campo [I]hidden[/I] que irá armazenar o identificador do funcionário (veja linha 8): [CODE]<s:url value="/funcionarios/salvar" var="acao" /> <sf:form method="post" modelAttribute="funcionario" action="${acao}"> <c:if test="${not empty funcionario.id}"> <div> <label>Código:</label> <p>${funcionario.id}</p> <sf:hidden path="id" /> </div> </c:if> <div> <label for="nome">Nome:</label> <sf:input path="nome" /> </div> <div> <label for="cpf">CPF:</label> <sf:input path="cpf" /> </div> <button type="submit">Salvar</button> </sf:form>[/CODE] Repare que a ação que o formulário acima vai chamar, ao ser submetido, continua sendo a mesma que apresentei pra você antes, ou seja, a ação salvar(). Isso não vai mudar. Agora vou mostrar a ação edicao() que vai ser chamada para abrir esse formulário. Ela é praticamente igual a ação novo() que já vimos também. Olhe só: [CODE]@RequestMapping(method = RequestMethod.GET, path = "/edicao") public ModelAndView edicao(@RequestParam Long id) { ModelAndView modelAndView = new ModelAndView("funcionario-formulario.jsp"); modelAndView.addObject("funcionario", funcionarios.findOne(id)); return modelAndView; }[/CODE] Basta invocarmos essa ação passando o identificador do funcionário que queremos editar para que ele faça a pesquisa do mesmo e devolva para nossa [I]view[/I] preparar o formulário que será enviado ao [I]browser[/I]. Um exemplo de URL para invocação seria: [URL]http://localhost:8080/app/funcionarios/edicao?id=1[/URL]. A única coisa de novo que a nova ação tem é a anotação @RequestParam. Como podemos ver, ela nos ajuda a ter acesso aos parâmetros da requisição de uma maneira mais simples. Uma observação aqui é que, se o parâmetro que vem pela URL for diferente do parâmetro da ação, então é preciso especificá-lo: [CODE]public ModelAndView edicao(@RequestParam("id") Long funcionario) { ... }[/CODE] Outra forma para anotar nosso método que deixaria a URL da página mais elegante, seria essa aqui: [CODE]@RequestMapping(method = RequestMethod.GET, path = "/{id}/edicao") public ModelAndView edicao(@PathVariable Long id) { ... }[/CODE] Não coloquei a implementação do método acima, pois, ela não se altera. O que muda é a URL para invocar a ação com esse novo mapeamento: [URL]http://localhost:8080/app/funcionarios/1/edicao[/URL]. Quanto a anotação @PathVariable, veremos ela ainda mais uma vez. Tem mais uma questão que envolve esse tópico aqui como um todo que é o seguinte: O Spring MVC é um framework [I]action-based[/I] e isso é pelo fato da própria ação enviar os dados para serem utilizados na página. Como fizemos aqui, enviando o objeto Funcionariopara ser editado. A ação recebe a requisição e ela mesma já trata de disponibilizar a informação (que seriam os objetos Java) que vai dinamizar as páginas que serão exibidas para o usuário final. [SIZE=5][B]Novas anotações de mapeamento[/B][/SIZE] A partir de versão 4.3.X do Spring Framework já temos disponíveis as seguintes anotações: [LIST] [*]@GetMapping [*]@PostMapping [*]@PutMapping [*]@DeleteMapping [*]@PatchMapping [/LIST] Podemos utilizá-las como alternativa a anotação @RequestMapping. Ao invés de utilizar assim: [CODE]@RequestMapping(method = RequestMethod.GET, path = "/novo")[/CODE] Usamos assim: [CODE]@GetMapping("/novo")[/CODE] É melhor porque além de não termos de configurar a propriedade method, melhora também a semântica dos nossos controladores. Veja como nosso controlador fica melhor com essas anotações: [CODE]@RequestMapping("/funcionarios") public class FuncionariosController { ... @GetMapping public ModelAndView listar() { ... } @GetMapping("/novo") public ModelAndView novo() { ... } @GetMapping("/edicao") public ModelAndView edicao(@RequestParam Long id) { ... } @PostMapping("/salvar") public RedirectView salvar(Funcionario funcionario, RedirectAttributes redirectAttributes) { ... } }[/CODE] [SIZE=5][B]Como configurar o ViewResolver[/B][/SIZE] ViewResolver é uma interface que ajuda o Spring MVC a encontrar as páginas que são retornadas por nossas ações. Para o código-fonte de exemplo que estou utilizando aqui (e irei disponibilizar para você) eu utilizei uma configuração diferente da padrão. A resolução padrão das páginas é feita em conjunto com a URL da requisição. No caso de, por exemplo, utilizarmos a URL [URL]http://localhost:8080/app/funcionarios/novo[/URL] para invocar nossa ação novo(): [CODE]@GetMapping("/novo") public String novo() { return "funcionario-formulario.jsp"; }[/CODE] Então, o Spring MVC iria procurar pela página funcionario-formulario.jsp em um diretório da nossa aplicação web chamada “funcionarios”. A configuração que utilizei é um pouco diferente. Foi estipulado a pasta “/WEB-INF/paginas/” para ser o diretório raiz de nossas páginas. Se quiséssemos um subdiretório com o nome “funcionarios”, teríamos que fazer o seguinte: [CODE]@GetMapping("/novo") public String novo() { return "funcionarios/funcionario-formulario.jsp"; }[/CODE] Assim o Spring MVC vai procurar nosso arquivo dentro da pasta “/WEB-INF/paginas/funcionarios/”. A configuração foi feita através do Java. Veja como ficou: [CODE]@Configuration public class ViewResolverConfig { @Bean public ViewResolver internalResourceViewResolver(){ InternalResourceViewResolver viewResolver = new InternalResourceViewResolver(); viewResolver.setViewClass(JstlView.class); viewResolver.setPrefix("/WEB-INF/paginas/"); viewResolver.setViewNames(new String[] {"*.jsp"}); return viewResolver; } }[/CODE] [SIZE=5][B]Como usar o Spring MVC para criar uma API RESTful[/B][/SIZE] Quero terminar falando um pouco sobre os recursos que temos no Spring MVC para criarmos APIs RESTful. Mas não quero aqui falar sobre arquitetura e nem de boas práticas de APIs RESTful. Vou, simplesmente, mostrar o caminho de como fazer isso, beleza? Imagine que você precise retornar todos os funcionários da sua base no formado JSON. Olhe só como ficaria: [CODE]@Controller @RequestMapping("/funcionarios") public class FuncionariosController { ... @ResponseBody @GetMapping("/todos") public List<Funcionario> todos() { return funcionarios.findAll(); } }[/CODE] Veja que já devolvemos a lista de funcionários diretamente. Isso é porque estamos utilizando a anotação @ResponseBody. Ela diz ao Spring MVC para jogar o retorno do método na resposta. E antes de fazer uma requisição para nossa nova ação, que vai retornar a resposta em JSON, não podemos esquecer de adicionar a seguinte dependência em nosso pom.xml: [CODE]<dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> <version>2.8.5</version> </dependency>[/CODE] Aqueles que optaram por uma configuração com o Spring Boot, não precisaram adicionar a dependência acima, pois, ele já faz isso por você. Agora sim podemos fazer uma requisição para [URL]http://localhost:8080/app/funcionarios/todos[/URL]. Teríamos um JSON de retorno com os funcionários parecido com este: [CODE][ { "id": 1, "nome": "João", "cpf": "11111111111" }, { "id": 2, "nome": "Maria", "cpf": "11111111112" }, { "id": 3, "nome": "Mateus", "cpf": "11111111113" } ][/CODE] Melhor ainda se criarmos um novo controlador e, ao invés de anotá-lo com @controller, usarmos @RestController. Veja como ficaria: [CODE]@RestController @RequestMapping("/api/funcionarios") public class FuncionariosResource { @Autowired private Funcionarios funcionarios; @GetMapping public List<Funcionario> todos() { return funcionarios.findAll(); } }[/CODE] A URL para invocar a ação todos(), nesse novo controlador, fica assim agora: [URL]http://localhost:8080/app/api/funcionarios[/URL]. Repare que, como estamos utilizando a anotação @RestController, nosso método não precisou da anotação @ResponseBody. Para o caso da construção de APIs, essa última opção com @RestController, fica mais elegante. :) Vamos a um último exemplo para utilizarmos, mais uma vez, a anotação @PathVariable. Essa é uma anotação que serve para pegarmos informações do [I]path[/I] da nossa ação [CODE]@RestController @RequestMapping("/api/funcionarios") public class FuncionariosResource { @Autowired private Funcionarios funcionarios; @GetMapping("/{id}") public Funcionario buscar(@PathVariable Long id) { return funcionarios.findOne(id); } }[/CODE] O que vai acontecer agora com nossa ação buscar() é que, quando fizermos uma requisição para [URL]http://localhost:8080/app/api/funcionarios/1[/URL] o parâmetro id, especificado na anotação @GetMapping, será passado para nossa ação. Veja o resultado dessa última requisição: [CODE]{"id":1,"nome":"João","cpf":"11111111111"}[/CODE] [SIZE=5][B]Conclusão: Spring MVC é um framework web cheio de recursos[/B][/SIZE] Espero ter passado a você um boa impressão do Spring MVC, pois, é um excelente framework web, cheio de recursos. Vimos aqui a estrutura de um controlador e como configurar nossas ações. Depois mostrei as novas anotações de mapeamento para as ações. Ensinei como customizar a configuração do ViewController. Expliquei como receber dados de um formulário e como enviar objetos para serem utilizados em nossas páginas JSP. Por último, vimos como utilizar o Spring MVC para construir uma API RESTful. Espero que tenha gostado. ;) [SPOILER="Fonte:"] [URL]http://blog.algaworks.com/spring-mvc/[/URL] [/SPOILER] [/CENTER]
  4. Cada atleta deve transar seis vezes por dia nos Jogos A pegação nas vilas olímpicas costuma ser homérica. E ajuda a explicar como funciona o corpo e a mente dos atletas de ponta. (POR: Alexandre Versignassi - ATUALIZADO EM: 29/07/2016) Três jogadoras do time sueco de handball perguntaram ao técnico de Usain Bolt, nas olimpíadas de 2008: "Tudo bem a gente entrar no quarto do velocista para dar parabéns pelo ouro dele nos 100 metros?". O treinador liberou. E os cumprimentos das suecas ao jamaicano estenderam-se por uma hora e meia, entre quatro paredes e uma porta fechada. E não teve nada demais. Nos jogos, o sexo livre é a regra, não a excessão. Não que todos tratem a Vila Olímpica como uma versão extendida e sem cortes de American Pie. Não. Os que caem na farra são "só" "uns 70%, 75% dos atletas", disse o nadador americano Ryan Lochte, ouro nos 400 metros medley em Londres numa entrevista para a ESPN. Hope Solo, goleira do futebol feminino americano, concorda: "Se você não tem disciplina, a vila pode ser uma baita distração", disse. Disciplina à parte, Hope mesmo disse que já deu seus pulos. Mas nem por isso a rival da brasileira Marta se deixou distrair tanto assim. Seus dois ouros, em Pequim e Londres, estão de prova. Atletas de ponta, afinal, podem ser jovens, bonitos, extremamente saudáveis e estarem no pico da atividade sexual, mas não rasgam medalha. Tanto que a esbórnia só come solta para valer mais para o final dos jogos, quando o trabalho já acabou para a maior dos olímpicos. Aí ninguém mais segura. Que o dia Josh Lakatos, do time de tiro ao alvo dos EUA. Quando sua equipe foi eliminada, os chefes da delegação americana pediram de volta as chaves do alojamento em que o time estava (uma casa de três andares, na vila olímpica de Sydney). Lakatos devolveu. Mas não quis nem saber. Veterano de Sydney, ele já tinha plena consciência de a vila se transformaria numa balada daquelas de fazer Calígula corar. Para não perder a festa, então, arrombou a porta da casa. E o lugar virou um porto-seguro para a prática do esporte mais antigo do mundo. "Virei um gerente de motel", brincou Lakatos, também para a ESPN. "Nunca vi tanta sacanagem na minha vida!". E ele nem precisava ter "gerenciado" um ninho de amor para ter visto tudo isso. Há relatos de sexo ao ar livre, já que nem todos os casais (ou trios, ou quartetos) consegue achar um abrigo discreto como o de Lakatos. Por essas, o Comitê Olímpico está distribuindo toneladas de camisinhas na vila olímpica, como já comentamos aqui. Serão 450 mil preservativos. Dá mais ou menos 45 por atleta. Três por dia de competição. Levando em conta que cada dupla olímpica só precisa de uma camisinha a cada round, a média de relações sexuais esperada pelo Comitê é de seis por pessoa a cada dia de competição. Mais: como um quarto dos atletas tende a não entrar na brincadeira, os 75% sexualmente ativos da vila devem superar essa marca sem grandes esforços. De onde vem tanto fogo? Para começar, a quantidade de energia que um atleta de ponta tem estacada em suas células é inimaginável para gente como a gente. O consumo médio de calorias na vila olímpica, para você ter uma ideia, é de 9 mil por atleta - com alguns chegando a 15 mil (coisa que um humano comum leva quase uma semana para consumir). Tudo isso sem treinar tanto, porque eles precisam estar no ápice enérgico para as provas. Você talvez dormisse por três dias se colocassse 10 mil calorias para dentro em 24 horas. Os atletas não: seus corpos são usinas de processamento de energia, e as calorias, combustível de alta octanagem. Some isso ao fato de todos estão confinados num espaço pequeno, e que as roupas de treino não são exatamente batinas de padre nem hábitos de freira, e pronto. Basta qualquer fagulha para que a vila entre em combustão sexual. Mas não é só o corpo dos olímpicos que explica esse fogo. É a cabeça deles também. O cérebro de um atleta de ponta é tão diferente do nosso quanto a musculatura. "Atletas são éxtremistas?. Quando treinam, têm um foco de raio laser. Quando saem para uma cerveja, são 20 cervejas...", explica Hope Solo, a morena de olhos azuis da foto ali em cima, e que acaba de desembarcar no Rio. É isso. A intensidade da mente e dos corpos dos poucos humanos capazes de disputar uma olimpíada rende performances memoráveis, mas boa parte delas ocorre bem longe dos nossos olhos.
  5. Uma visão econômica da religião POR BERNARDO GUIMARÃES Religião é um assunto que envolve muitos aspectos diferentes. Esse post busca passar uma das visões econômicas da religião. Vivendo em sociedade, frequentemente temos que escolher entre “cooperar, fazer o certo” e “trapacear, levar vantagem”. Por exemplo, pessoas envolvidas em um negócio frequentemente tem a chance de roubar um pouco dos ganhos da outra (“trapacear”), com baixa chance disso despertar suspeitas. Ou, considere duas pessoas de uma comunidade primitiva caçando ou lutando em guerra contra um inimigo. Se um é ferido, o outro pode ajudá-lo (“cooperar”), ainda que isso implique riscos para si mesmo, ou pode abandonar o parceiro (“trapacear”). De modo geral, as pessoas de um grupo estarão melhor se todos cooperarem, se ninguém trapacear. Isso possibilitará mais negócios (pois uma confia na outra), mais empenho nas batalhas (pois um sabe que o outro tentará socorrê-lo, se preciso for), etc. Contudo, para um indivíduo pensando apenas em si mesmo, com frequência o melhor será “trapacear, levar vantagem”. Além disso, cooperar é ainda mais custoso se o outro não coopera. O indivíduo que age de boa fé com um membro da comunidade que quer roubá-lo é o que mais tem a perder. Em suma, apesar de “cooperar” ser o melhor para a comunidade, os indivíduos estarão tentados a “trapacear” com frequência. Essa perda de confiança nos outros afeta as decisões de cada um: há menos negócios, batalhas e caçadas. Isso afeta negativamente o grupo. Essa exposição pode passar a ideia de uma visão simplista da humanidade, sem espaço para qualquer outro senso de moralidade. Não é isso. O ponto é que induzir mais cooperação entre as pessoas nos negócios e nas batalhas contra outros grupos traz vantagens para a comunidade. Agora, entra a religião. Suponha que exista nesse mundo a seguinte crença: se você trapacear, uma força superior lhe punirá; se você cooperar, uma força superior lhe recompensará. As punições e recompensas ocorrerão na vida que começa depois da morte. Digamos que essa crença seja parte de um conjunto de crenças, chamada de “religião”. Essa crença tem o poder de induzir os indivíduos a cooperarem, mesmo quando seria possível roubar sem o parceiro perceber, abandonar o amigo ferido ou fugir da batalha. Para o grupo como um todo, isso traz muitas vantagens no longo prazo. Há, porém, uma questão: como eu vou saber que meu parceiro também vai cooperar comigo e, portanto, vale a pena cooperar? Bem, ele vai cooperar comigo se acredita que será recompensado se assim o fizer, ou seja, se ele acreditar na religião. Mas como eu sei que ele acredita na religião? Suponha que, de acordo com a religião, as forças superiores que recompensam as boas ações também punem quem não obedece o jejum em determinadas épocas do ano, as mulheres que cortam cabelos ou as pessoas que não oferecem seus serviços ou doações aos templos. Quem acredita na religião estará disposto a esses sacrifícios e privações e, com frequência, estará feliz de seguir as instruções e participar dos rituais, pois estará agradando às forças superiores. Esses custosos rituais mostram que uma pessoa envolvida acredita que será punida se não cooperar com seu grupo. Assim, para os outros que também acreditam na religião, vale a pena cooperar com ela. Como consequência, o grupo todo fica melhor, apesar dos custos (se esses não forem altos demais). O que emerge dessa análise é o seguinte: (1) A crença em uma força superior que recompensa os humanos por boas ações e pune as más ações pode trazer benefícios para a comunidade por si só (independentemente da existência ou não das punições depois da morte). (2) Faz todo sentido que essa crença exija rituais custosos, pois isso permite às pessoas mostrarem aos outros que acreditam no conjunto de crenças (“a religião”) e, portanto, que vão cooperar. Assim, faz sentido cooperar com elas. Uma implicação desse argumento é que não é nada surpreendente que a religião seja um componente importante da grande maioria das sociedades que prosperaram. Cooperar, em geral, é algo muito bom. Entretanto, em muitos casos importantes, “cooperar” pode significar arriscar a vida na guerra. O grupo que tem indivíduos dispostos a morrer pela vitória na batalha vai ter mais chances de vencer guerras e, portanto, conquistar territórios e prosperar. De acordo com essa lógica, não é nada estranho que a religião seja, ao mesmo tempo, fonte de crenças que nos levam a cuidar do próximo, mas também fonte de crenças que nos levam a matar quem enxergamos como inimigo. Referências: – Implicações dessa visão econômica da religião são estudadas, por exemplo, em artigos recentes de Gilat Levy e Ronny Razin, como: “Religious Beliefs, Religious Participation and Cooperation”, American Economic Journal: Microeconomics, 2012; “Rituals or Good Works: Social Signalling in Religious Organizations”, Journal of European Economic Association, 2014.
×
×
  • Create New...