JQUERY COM EVENTO ASP.NET
Galera, tenho experiência com Windows Form, e agora estou começando a aprender ASP.NET. Estou apanhando muuuito. Ajax, JQuery.. isso é tudo muito novo pra mim.
Espero que possam me ajudar.
Eu criei um WebUserControl chamado userControlFormacaoProfissional. Nele, eu criei um evento chamado Remover. Está tudo funcionando legal na parte do Code Behind, tá disparando tudo certinho.
Só que eu queria associar um código JQuery à esse evento. Ou seja, quando o evento disparar, eu queria que executasse um script.
O problema é que JQuery roda no cliente, meu evento roda no servidor. Ou seja, a JQuery não enxerga meu evento.
Tentei assim:
<script type=[Ô]text/javascript[Ô]>
$(function ()
{
$([Ô]#UserControlFormacaoProfissional1[Ô]).on([Ô]Remover[Ô])(function ()
{
alert([Ô]teste[Ô]);
});
});
</script>
Mas pelos motivos já citados, não funcionou.
Alguém pode me dar o caminho das pedras? Se falei alguma besteira, me desculpem... realmente essa parte WEB é bem nova pra mim...
Obrigado!
Espero que possam me ajudar.
Eu criei um WebUserControl chamado userControlFormacaoProfissional. Nele, eu criei um evento chamado Remover. Está tudo funcionando legal na parte do Code Behind, tá disparando tudo certinho.
Só que eu queria associar um código JQuery à esse evento. Ou seja, quando o evento disparar, eu queria que executasse um script.
O problema é que JQuery roda no cliente, meu evento roda no servidor. Ou seja, a JQuery não enxerga meu evento.
Tentei assim:
<script type=[Ô]text/javascript[Ô]>
$(function ()
{
$([Ô]#UserControlFormacaoProfissional1[Ô]).on([Ô]Remover[Ô])(function ()
{
alert([Ô]teste[Ô]);
});
});
</script>
Mas pelos motivos já citados, não funcionou.
Alguém pode me dar o caminho das pedras? Se falei alguma besteira, me desculpem... realmente essa parte WEB é bem nova pra mim...
Obrigado!
Em primeiro lugar, parabéns por estar se aventurando em páginas Web! No que precisar pode contar comigo!
Você já de cara encontrou um dos maiores dilemas para quem usa ASP.NET. UserControl pode parecer bastante útil, mas por experiência própria, já te advirto que não são fáceis de se trabalhar. Por causa de um pequeno detalhe: Ao renderizar(o que ocorre no server), o Id dele é modificado para um nome meio que randômico, basicamente é o mesmo id que você usa, mas pode sempre contém alguma adição por parte do server. Para se pegar esse nome, se usa a propriedade ClientId, assim:
Onde usrControl é o nome que você usou ao colocar o controle em algum container. Repare nisso da seguinte forma:
1 - Carregue a página normalmente.
2 - Abra o código fonte dela, geralmente CTRL+U
3 - Procure o componente e veja que o ID não é o mesmo que você colocou ao colocar o controle.
Por experiência, posso garantir que controles ASP.NET são um verdadeiro pé no saco. Eles são difÃceis com essa parte, quando se quer integrar com JQuery, AngularJS BootStrap ou algum outro framework. Um conselho que posso te dar quanto à isso é: Faça WebAPI para servir de fonte de dados e utilize apenas HTML + CSS + Javascript para a interface. é muito mais leve, simples e sem mistério. Se você utilizar JQuery, AngularJS, BootStrap ou outros frameworks, você vai ter um resultado muito melhor, além de uma flexibilidade de controles muito maior. Existem vários frameworks de componentes muito bons que fazem um uso muito eficiente do JQuery e do AngularJS, como por exemplo, o jQuery EasyUI, regido pela licença GNU(gratuito, desde que se mencione o seu uso) com dezenas de controles muito bonitos, com o DataGrid mais evoluÃdo que já vi para aplicações web, fora vários outros controles muito interessantes, dê uma olhadinha pela página deles e veja por você mesmo.
Qualquer dúvida, é só postar aÃ! Boa sorte!
Você já de cara encontrou um dos maiores dilemas para quem usa ASP.NET. UserControl pode parecer bastante útil, mas por experiência própria, já te advirto que não são fáceis de se trabalhar. Por causa de um pequeno detalhe: Ao renderizar(o que ocorre no server), o Id dele é modificado para um nome meio que randômico, basicamente é o mesmo id que você usa, mas pode sempre contém alguma adição por parte do server. Para se pegar esse nome, se usa a propriedade ClientId, assim:
$(function ()
{
$([Ô]#<%= usrControl.ClientID %> [Ô]).on([Ô]Remover[Ô])(function ()
{
alert([Ô]teste[Ô]);
});
});
Onde usrControl é o nome que você usou ao colocar o controle em algum container. Repare nisso da seguinte forma:
1 - Carregue a página normalmente.
2 - Abra o código fonte dela, geralmente CTRL+U
3 - Procure o componente e veja que o ID não é o mesmo que você colocou ao colocar o controle.
Por experiência, posso garantir que controles ASP.NET são um verdadeiro pé no saco. Eles são difÃceis com essa parte, quando se quer integrar com JQuery, AngularJS BootStrap ou algum outro framework. Um conselho que posso te dar quanto à isso é: Faça WebAPI para servir de fonte de dados e utilize apenas HTML + CSS + Javascript para a interface. é muito mais leve, simples e sem mistério. Se você utilizar JQuery, AngularJS, BootStrap ou outros frameworks, você vai ter um resultado muito melhor, além de uma flexibilidade de controles muito maior. Existem vários frameworks de componentes muito bons que fazem um uso muito eficiente do JQuery e do AngularJS, como por exemplo, o jQuery EasyUI, regido pela licença GNU(gratuito, desde que se mencione o seu uso) com dezenas de controles muito bonitos, com o DataGrid mais evoluÃdo que já vi para aplicações web, fora vários outros controles muito interessantes, dê uma olhadinha pela página deles e veja por você mesmo.
Qualquer dúvida, é só postar aÃ! Boa sorte!
Valeu pelas dicas KERPLUNK!
Dei uma olhada no JQuery EasyUI e realmente tem muita coisa boa.
Acho que a maior dificuldade durante o aprendizado de uma nova linguagem é a frustração de não conseguir realizar tarefas simples. Pelo menos a parte do CodeBehind eu não apanho tanto, que é baseado em VB.Net/C# mesmo. Apesar de que aqueles postbacks doidos terem me assustado no começo. Colocava variavel na seção general, e a variavel se perdia depois de atualizar a página hahaha Até aprender sobre Session, ViewState... foi uma luta.
Essa dica do ClientId foi muito boa. Assim, consigo identificar como meu controle criado no servidor é reconhecido na parte do client.
Muito obrigado cara!
Deixarei o tópico aberto mais um dia, caso queira comentar algo.
Abraços! Valeu pela força.
Dei uma olhada no JQuery EasyUI e realmente tem muita coisa boa.
Acho que a maior dificuldade durante o aprendizado de uma nova linguagem é a frustração de não conseguir realizar tarefas simples. Pelo menos a parte do CodeBehind eu não apanho tanto, que é baseado em VB.Net/C# mesmo. Apesar de que aqueles postbacks doidos terem me assustado no começo. Colocava variavel na seção general, e a variavel se perdia depois de atualizar a página hahaha Até aprender sobre Session, ViewState... foi uma luta.
Essa dica do ClientId foi muito boa. Assim, consigo identificar como meu controle criado no servidor é reconhecido na parte do client.
Muito obrigado cara!
Deixarei o tópico aberto mais um dia, caso queira comentar algo.
Abraços! Valeu pela força.
Com certeza tenho muito mais a comentar!
Essa ideologia de postback para tudo com (des)controles do server é um saco de controlar. No Page_Load tem que ficar prevendo isso o tempo todo. Uma alternativa para isso é não usar controles no server. Isso vai fazer com que não haja postback, em contra partida, você não tem o codebehid. Pelo menos não no modo tradicional. Mas existe uma saÃda para isso. Você pode criar um método estático e decorar como WebMethod, inclusive definindo a assinatura dele e chamar esse método com AJAX. Aqui um exemplo de como se faz isso. Esses métodos são chamados com o AJAX, executados e podem ou não ter retorno. é mais ou menos como funciona uma WebAPI, a diferença é que o método fica no próprio form, tornando o aprendizado disso mais simples. Eles podem ser aplicados à qualquer evento de qualquer controle HTML, inclusive para controles no renderizados no Server, mas para fazer a trigger do controle você precisa usar o ClientID dele para ter o nome/Id correto.
Usar variáveis em sessão/viewstate é quase sempre um péssimo negócio por várias razões:
1 - Dependendo do conteúdo ou número de variáveis na session ou viewstate, a renderização do form é afetada. Essas variáveis nada mais são que campos ocultos no form, observe o código gerado, você vai ver os campos ocultos com o conteúdo criptografado.
2 - À cada postback, essas variáveis devem ser consideradas e se o evento Load do form não estiver preparado corretamente, você vai perdê-las
3 - Por estarem no client, ainda que criptografadas, essas variáveis são passÃveis de hacking, comprometendo totalmente a segurança da sua aplicação. E é muito comum em programadores web iniciantes usarem o nome de login ou algo assim como variável de sessão.
4 - A Viewstate é basicamente uma [Ô]session do form[Ô] e não é incomum ter de [Ô]passá-las[Ô] para a session da aplicação
5 - A sobrecarga no server é um perigo real quando se usa muita coisa na session. Imagine 50 ou 100 usuários logados, cada um com 1Mb de dados na session. Esses dados são enviados e recebidos à cada postback, são logados no server e ficam sujeitos ao GAC.
Por essas e muitas outras razões detesto usar ASP.NET e prefiro muito mais criar a WebAPI e fazer o front-end usando HTML puro, claro, com JQuery, CSS e os frameworks que desejar. Quando eu precisar estender minha aplicação web para qualquer outra interface, incluindo mobile, a WebAPI já está pronta e [Ô]conversa[Ô] de boa com qualquer coisa. Além da vantagem indiscutÃvel de integração. Imagine que você tenha um cliente que usa o seu sistema e ele gostaria de integrar as vendas dele com um de seus representantes. Se o tal representante também usar seu sistema, fica espetacular, pois você tem total abertura para fazer como quiser essa integração. Mas mesmo que o tal representante não possua um sistema seu, você pode liberar métodos da sua WebAPI para ser consumida com o sistema dele. Ou seja, o seu cliente vai ter total acesso aos dados e transações dos representantes, em tempo real, de qualquer dispositivo. Fora dezenas de outros serviços que podem ser integrados sem que essas integrações sejam uma tarefa hercúlea.
Mas atenção! WebAPI é só vantagem comparado com outras plataformas, mas o seu código deve ser OOP e muito bem organizado, pois a documentação de uma WebAPI para consumo de terceiros, deve ser bem documentada. Portanto, se evolui de mais de uma maneira, você vai ter um código limpo, eficiente e de manutenção simples, além de totalmente integrável, mas o espaço para gambiarra e programação procedural é quase inexistente. Se precisar de ajuda também nisso, basta chamar, no que eu puder, eu ajudo com o maior prazer.
Essa ideologia de postback para tudo com (des)controles do server é um saco de controlar. No Page_Load tem que ficar prevendo isso o tempo todo. Uma alternativa para isso é não usar controles no server. Isso vai fazer com que não haja postback, em contra partida, você não tem o codebehid. Pelo menos não no modo tradicional. Mas existe uma saÃda para isso. Você pode criar um método estático e decorar como WebMethod, inclusive definindo a assinatura dele e chamar esse método com AJAX. Aqui um exemplo de como se faz isso. Esses métodos são chamados com o AJAX, executados e podem ou não ter retorno. é mais ou menos como funciona uma WebAPI, a diferença é que o método fica no próprio form, tornando o aprendizado disso mais simples. Eles podem ser aplicados à qualquer evento de qualquer controle HTML, inclusive para controles no renderizados no Server, mas para fazer a trigger do controle você precisa usar o ClientID dele para ter o nome/Id correto.
Usar variáveis em sessão/viewstate é quase sempre um péssimo negócio por várias razões:
1 - Dependendo do conteúdo ou número de variáveis na session ou viewstate, a renderização do form é afetada. Essas variáveis nada mais são que campos ocultos no form, observe o código gerado, você vai ver os campos ocultos com o conteúdo criptografado.
2 - À cada postback, essas variáveis devem ser consideradas e se o evento Load do form não estiver preparado corretamente, você vai perdê-las
3 - Por estarem no client, ainda que criptografadas, essas variáveis são passÃveis de hacking, comprometendo totalmente a segurança da sua aplicação. E é muito comum em programadores web iniciantes usarem o nome de login ou algo assim como variável de sessão.
4 - A Viewstate é basicamente uma [Ô]session do form[Ô] e não é incomum ter de [Ô]passá-las[Ô] para a session da aplicação
5 - A sobrecarga no server é um perigo real quando se usa muita coisa na session. Imagine 50 ou 100 usuários logados, cada um com 1Mb de dados na session. Esses dados são enviados e recebidos à cada postback, são logados no server e ficam sujeitos ao GAC.
Por essas e muitas outras razões detesto usar ASP.NET e prefiro muito mais criar a WebAPI e fazer o front-end usando HTML puro, claro, com JQuery, CSS e os frameworks que desejar. Quando eu precisar estender minha aplicação web para qualquer outra interface, incluindo mobile, a WebAPI já está pronta e [Ô]conversa[Ô] de boa com qualquer coisa. Além da vantagem indiscutÃvel de integração. Imagine que você tenha um cliente que usa o seu sistema e ele gostaria de integrar as vendas dele com um de seus representantes. Se o tal representante também usar seu sistema, fica espetacular, pois você tem total abertura para fazer como quiser essa integração. Mas mesmo que o tal representante não possua um sistema seu, você pode liberar métodos da sua WebAPI para ser consumida com o sistema dele. Ou seja, o seu cliente vai ter total acesso aos dados e transações dos representantes, em tempo real, de qualquer dispositivo. Fora dezenas de outros serviços que podem ser integrados sem que essas integrações sejam uma tarefa hercúlea.
Mas atenção! WebAPI é só vantagem comparado com outras plataformas, mas o seu código deve ser OOP e muito bem organizado, pois a documentação de uma WebAPI para consumo de terceiros, deve ser bem documentada. Portanto, se evolui de mais de uma maneira, você vai ter um código limpo, eficiente e de manutenção simples, além de totalmente integrável, mas o espaço para gambiarra e programação procedural é quase inexistente. Se precisar de ajuda também nisso, basta chamar, no que eu puder, eu ajudo com o maior prazer.
Cara, que bom que você comentou sobre o ViewState e o Session. São coisas que eu realmente não tinha pensado. E fiz o teste aqui, e realmente o ViewState aparece criptografado no html.
Eu estava armazenando informações de login no ViewState, pensando que estavam super protegidas do usuário.
Outra coisa que me chamou a atenção é essa questão de usuários em massa que você comentou. Eu estou acostumado a programar WindowsForm e costumo jogar toda a complexidade para o cliente (minha aplicação local) e tento usar o mÃnimo possÃvel o servidor (consultas, triggers, procedures, jobs.. no banco de dados). Mas nesse caso, realmente, todo o código ASP que eu digitar vai pro servidor. Então, coisas que eu costumo fazer programando .NET, terei que começar a pensar em fazer via Javascript, JQuery, etc. Acho que essa é uma das principais dificuldades, porque tenho que largar o comodismo de fazer algo que já sei (code behind) pra dar a tapa a capa nos scripts. Até as validações eu tenho feito via asp.net. Tamanho é o medo de javascript.
Pode deixar que irei postar sempre questões aÃ. Porque tenho muitas dúvidas teóricas.
Agradeço pela força Kerplunk. Poucas são as pessoas que tem essa boa vontade do caralho em ajudar o outro. No que precisar pode contar comigo também. Abração!
Eu estava armazenando informações de login no ViewState, pensando que estavam super protegidas do usuário.
Outra coisa que me chamou a atenção é essa questão de usuários em massa que você comentou. Eu estou acostumado a programar WindowsForm e costumo jogar toda a complexidade para o cliente (minha aplicação local) e tento usar o mÃnimo possÃvel o servidor (consultas, triggers, procedures, jobs.. no banco de dados). Mas nesse caso, realmente, todo o código ASP que eu digitar vai pro servidor. Então, coisas que eu costumo fazer programando .NET, terei que começar a pensar em fazer via Javascript, JQuery, etc. Acho que essa é uma das principais dificuldades, porque tenho que largar o comodismo de fazer algo que já sei (code behind) pra dar a tapa a capa nos scripts. Até as validações eu tenho feito via asp.net. Tamanho é o medo de javascript.
Pode deixar que irei postar sempre questões aÃ. Porque tenho muitas dúvidas teóricas.
Agradeço pela força Kerplunk. Poucas são as pessoas que tem essa boa vontade do caralho em ajudar o outro. No que precisar pode contar comigo também. Abração!
Tópico encerrado , respostas não são mais permitidas