Jag håller just nu på att hårdstudera .NET-ramverket och kringliggande tekniker, främst VB.NET och tänkte ställa ett par frågor som jag vill ha ett par mänskliga svar på. Ibland är MSDN lite väl 'opartiskt' och jag vet att wF har bra resurser av .NET-folk som säkert kan hjälpa mig lite på traven. ;)
Jag är mestadels intresserad av information som berör version 2.0 av ramverket, då detta kommer att vara det jag inriktar mig på.
1. Jag har hört att 2.0 skall vara mycket mer inriktat på webb och mycket utvecklat mer åt det hållet än 1.1. Finns det några uppenbara fördelar/tekniker som kommer dyka upp i 2.0 som man bör lägga tid på att studera? Kommer 2.0 att vara lika 'event-driven' som 1.1, eller kommer det förändras, ur ett utvecklar-perspektiv?
2. Jag har kikat lite på Master Pages, som verkar vara det jag är mest intresserad av; att på ett enkelt sätt, som utvecklare, se till att dela upp min applikation i delar och lager, dels för skalbarhet och dels för att tillåta olika nivåer inom t.ex. ett utvecklarteam att arbeta på olika nivåer med samma applikation, utan att störas av varandras delar. Kommer Master Pages hjälpa mig som vill strukturera min applikation i logiska lager för fler utvecklare, eller är det mest fördelaktigt för HTML och gränssnitt (dvs som templates)?
3. Kan jag använda User Controls för att skapa t.ex. HTML-tabeller som beroende på parametrar visar olika data, t.ex. som att inkludera listor på olika databasinnehåll (produktlistor, kundkorgar) osv?
Jag är tacksam för all input. :) Jag har läst en del i forumet, men jag föredrar faktiskt att få svar på frågorna av någon/några medlemmar, då detta brukar ge mer klarsynthet.
1. Förändringarna i 2.0 är inte inriktade på webben i själva ramverket. Det är möjligt att man till 2.0 satsat mer på att förbättra ASP.NET än WinForms, men själva ramverket är inte inriktad på någon lösning. Det lilla jag sett av 2.0 så är det fortfarande eventbaserat och har svårt att tänka mig att det kommer att ändras.
2. Masterpage kommer inte hjälpa dig att dela upp din applikation i flera lager, det den hjälper dig med är att du enkelt kan byta ut olika templates på din website. Vill du dela upp din applikation i flera lager så att fler kan arbeta mot den samtidigt i olika lager så är det aritekturen av din lösning du skall titta på.
3. Förstår inte frågan riktigt, men visst kan du göra en UserControl som visar olika saker beroende på olika inputparameters, jag skulle dock inte råda dig till det. Det är bättre att ha 10 usercontroller som varje gör sin speciella sak, istället för att ha 1 som gör alla 10 saker. Du kan dock ha en 11 usercontrol som bestämmer vilken av de 10 som skall visas beroende på inputdata.
Det finns många förändringar i 2.0 och en av de bättre för ASP.NET är MasterPages och möjligheten till Templates, för själv ramverket så tycker jag Generics har störst fördelar.
MasterPages är väldigt bra men ingen nyhet i sig. Om någon missat mina tidigare inlägg angående detta här i forumet så kan jag ju tillägga att den enda nyheten med det är att nu är det inkluderat i ramverket. Men det finns redan idag och du kan använda det med 1.1.
Microsoft släppte ett demo för några år sedan. Det funkade inte så bra men flera har byggt vidare och utvecklat egna versioner, t.ex. Paul Wilson. Sök här i forumet på mina poster så står det en hel del.
Finns ingen anledning att vänta på 2.0 om man kan göra de bra sakerna redan idag. ;)
Särskilt som det nu verkar dröja till slutet av 2005 innan 2.0 kommer. Och det kan väl försenas igen om vi har otur.
2. Masterpage kommer inte hjälpa dig att dela upp din applikation i flera lager, det den hjälper dig med är att du enkelt kan byta ut olika templates på din website. Vill du dela upp din applikation i flera lager så att fler kan arbeta mot den samtidigt i olika lager så är det aritekturen av din lösning du skall titta på.
Nej, det vet är jag fullt medveten om. Kanske uttryckte mig lite klumpigt. Det är bara lite svårt att förklara vad jag vill få ut av det tror jag. ;)
Ju mer jag läser på om Master Pages, desto mer kommer jag fram till att de bara är till för layout. Jag hade någon slags vision där Master Pages var mer än bara för utseende, alltså ungefär som Controls, fast i större skala. Efter samtal med den goda erka har vi dock kommit fram till att så inte är fallet.
Gladh skrev:
3. Förstår inte frågan riktigt, men visst kan du göra en UserControl som visar olika saker beroende på olika inputparameters, jag skulle dock inte råda dig till det. Det är bättre att ha 10 usercontroller som varje gör sin speciella sak, istället för att ha 1 som gör alla 10 saker. Du kan dock ha en 11 usercontrol som bestämmer vilken av de 10 som skall visas beroende på inputdata.
Jo, återigen; självklart skall man väl ha en för varje ändamål. Jag undrar egentligen bara ifall det verkligen är rätt sätt att använda Controls till detta ändamål. Jag vill ge frihet (för t.ex. en designer) att flytta runt bitar/tabeller av applikationen lite som jag vill på sidorna.
PDahlen skrev:
MasterPages är väldigt bra men ingen nyhet i sig. Om någon missat mina tidigare inlägg angående detta här i forumet så kan jag ju tillägga att den enda nyheten med det är att nu är det inkluderat i ramverket. Men det finns redan idag och du kan använda det med 1.1.
Microsoft släppte ett demo för några år sedan. Det funkade inte så bra men flera har byggt vidare och utvecklat egna versioner, t.ex. Paul Wilson. Sök här i forumet på mina poster så står det en hel del.
Jo, jag har läst i bland annat din blog och andra sidor där Wilson's metoder beskrivs.
PDahlen skrev:
Särskilt som det nu verkar dröja till slutet av 2005 innan 2.0 kommer. Och det kan väl försenas igen om vi har otur.
Är inte det bara SQL Server'n (Yukon) som är försenad? Det handlar alltså om 2.0'an också?
Är inte det bara SQL Server'n (Yukon) som är försenad? Det handlar alltså om 2.0'an också?
Jo, det är SqlServer 2005 som är försenad. Men eftersom Visual Studio .NET 2005 är så när kopplad till SqlServer 2005 är VS.NET 2005 också försenat, om inte Microsoft, mot förmodan, skulle koppla loss de två.
Det innebär dock inte att själva ramverket 2.0 inte kommer tidigare, men då får man sitta och kompilera "för hand".
Möjligheten att köra Beta 2 versionen finns ju alltid, när den kommer, men personligen så avvaktar jag med skarpa projekt till skarpa VS.NET kommer.
Japp, som jag förstått MasterPage så är det endast till för layouten, alltså att man skapa en mall där man seda "plugar" in de andra sidorna i.
Nu har jag inte läst in mig på masterpage än, men om jag förstått det rätt så försvinner iden med UserControls när MasterPages kommer. Idag så kan man göra en sida, där man laddar olika controls beroende på vad man vill skall visas på sidan. På detta sätt så har man en fast definerad ram runt sina controls.
I och med MasterPags så blir MasterPagen din Mall och dins sidor blir som UserControls som man pluggar in i din masterpage, då försvinner iden lite med att ha en UserControl, eftersom du gör samma sak med en sida nu istället. Är det så att du har en Usercontrols som du vill återanvända i flera projekt så bör de göra som en ServerControls istället.
Men visst kan du ha en sida som implementerar en massa UserControls där du sedan låter designern själv kasta runt innehållet i dessa usercontrols, men det är ju inget nytt i 2.0 det kan man göra idag också, men jag misstänker att jag återigen missförstå vad du vill göra med dina UserControls.
Jag fortsätter med lite fler frågor i den här tråden. :)
Borde man samla alla codebehind's och ascx's på samma ställe, i t.ex. en rotmapp, eller skall man låta varje separat fil ligga tillsammans med sin relaterade aspx-fil? Om man har väldigt många user controls som ligger inom olika områden, så känns det som om det lätt kan bli rörigt.
Hur bör man göra om man vill låta en gränssnittsprogrammerare styra innehåll i en user control? T.ex. om han vill välja vilka kolumner som skall visas i en user-tabell, eller liknande saker. Skall man skapa någon slags config-metod för klassen i codebehindfilen (typ ConfigControl(foo,bar) ) Problemet är att personen i fråga inte skall ändra i ascx-filen, så var görs anropet?
Ska han ändra i aspx sidan? Jag hade byggt metoder/propertys i min ascx där han kunde skicka i antingen simple,medium,full och beroende på det visades x antal av kolumnerna. Eller så gör du en asp:table där varje kolumn motsvarar ett fält i user-tabellen, sedan kan han sätta visible=false/true på alla kolumner i tabellen. Det finns flera olika sätt att lösa det på, men jag förstod inte riktigt i vilken fil du vill att han ska ändra i.
Jag brukar låta mina codebehindfiler ligga kvar i den mapp de tillhör, alltså tillsammans med .aspx sidan. Sedan brukar jag ha en speciell mapp där jag lägger alla mina ascx filer i. Detta är dock en smaksak och man gör det som man trivs bäst med, finns inga regler/riktlinjer för det.
Angående din andra fråga så tror jag du komplicerar till det. Om du nu har 2 personer som skriver en ASPX sida, en som gör designen och en som gör codebehinden.
Så skall den som gör designen använda sig av serverkontroller på de kontroller som man vill göra tillgängliga i codebehinden.
Det är sedan upp till personen som kodar codebehinden att göra enables/disabled visible/hidden på de olika kontroller som inte behövs.
Själv personen som gör design sidan bör inte bestämma vilka kontroller som skall synas.
Om man nu skall använda 5 olka kontroller på sidan, och så bestämmer man att de 2 första skall vara synliga när man besöker sidan första gången och de andra skall vara dolda. Detta kan man lösa antingen genom att låta designerna gör visible=hidden på de kontroller som inte skall visas. Eller så låter du codebehind programmeraren göra det i Page_Load() och där sätta visible=hidden på de kontroller som inte skall visas.
Mitt förslag är att den person som gör designen INTE är ansvarig för vilka kontroller som skall visas/inte visas. Utan det är personen som gör codebehind som ansvara för att rätt kontroller visas vid rätt anrop till sidan. Och detta för att det passar bättre in i den aritektur som MS förespråkar att man använder när man vill bygga lite störresystem där man har ett UI Process layer under sina UI sidor som styr vilka, när och hur sidorna skall visas.
Jo, jag vill ju att han skall ändra i enbart aspx-filen. Han skall aldrig röra varken Codebehind eller User Controls.
Säg att jag har en User Control som jag vill skall visa en lista på t.ex. alla användare i systemet. Kanske vill jag låta killen som jobbar med mina aspx-filer bestämma ifall användare av typ 1 skall visas, eller kanske av typ 2, eller tillochmed alla? Hur ger han parametrarna till kontrollen utan att behöva skriva för mycket kod (ingen alls helst). För mycket begärt? ;)
Angående din andra fråga så tror jag du komplicerar till det. Om du nu har 2 personer som skriver en ASPX sida, en som gör designen och en som gör codebehinden.
Så skall den som gör designen använda sig av serverkontroller på de kontroller som man vill göra tillgängliga i codebehinden.
Det är sedan upp till personen som kodar codebehinden att göra enables/disabled visible/hidden på de olika kontroller som inte behövs.
Jo, fast om man nu vill konstruera ett system där designern skall kunna bestämma placering av olika saker i mina aspx-filer (t.ex. av kontroller), så vill man helst inte ha en programmerare som sitteroch gör hans 'designmässiga' ändringar i aspx-filen hela tiden. Det vill jag låta honom göra själv.
Designern skall ha tillgång till applikationens mallsidor (det finns en standardutgåva av alla aspx-filer) och skall sedan för varje specifikt uppdrag kunna ändra i dessa filer ganska fritt, däribland också flytta omkring kontroller och kanske också (om det nu är möjligt) ge dem en och annan parameter som påverkar presentation/funktionalitet i kontrollen, typ i min ascx-fil eller Codebehind. Dessa parametrar är givetvis förberedda för av programmeraren.
Jag vet inte om jag tänker fel visserligen. :r
303 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e
