[asp dot net]form en postback

[Anoniem: 27948]

Ik ben bezig om mijn voeten nat te krijgen in de wondere wereld van asp dot net. Ik heb een simpel formulier op een web pagina die geen master page heeft. Als ik de informatie post en de geposte parameters opvraag krijg ik netjes de namen van de velden zoals ze genoemd zijn (bv txtLoginname en txtPassword).

code:

txtLoginname -- 'xyz'
txtPassword -- 'abc'
ddlSchoolselector -- '1'
btnLogin -- 'Login'

Als ik echter een master pagina gebruik is dit niet langer het geval en krijg ik de volgende 'nonsens'

code:

ctl00$ContentPlaceHolder1$lbLanguageselector -- 'AFR'
ctl00$ContentPlaceHolder1$txtISO639code -- 'SPA'
ctl00$ContentPlaceHolder1$txtDescription -- 'Español'
ctl00$ContentPlaceHolder1$btnAddlanguage -- 'Add language'

De vraag is wat de juiste manier is om uit het laatste voorbeeld de originele namen van de velden en knoppen te halen.

Is het veilig om domweg bv. txtISO639code.Text te gebruiken? Het lijkt er tot nu toe op dat de waarde die daar in stond bewaard blijft, maar mag ik daar in 100% van de gevallen op rekenen? En dit lost niet het probleem op als er twee knoppen zijn (btnAddlanguage en btnAddtranslation) en ik moet uitvogelen welke knop was gebruikt.

Of moet ik de veldnaam analyseren om te zien of de naam waar ik in ge-interesserd ben erin zit? Of is er een andere manier?

De code die bovenstaande resultaten heeft gegeven

code:

        if (Page.IsPostBack == true)
        {
            for (int i = 0; i < Request.Form.Keys.Count; i++)
            {
                if (Request.Form.Keys[i].Substring(0, 2).Equals("__") == true)
                    continue;
                string tmp = Request.Form[Request.Form.Keys[i]];
                lblMessage.Text += "<br />" + Request.Form.Keys[i] + " -- '" + Request.Form[Request.Form.Keys[i]] + "'";
            }
        }

Bedankt voor het meedenken

[GrooV]

Je kan toch gewoon de waardes van je control uitlezen?

[Haan]

Je gebruikt ASP.NET, dus doe het gewoon op de ASP.NET manier en niet als classic ASP.

In de code-behind van je pagina, zijn gewoon alle controls beschikbaar, onafhankelijk van of je wel of geen master page gebruikt. Dus je kunt gewoon txtLogin.Text gebruiken en hoeft niet moeilijk te doen met Request.Forms.WhatEver

Je moet daarnaast een event koppelen aan je buttons, in dat event ga je vervolgens je ding doen. Daarmee heb je het probleem met je meerdere knoppen opgelost.

Je gaat dus niet in de Page_Load op een postback checken, maar je gaat iets doen met een button click event.

Maar kort samengevat moet je gewoon eerst eens even wat gaan lezen: http://www.asp.net/web-forms om een beetje begrip van de materie te krijgen.

[R4gnax]

Haan schreef op maandag 25 februari 2013 @ 14:06:
Maar kort samengevat moet je gewoon eerst eens even wat gaan lezen: http://www.asp.net/web-forms om een beetje begrip van de materie te krijgen.

Kort samengevat moet je gewoon eerst eens even WebForms inruilen voor MVC en dan even wat gaan lezen: http://www.asp.net/mvc om een beetje begrip van de materie te krijgen.


Serieus; waarom zou je voor nieuwbouw nog met de ultieme faal die WebForms is, willen gaan werken? Mij dunkt dat al keer op keer bewezen is dat WebForms gewoon niet past bij een moderne web architectuur. Het is puur een dinosaurus die overgebleven is uit het tijdperk dat Microsoft het nodig vond om WinForms ontwikkelaars de mogelijkheid te bieden om met hun 'kennis' ook web-applicaties in elkaar te sleuren & pleuren.

Daarnaast steekt het ook echt gewoon enorm slecht in elkaar.

ViewState werkt voor geen meter en maakt je HTTP requests en responses bloated. Alle control IDs maken je responses bloated. De page life-cycle, en daaraan gerelateerde event-driven architecture die de daadwerkelijke executie flow onleesbaar, onbeheersbaar en ononderhoudbaar maakt. En dan is er nog het extreem fragiele databinding, waarbij met het minste of geringste onnodige rebinds op een databron nodig zijn of wat gewoon niet werkt omdat bepaalde handelingen in de lifecycle verkeerd om plaats vinden. (Saillant detail; zelfs Microsoft's eigen BaseDataBoundControl, waarvan alle data-bound controls afgeleid horen te zijn, maakt er een potje van.)

Nee, WebForms is iets waarvan we allemaal collectief het bestaan het beste zo snel mogelijk kunnen vergeten...

[D-Raven]

R4gnax schreef op maandag 25 februari 2013 @ 19:39:
[...]

Kort samengevat moet je gewoon eerst eens even WebForms inruilen voor MVC en dan even wat gaan lezen: http://www.asp.net/mvc om een beetje begrip van de materie te krijgen.


Serieus; waarom zou je voor nieuwbouw nog met de ultieme faal die WebForms is, willen gaan werken? Mij dunkt dat al keer op keer bewezen is dat WebForms gewoon niet past bij een moderne web architectuur. Het is puur een dinosaurus die overgebleven is uit het tijdperk dat Microsoft het nodig vond om WinForms ontwikkelaars de mogelijkheid te bieden om met hun 'kennis' ook web-applicaties in elkaar te sleuren & pleuren.

Daarnaast steekt het ook echt gewoon enorm slecht in elkaar.

ViewState werkt voor geen meter en maakt je HTTP requests en responses bloated. Alle control IDs maken je responses bloated. De page life-cycle, en daaraan gerelateerde event-driven architecture die de daadwerkelijke executie flow onleesbaar, onbeheersbaar en ononderhoudbaar maakt. En dan is er nog het extreem fragiele databinding, waarbij met het minste of geringste onnodige rebinds op een databron nodig zijn of wat gewoon niet werkt omdat bepaalde handelingen in de lifecycle verkeerd om plaats vinden. (Saillant detail; zelfs Microsoft's eigen BaseDataBoundControl, waarvan alle data-bound controls afgeleid horen te zijn, maakt er een potje van.)

Nee, WebForms is iets waarvan we allemaal collectief het bestaan het beste zo snel mogelijk kunnen vergeten...

Ik zeg niet dat ik Webforms geweldig vind, maar de aspecten die jij hier aanhaalt zijn behoorlijk subjectief en aan mening onderhevig.

Webforms steekt niet 'slecht' in elkaar. Onderschat niet hoeveel website en applicaties er op dit framework gemaakt zijn, en nog steeds gemaakt worden.
Dat het framework kwa architectuur design niet meer van deze tijd is, ok, maar om het dan meteen slecht te noemen vind ik echt een paar stappen te ver.

[R4gnax]

D-Raven schreef op maandag 25 februari 2013 @ 19:57:
Webforms steekt niet 'slecht' in elkaar. Onderschat niet hoeveel website en applicaties er op dit framework gemaakt zijn, en nog steeds gemaakt worden.
Dat het framework kwa architectuur design niet meer van deze tijd is, ok, maar om het dan meteen slecht te noemen vind ik echt een paar stappen te ver.

Je kunt inderdaad wel degelijk onderhoudbare applicaties schrijven in WebForms: dat houdt in dat je in de Page een binder injecteert waarin je input parameters ophaalt en valideert, dat je deze doorgeeft aan een model factory, dat deze daarmee een view model tree opbouwt en dat je deze tree daarna één keer aan je Page data-bind; je maakt gebruik van de 'trickle down' om alle child controls ook te populeren. Klaar.
(Even terzijde: laat dat nou net zijn wat eigenlijk ASP.NET MVC ook doet, maar dan van meet af aan goed opgezet...)


Bovenstaande is alleen helemaal niet waar WebForms voor ontworpen is, getuige alleen al het feit dat je bewust 90% van alle 'features' moet negeren om een enigzins nette en op de lange termijn onderhoudbare applicatie te produceren.

WebForms was bedoeld als het web equivalent van WinForms, oftewel: het maken van een stateful applicatie op basis van 'forms' door 'controls' in een layout designer in elkaar te slepen en aan elkaar te hangen via event handlers. Hoeveel van dat soort WebForms applicaties; die 'zoals het bedoeld is' gebouwd zijn, ken jij, waarbij ze daadwerkelijk overzichtelijk in elkaar zijn gezet en ook over de tijd heen overzichtelijk zijn gebleven? Dat zullen er verdomd weinig zijn, denk ik zo.

Als je daadwerkelijk meent dat de (bedoelde) architectuur voor WebForms niet slecht in elkaar steekt dan is daar maar één verklaring voor: Stockholm Syndroom; je hebt je eigen aangeleerd er mee te leven.


‌

D-Raven schreef op maandag 25 februari 2013 @ 19:57:
Ik zeg niet dat ik Webforms geweldig vind, maar de aspecten die jij hier aanhaalt zijn behoorlijk subjectief en aan mening onderhevig.

Trek BaseDataBoundControl maar eens door ILSpy of Reflector heen of download (als je avontuurlijk bent) de framework sourcecode. Vertel me maar eens zonder te verschieten dat dat goed in elkaar steekt.
(En even om tegen die prutzooi af te zetten: als je het wel goed implementeert dan is een strongly-typed data-bind zo'n 10 regels code.)

offtopic:
Oh, cool! Je kunt toch wel een zero-width non-joiner ('‌') gebruiken om extra witruimte te forceren voor een quote. Ben verbaasd dat dat werkt zeg, maar het is wel verdomde handig om een tweedelige post netjes visueel meer gescheiden te formatten.

[ Voor 19% gewijzigd door R4gnax op 25-02-2013 21:46 ]

[D-Raven]

R4gnax schreef op maandag 25 februari 2013 @ 21:31:
[...]


Je kunt inderdaad wel degelijk onderhoudbare applicaties schrijven in WebForms: dat houdt in dat je in de Page een binder injecteert waarin je input parameters ophaalt en valideert, dat je deze doorgeeft aan een model factory, dat deze daarmee een view model tree opbouwt en dat je deze tree daarna één keer aan je Page data-bind; je maakt gebruik van de 'trickle down' om alle child controls ook te populeren. Klaar.
(Even terzijde: laat dat nou net zijn wat eigenlijk ASP.NET MVC ook doet, maar dan van meet af aan goed opgezet...)

Bovenstaande is alleen helemaal niet waar WebForms voor ontworpen is, getuige alleen al het feit dat je bewust 90% van alle 'features' moet negeren om een enigzins nette en op de lange termijn onderhoudbare applicatie te produceren.

Als jij een MVC gedachtengoed wilt toepassen op WebForms, then your gonna have a bad time.
Voor wat het poogt te doen steekt webforms best aardig in elkaar. Dat de manier waarop het 't web en webdevelopment an sich benaderd niet ideaal is staat daar los van. Dat zijn 2 hele verschillende dingen, maar blijkbaar kan jij dat niet los beschouwen.

WebForms was bedoeld als het web equivalent van WinForms, oftewel: het maken van een stateful applicatie op basis van 'forms' door 'controls' in een layout designer in elkaar te slepen en aan elkaar te hangen via event handlers. Hoeveel van dat soort WebForms applicaties; die 'zoals het bedoeld is' gebouwd zijn, ken jij, waarbij ze daadwerkelijk overzichtelijk in elkaar zijn gezet en ook over de tijd heen overzichtelijk zijn gebleven? Dat zullen er verdomd weinig zijn, denk ik zo.

Als jij zo met webforms omgaat dan spreekt dat boekdelen. Om een vergelijking te maken richting MVC, pleur jij ook al je code linea recta in je controller methods "omdat dit zo in alle voorbeelden staat" ?

De rest van je opmerkingen zijn zinloos, want dat is niet waar we het hier over hebben. Daarnaast, in elk framework vind je wel ranzige code.

offtopic:
Zullen we dan nu ophouden met het hyjacken van de TS zn topic ?

[Anoniem: 27948]

GrooV schreef op maandag 25 februari 2013 @ 14:02:
Je kan toch gewoon de waardes van je control uitlezen?

Haan schreef op maandag 25 februari 2013 @ 14:06:

In de code-behind van je pagina, zijn gewoon alle controls beschikbaar, onafhankelijk van of je wel of geen master page gebruikt. Dus je kunt gewoon txtLogin.Text gebruiken en hoeft niet moeilijk te doen met Request.Forms.WhatEver

OK, het is dus 100% gegarandeerd dat direct na een post die controls dezelfde inhoud bevatten als the POST parameters en dat lost dus onderstaand probleem op.

Anoniem: 27948 schreef op maandag 25 februari 2013 @ 12:54:
Is het veilig om domweg bv. txtISO639code.Text te gebruiken? Het lijkt er tot nu toe op dat de waarde die daar in stond bewaard blijft, maar mag ik daar in 100% van de gevallen op rekenen?

Haan schreef op maandag 25 februari 2013 @ 14:06:
Je moet daarnaast een event koppelen aan je buttons, in dat event ga je vervolgens je ding doen. Daarmee heb je het probleem met je meerdere knoppen opgelost.

Je gaat dus niet in de Page_Load op een postback checken, maar je gaat iets doen met een button click event.

OK, ik had dat al geprobeerd, maar ben er nog niet uit hoe dat precies werkt; op het moment dat ik dat doe gebeurt er geen post; zal wel een aanroep van een of andere methode missen of autopostback niet hebben uitgeschakeld (of iets in die trant). Ik ben wel in staat geweest een GET aan de gang te krijgen. Ik zal het nog eens een keertje proberen.

Haan schreef op maandag 25 februari 2013 @ 14:06:
Maar kort samengevat moet je gewoon eerst eens even wat gaan lezen: http://www.asp.net/web-forms om een beetje begrip van de materie te krijgen.

Ik heb me al suf gelezen en gezocht in de maand dat ik bezig ben met SQL server en asp dot net

Bedankt voor de antwoorden. En sorry dat ik op dit moment niet al te ge-interesseerd ben in MVC versus webforms versus wat-dan-ook. Voel vrij om die discussie voor te zetten

[D-Raven]

Eeen webforms vs mvc discussie is wel het laatste waar ik zin in heb Been there, done that, got the T-shirt(s), use the search.

[R4gnax]

D-Raven schreef op maandag 25 februari 2013 @ 22:28:
Voor wat het poogt te doen steekt webforms best aardig in elkaar. Dat de manier waarop het 't web en webdevelopment an sich benaderd niet ideaal is staat daar los van. Dat zijn 2 hele verschillende dingen, maar blijkbaar kan jij dat niet los beschouwen.

"WebForms is een framework bedoeld voor web development, alleen is WebForms uiteraard niet een framework bedoeld voor web development. Hier is niets mis mee."

Sorry hoor. Maar daar moest ik gewoon nog even op reageren. Effectief is dat namelijk gewoon wat je schrijft. Aangezien je zelf al aangeeft geen zin te hebben in verdere discussie houd ik het daar bij.

[Grijze Vos]

Anoniem: 27948 schreef op dinsdag 26 februari 2013 @ 06:25:

OK, het is dus 100% gegarandeerd dat direct na een post die controls dezelfde inhoud bevatten als the POST parameters en dat lost dus onderstaand probleem op.

Nee, dat is het niet. Alleen als je die data weer terug post naar de server worden die controls gepopulate. En ze worden ook alleen dan gepopulate als ze bestaan in de control structure voordat het Page_Init event vuurt. (Dus als ze dynamisch toegevoegd zijn, dan moet je ze opnieuw toevoegen in de PreInit.)

Luister naar R4gnax, delete je project, start een mvc4 project. Daar heb je oneindig veel meer aan. Webforms is een convoluted manier van webprogrammeren die je hard gaat steken zodra je ook maar iets ajax-related gaat doen. Dan ga je namelijk de pijn voelen van het kunstje waar webforms zo goed in is: het pretenderen een stateful applicatiemodel te zijn in een stateless omgeving, terwijl je die state niet hebt bij ajax requests.

Overigens, die 'dot' mag je gewoon schrijven als een '.' hoor: ASP.NET

[D-Raven]

R4gnax schreef op dinsdag 26 februari 2013 @ 09:12:
[...]


"WebForms is een framework bedoeld voor web development, alleen is WebForms uiteraard niet een framework bedoeld voor web development. Hier is niets mis mee."

Sorry hoor. Maar daar moest ik gewoon nog even op reageren. Effectief is dat namelijk gewoon wat je schrijft. Aangezien je zelf al aangeeft geen zin te hebben in verdere discussie houd ik het daar bij.

Dat is niet wat ik zeg We praten langs elkaar heen geloof ik.
Wat ik zeg is dat Webforms kwa code, databinding, event handlers, de hele shit, best goed werkt. Je kunt het op allerlei manieren 'misbruiken' en het werkt gewoon (mits je weet wat je doet).

Dat het paradigma wat webforms gebruikt voor webdevelopment (statefull pagina's, page postbacks, pleur en sleur, etc) niet de manier is waarop je/ik webdevelopment zou willen doen tegenwoordig. Daar ben ik het mee eens. Maar dat zie ik als 2 verschillende dingen.

offtopic:
Ik programmeer notabene al 2 jaar in MVC

[Anoniem: 27948]

OK
even ter afsluiting van mijn kant
1)
ik heb de onclick voor de knoppen nu werkend; vraag me niet wat er de vorige keer mis ging
2)
code aangepast onder de veronderstelling dat het allemaal veilig is; dit was al gebeurd voordat 'grijze vos' zijn zegje deed, maar ik zal daar nog eens over nadenken

PS
Ik heb erg veel zijn om terug te gaan naar vi, php and mysql, maar daar leren we weer zo weinig van

En nogmaals bedankt, allemaal.

[ Voor 3% gewijzigd door Anoniem: 27948 op 27-02-2013 09:00 ]

[RobIII]

Anoniem: 27948 schreef op woensdag 27 februari 2013 @ 08:59:
PS
Ik heb erg veel zijn om terug te gaan naar vi, php and mysql, maar daar leren we weer zo weinig van

Dan moet je ASP.Net MVC eens een kans geven en, laten we eerlijk wezen, daarna wil je never, ever, meer terug naar PHP. Er zullen vast uitzonderingen zijn (en die melden zich geheid allemaal stuk voor stuk onder deze post...) maar het gros van de mensen die ik ken/spreek die naar MVC3/4 overstappen willen nooit meer terug.

Het Webforms paradigma moet je liggen (en is inderdaad, IMHO, wat outdated). Maar dat maakt niet meteen héél ASP (noch .Net for that matter) ruk.

[ Voor 14% gewijzigd door RobIII op 27-02-2013 09:53 ]

[InZane]

R4gnax schreef op maandag 25 februari 2013 @ 19:39:
[...]

Kort samengevat moet je gewoon eerst eens even WebForms inruilen voor MVC en dan even wat gaan lezen: http://www.asp.net/mvc om een beetje begrip van de materie te krijgen.

[knip]

Het is alsof ik mezelf hoor praten

Ik zou zelf ook niet meer met WebForms beginnen. Naar mijn mening is het een uitstervende soort.

In plaats daarvan zou ik me lekker gaan inlezen in MVC 3/4, Entity Framework, Razor en vergeet ook Nuget niet