POST COM JQUERY. RETORNO NOTHING
Como me recomendaram, comecei a ver uns recursos do JQuery UI. Tem umas coisas muito bacanas. Mas infelizmente, não tem uma integração legal com WebForm. Vi que existe um tal de Juice UI que faz essa integração. Mas como estou aprendendo, resolvi fazer algumas coisas mais primitivas primeiro...
Por não fazer essa integração legal, vi que existe a possibilidade de passar os dados dos controles em forma de requisições. Beleza. AÃ fui fazer o meu primeiro teste: Num clique de um botão eu executo o seguinte script:
var dados = [Ô]id=312[Ô]
$.post([Ô]WebForm1.aspx[Ô], dados);
E no clique do outro botão, eu coloco meu código asp desse jeito:
Dim retorno As String = Request.Form([Ô]id[Ô])
Mas o retorno sempre vem [Ô]Nothing[Ô]. Já depurei o script, e ele está sendo executado, mas por algo motivo não consigo pegar ele depois com o Request.
Alguém saberia me dizer o que estou fazendo de errado?
Desde já, agradeço muito.
Definição do problema: Usar o Sortable do JQueryUI e conseguir salvar a ordenação no banco de dados.
Dificuldade: Recuperar essas informações e jogar para o servidor.
Resolvi o problema da seguinte forma:
script:
$(function () {
$([Ô]#sortable[Ô]).sortable({
placeholder: [Ô]ui-state-highlight[Ô],
update: function ()
{
var dados = $([Ô]#sortable[Ô]).sortable([Ô]serialize[Ô], { key: [Ô]sort[Ô] });
$.ajax({
type: [Ô]POST[Ô],
url: [Ô]Default.aspx/RecuperaOrdenacao[Ô],
data: [ô]{chaves: [Ô][ô] + dados + [ô][Ô] }[ô],
contentType: [Ô]application/json; charset=utf-8[Ô],
dataType: [Ô]json[Ô]
});
}
});
$([Ô]#sortable[Ô]).disableSelection();
});
Onde no evento [Ô]update[Ô], que é quando o cara acabou o drag-and-drop... eu mando um método Post assÃncrono, chamando um WebMethod.
No code-behind, eu declaro meu webmethod dessa forma:
<WebMethod>
Public Shared Sub RecuperaOrdenacao(chaves As String)
[ô]salvo as informações aqui
End Sub
Deixarei o tópico aberto durante mais 1 dia para qualquer comentário ou dúvida sobre o código.
Abraços!
Tenho dado umas lidas em MVC e WebAPI também, paralelamente. Mas não vejo o motivo de tanto saudosismo pela tecnologia também não.
Quem programa MVC sem usar o projeto MVC (melhor dizendo, que usa o padrão de projetos MVC sem necessariamente usar o tipo de projeto MVC). Tem a parte do servidor estruturada de forma praticamente idêntica. Se bobear, tenho mais flexibilidade usando meu framework.
Essa facilidade no mapeamento de dados no projeto MVC obviamente é uma evolução. Mas muito antes disso existir, a gente já programava desse jeito.
Pelo que andei lendo, WebAPI substitui o WebService, e não o WebForm.
Assim como muitos aqui, existem muitas pessoas que largaram mão da View com webform e começou a fazer só javascript e jquery. Usando jQuery para consumir o serviço.
A vantagem é que:
O código da View fica mais limpo. Você não fica nessa emboleira do caramba que tenho com WebForm. E o código que é renderizado é muito mais limpo. Eu concordo.
Mas vamos concordar também que a curva de aprendizado é muito maior.
Tem muita gente que fala pra migrar direto pro MVC (WebApi) porque eles vieram do WebForm ou pelo menos, conhecem JQuery e javascript o bastante para conseguir desenvolver algo na parte do cliente.
Infelizmente é meu primeiro contato com JQuery e Javascript. Então se a minha View depender só dos meus conhecimentos de javascript e JQuery, eu to na merda. Não vai sair nada. Boostrap, JQuery UI... to aprendendo tudo agora... E está sendo um processo bem vagaroso. Porque é tanta tecnologia que faz a mesma coisa, que você nem sabe por onde anda.
Então o meu plano é desenvolver pra WebForm, mas já me familiarizando com o uso de JQuery, pra quando eu começar a fazer minhas Views apenas consumindo o meu serviço WebAPI ... não travar muito. Justamente por isso, fiz questão de usar o JQuery UI na unha, ao invés de usar componentes prontos.
Mas pelo que vi de exemplos na internet, tirando a parte do JQuery e javascript, vai ser algo bem tranquilo migrar depois pra WebApi. Na verdade, tirando a parte da View, diria que me sinto confiável pra programar.
Abraços!
E como sempre, agradeço os conselhos!
O WebForm surgiu pra pegar a turma que sempre se preocupou em trabalhar com formulários, e isso deixa o seu código mais amarrado e dependente dos controles. é como se você tivesse programando em RAD com DataBound para Windows Forms e alguém chegasse e lhe perguntasse: [Ô]Não seria melhor você fazer o seu código desamarrado dos controles?[Ô] Aà você diz: [Ô]Acho que não, pois do jeito que estou fazendo é tudo mais rápido e produtivo. Eu arrasto um controle aqui, outro ali e já fica tudo funcionando. Pra quê se dar ao trabalho de fazer todas as coisas desacopladas se do jeito que estou fazendo está funcionando e atendendo aos meus propósitos?[Ô]. Perceba que justificativa existe pra tudo e não terÃamos como dizer que ele está errado. Tudo vai depender do patamar que você quer chegar e dá perspicácia em tomar o rumo menos doloroso.
Citação::
Valeu cara.
Tenho dado umas lidas em MVC e WebAPI também, paralelamente. Mas não vejo o motivo de tanto saudosismo pela tecnologia também não.
Quem programa MVC sem usar o projeto MVC (melhor dizendo, que usa o padrão de projetos MVC sem necessariamente usar o tipo de projeto MVC). Tem a parte do servidor estruturada de forma praticamente idêntica. Se bobear, tenho mais flexibilidade usando meu framework.
Essa facilidade no mapeamento de dados no projeto MVC obviamente é uma evolução. Mas muito antes disso existir, a gente já programava desse jeito.
Pelo que andei lendo, WebAPI substitui o WebService, e não o WebForm.
Assim como muitos aqui, existem muitas pessoas que largaram mão da View com webform e começou a fazer só javascript e jquery. Usando jQuery para consumir o serviço.
A vantagem é que:
O código da View fica mais limpo. Você não fica nessa emboleira do caramba que tenho com WebForm. E o código que é renderizado é muito mais limpo. Eu concordo.
Mas vamos concordar também que a curva de aprendizado é muito maior.
Tem muita gente que fala pra migrar direto pro MVC (WebApi) porque eles vieram do WebForm ou pelo menos, conhecem JQuery e javascript o bastante para conseguir desenvolver algo na parte do cliente.
Infelizmente é meu primeiro contato com JQuery e Javascript. Então se a minha View depender só dos meus conhecimentos de javascript e JQuery, eu to na merda. Não vai sair nada. Boostrap, JQuery UI... to aprendendo tudo agora... E está sendo um processo bem vagaroso. Porque é tanta tecnologia que faz a mesma coisa, que você nem sabe por onde anda.
Então o meu plano é desenvolver pra WebForm, mas já me familiarizando com o uso de JQuery, pra quando eu começar a fazer minhas Views apenas consumindo o meu serviço WebAPI ... não travar muito. Justamente por isso, fiz questão de usar o JQuery UI na unha, ao invés de usar componentes prontos.
Mas pelo que vi de exemplos na internet, tirando a parte do JQuery e javascript, vai ser algo bem tranquilo migrar depois pra WebApi. Na verdade, tirando a parte da View, diria que me sinto confiável pra programar.
Abraços!
E como sempre, agradeço os conselhos!
Cara vou ter que discordar de você, iniciar um projeto em web forms é complicado.. eu fiz em webforms um projeto minúsculo pois possui apenas 3 páginas, porém só vou dar alguns motivos pra você abandonar o webforms e partir pro MVC:
http://imasters.com.br/linguagens/asp/asp-net-5-nada-sera-como-antes/?trace=1519021197
Agora minha dica é já comece no ASP .NET 5
Concordo com o JABA, se prender a tecnologias do passado não é uma boa e isso é desculpa.
Citação::
Valeu cara.
Tenho dado umas lidas em MVC e WebAPI também, paralelamente. Mas não vejo o motivo de tanto saudosismo pela tecnologia também não.
Quem programa MVC sem usar o projeto MVC (melhor dizendo, que usa o padrão de projetos MVC sem necessariamente usar o tipo de projeto MVC). Tem a parte do servidor estruturada de forma praticamente idêntica. Se bobear, tenho mais flexibilidade usando meu framework.
Essa facilidade no mapeamento de dados no projeto MVC obviamente é uma evolução. Mas muito antes disso existir, a gente já programava desse jeito.
Pelo que andei lendo, WebAPI substitui o WebService, e não o WebForm.
Assim como muitos aqui, existem muitas pessoas que largaram mão da View com webform e começou a fazer só javascript e jquery. Usando jQuery para consumir o serviço.
A vantagem é que:
O código da View fica mais limpo. Você não fica nessa emboleira do caramba que tenho com WebForm. E o código que é renderizado é muito mais limpo. Eu concordo.
Mas vamos concordar também que a curva de aprendizado é muito maior.
Tem muita gente que fala pra migrar direto pro MVC (WebApi) porque eles vieram do WebForm ou pelo menos, conhecem JQuery e javascript o bastante para conseguir desenvolver algo na parte do cliente.
Infelizmente é meu primeiro contato com JQuery e Javascript. Então se a minha View depender só dos meus conhecimentos de javascript e JQuery, eu to na merda. Não vai sair nada. Boostrap, JQuery UI... to aprendendo tudo agora... E está sendo um processo bem vagaroso. Porque é tanta tecnologia que faz a mesma coisa, que você nem sabe por onde anda.
Então o meu plano é desenvolver pra WebForm, mas já me familiarizando com o uso de JQuery, pra quando eu começar a fazer minhas Views apenas consumindo o meu serviço WebAPI ... não travar muito. Justamente por isso, fiz questão de usar o JQuery UI na unha, ao invés de usar componentes prontos.
Mas pelo que vi de exemplos na internet, tirando a parte do JQuery e javascript, vai ser algo bem tranquilo migrar depois pra WebApi. Na verdade, tirando a parte da View, diria que me sinto confiável pra programar.
Abraços!
E como sempre, agradeço os conselhos!
Se entendimento sobre WebApi, esta errado, mas não vou discutir isso aqui.
Bom depois não diga que não foi avisado e que não sabia, mas você escolheu o que aparentemete é mais cômodo, afinal de contas arrastar e soltar componentes é uma maravilha não é, eu já fazia isso no windows forms então vai ser quase a mesma coisa no web forms correto?
Errado, o que aparentemente é cômodo hoje, vai ser uma pedra no sapado mais tarde, aliás várias pedras.
Espere o sistema crescer um pouco e vc vai saber do que estou falando, a começar pelo seu javascript, que se transformará numa macarronada, sem inÃcio e sem fim.
Meus conselho, siga o conselho do MESTRE
Boa sorte
Abraços
[Ô]Desenvolve usando Web Forms? Não se preocupe…
Você pode continuar a desenvolver aplicativos Web Forms e ter a confiança de que os Web Forms é uma parte essencial da plataforma de desenvolvimento .NET para web.
A tecnologia não foi abandonada e ainda terá a adição de novos recursos para Web Forms para melhorar a experiência de desenvolvimento e manter a tecnologia atualizada com as práticas da web.[Ô]
Eu não vou entrar numa discussão, até porque sou iniciante e não me sinto a vontade para defender uma prática ou outra, como faço com WinForm.
Eu só acho meio chato o fato de toda pergunta que coloco sobre WebForm aqui, o pessoal só responder com mudança de tecnologia.
Estou no meio de um projeto, as vezes tenho dúvidas por ser iniciante. Mas nunca consigo uma resposta. Se o cara responde pelo menos:
[Ô]Cara, esquece esse WebForm...
Mas a resposta pra sua pergunta é bla bla bla bla[Ô]
Aà pelo menos vai estar me ajudando e me dando a dica. E o engraçado é que se tem uma pergunta sobre VB6, esse mesmo pessoal responde na boa. Vejo perguntas de gente que faz uma query na unha gigantesca, cheia de concatenação... o pessoal responde. Vejo perguntas de gente programando estruturado no .NET. Aliás, eu nunca vi uma classe postada numa pergunta, que fazia uso de Herança ou até mesmo que implementava uma Interface personalizada.
Olha, eu agradeço a ajuda que vocês estão me dando. Sei que falam isso pro meu bem... mas até 1 mês atrás+-, nem <div> eu sabia o que era.
[Ô]Espere o sistema crescer um pouco e vc vai saber do que estou falando, a começar pelo seu javascript, que se transformará numa macarronada, sem inÃcio e sem fim.[Ô]
Eu realmente espero ver o que você está falando. Porque acho que a mudança de tecnologia, deve ser feita por necessidade... e não modismo ou porque outro falou que era melhor. Atualmente eu tenho só 2 birras com o WebForm: A quantidade de lixo gerado na renderização e criação de WebControl... criar um WebControl foi bastante complicado porque tinha que ter um conhecimento bem definido do ciclo de vida da página. O fato de ter que desenhar tudo no Pre-Render foi desgastante.
Seja como for, pararei de postar perguntas sobre WebForm aqui... até porque nunca consigo uma resposta...
Abraços!