25. januar 2005 - 21:50Der er
15 kommentarer og 1 løsning
Bevare objekt state mellem formularer
Hej gruppe,
Jeg er lige begyndt at kode lidt ASP.NET (har en lille smule Java erfaring) og er rendt ind i et problem.
Jeg har en formular (kontakt.aspx) og en tilhørende code-behind fil. Min formular.aspx er opdelt i to, afgrænset af en variabel, der bliver sat i code-behindfilen, der angiver om det er formular1 eller formular2 der skal vises. Vil nemlig gerne have at brugeren har mulighed for at validere sine indtastede data inden afsendelse. Så disse bliver altså vist på siden efter brugeren har afsendt formularen første gang.
Problemet er at når brugeren sender de indtastede data anden gang - disse sendes til en email vha. SmtpMail klassen, bliver variablene ikke medsendt i emailen.
Det jeg har forsøgt er, at lave en klasse, der hedder Objekt_Kontakt.cs, denne har getmetoder for alle værdierne, samt en konstruktør, der sætter værdierne på objektet.
Jeg sætter så værdierne i den første event sådan her:
og kalder opbejtet som er oprettet i toppen af klassen med public Object_Kontakt o;
o = new Object_Kontakt(firmanavn, kontaktperson, adresse, postnummer, by, telefon, email, ringFra, ringTil, ringDato);
Det virker fint nok med oprettelsen af objektet og jeg kan så sagtens kalde værdierne fra samme metode, men når jeg i min mailopbygning gør fek,s. således:
Sendes der altså ingen objektværdier med i emailen. Jeg får en null-reference exception...
Nogen der ved hvad jeg gør galt? For burde jeg ikke kunne kalde et objekt der lige er oprettet fra en anden metode indenfor samme klasse?
Håber nogen kan hjælpe - kunne godt tænke mig at kunne lave dette mere objektorienteret og vil helst undgå session-variable eller hidden fields eller hvad man ellers bruger for at overføre data mellem metoder/formularer.
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
Hvis metoderne er i samme klasse og objektet ikke er oprettet i en metode som en local variabel så kan du godt ja... men kan lige kigge din kode igennem også
Hvis jeg har forstået spørgsmålet korrekt så er det en lokal variabel for metoden så derfor kan den ikke ses i en anden metode.. hvis din metode som opretter objektet skal kalde en anden metode kan du sende det med som parameter
Synes godt om
Slettet bruger
25. januar 2005 - 22:48#4
Jeg vil meget gerne sende begge klasser hvis det vil gøre det mere tydeligt hvad det er jeg vil lave. Kort fortalt er det jeg gør:
1. Indsamler nogle værdier fra formularen i min .aspx side
2. Sætter disse værdier lig med variable lokalt i den ene metode i min code-behind klasse.
3. Referencierer et objekt der allerede er erklæret i toppen - altså med private - hvor alle variable sendes med til en konstruktør i den anden klasse.
4. Kalder objektets metoder for at hente værdierne ind i min anden metode i min code-behind klasse.
Desværre virker det ikke som det skal, altså jeg kan se at objektet er oprettet osv., da jeg kan kalde metoderne og få udskrevet værdier fra den første metode, men ikke fra den næste - her er værdierne tilsyneladende væk.
Hvordan sørger man for at objektet lever mere end én sides "levetid"?
du gemmer objectet i session'en, og henter det ud igen på en anden side.
Synes godt om
Slettet bruger
25. januar 2005 - 23:09#6
Jeg ville helst undgå at oprette sessionobjekter, derfor denne metode. Vil det sige at det ikke kan gøres på andre måder end med sessionobjekter eller hidden fields i formen?
uhm... Response.Transfer kan også gøre det, da du så på side2 kan få fat i værdierne fra side1 ved hjælp af Context.Handler
Synes godt om
Slettet bruger
25. januar 2005 - 23:59#8
Her er et svar jeg fik fra en anden gruppe vedrørende det samme problem:
"Hvis du (for skønheden i kodens skyld) vil lave det du tænker på skal du nok arbejde med serialisering, hvor du gemmer objektet på serveren og efterfølgende henter det frem igen. Mit gæt vil dog være at der et vist overhead ved denne løsning, men det er ren spekulation fra min side."
Så det kan tilsyneladende godt lade sig gøre at oprette et onjekt på serveren for derefter at referere til det, det er så bare hvordan og hvad der menes med overhead...
Men hvis det er så stort et problem kan jeg selvfølgelig godt lade være med at bruge den, troede bare at det netop var muligt med objektorienterede sprog (klient-server princip eller ej).
du skal huske på at en webside er et stateless miljø. Serveren husker ikke umiddelbart på hvad der skete på en side for 2 minutter siden. Dette kræver at man som programmør må implementere en form for state. Til det findes der Application, Session og ViewState. De to første befinder sig i serverens hukommelse og kan bruges til henholdsvis deling mellem alle sessions og indenfor den enkelte session. Ved at bruge ViewState bliver ens state gemt i tekststreng der bliver sendt med siden til klienten, og ved næste request kan man så genskabe ens state som den var sidst en side blev hentet.
Den metode du her referer til er ViewState og er fin til små mængder data der ikke er for komplekst. Og ja, der er kommer en del overhead på viewstate, og kan meget hurtigt generere en hulens masse ekstra trafik.
Jeg kan dog ikke se hvad du har imod Session. Det er en feature der er implementeret, netop for at kunne beholde sine objecter på tværs af requests. Altså i fuld tråd med OOP-principperne. At kunne bruge ViewState, men ikke session ser jeg endda endnu mere absurd.
Altså. Gem dit object i en session, og hiv det frem igen når du skal bruge. Om det er i samme request eller 9 minutter senere... doesn't matter. Det er det samme object som da du gemte det.
PS. Du kan ikke direkte sammenligne en webside med et klient-server miljø. Et et KS-miljø vil serveren som oftest huske på klienten og hvad den har foretaget sig in the past. Det gør webserveren ikke. Den modtager et request, udfører det, sender data tilbage til klienten og glemmer derefter alt om det request. Et stateless miljø.
Cite: Så det kan tilsyneladende godt lade sig gøre at oprette et onjekt på serveren for derefter at referere til det, det er så bare hvordan og hvad der menes med overhead...
Ja, sagtens... anyone told you otherwise?
Synes godt om
Slettet bruger
26. januar 2005 - 01:01#11
Citat: Ja, sagtens... anyone told you otherwise?
Næ ikke ligefrem, men jeg er sådan set heller ikke blevet klogere på hvorfor jeg så ikke kan referere til det fra en anden metode :)
som jeg kan se, og har forstået det... så består din side af to dele, som hver især eksisterer i to uafhængige kontekst'e, right? du har din side, lad os kalde den side/1 og side/2... samme aspx-sider men i hvert sit request.
Du opretter et object på side/1 og forventer at dette object stadigvæk findes når at du sender brugeren videre til side/2. Thats just not going to happen. Med mindre at du selv gør noget for at gemme dit state mellem dine request, så vil et object oprettet i et request ikke findes i et andet request.
Timeline:
brugeren kommer ind på din side (form1) indstaster data i tekstboksene og submitter du opretter et object der indeholder brugerens data du sender brugeren videre til form2 med hans indtastede data så han kan tjekke en ekstra gang du bruger det object du oprettede under punkt3 til at sende en email emailen du sender indeholder ikke noget data
You see, there's something missing here. Det object du oprette under punkt 3 findes ikke under punkt 5, da vi er i to forskellige kontekst. Du bliver altså aktivt nødt til at gemme dit object så det kan tilgås på tværs af dine request's, og som sagt kan det gøres på tre forskellige måder. Application, Session eller ViewState. Personligt vil jeg gemme det i session:
Gem: Session["contact"] = o; Hent: Object_Kontakt o = (Object_Kontakt)Session["contact"];
cyberfessor, det funker jo som en drøm... Tak! Jeg ved godt at jeg skrev at jeg helst ville undgå sessionobjekter, men der mente jeg den gængse .asp-måde, hvor man opretter et objekt for hver værdi i formularen og derefter skal trække dem ud én efter én.
Den måde du skrev er sgu god da jeg på den måde kun skal koncentrere mig om et enkelt objekt.
Hehe, ja det kan ses :-) Glæder mig til at dykke dybere ned i det.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
