[ASP.NET] Scheiding code/layout

[Verwijderd]

Wat zijn de mogelijkheden? Ik kon op dit onderwerp slechts één draadje vinden en daar stonden niet echt goede oplossingen naar mijn mening. Ik heb een aantal mogelijkheden mbt dit onderwerp hieronder kort beschreven.

Custom template engine
Dit is een methode die ik veel tegenkwam in de tijd dat ik websites ontwikkelde in php. Je ontwikkelt (of download) een class die niets meer doet dan bestandjes inlezen en zogenaamde "template variabelen" tussen bijv. { en } vervangt met de op te geven waarden. Dit is wel een volledige scheiding tussen code en layout, maar het past niet echt in het idee van Microsoft, omdat je alleen nog maar gebruik maakt van de Code-behind classes. Een nadeel is is dat je vaak ontelbaar veel templates krijgt.

ASP.NET User Controls
Persoonlijk vind ik dit geen goede oplossing, omdat je dan gebruik maakt van het code-behind model van Microsoft wat geen (goede) scheiding is van code en layout. In het topic wat ik gevonden had met de search had wel een redelijke oplossing, maar ik kan dat topic niet meer naar voren halen, omdat ik alleen maar "This page cannot be displayed" meldingen krijg als ik de search gebruik...

Eeuuhh..
Nog meer ideeën?

[NMe]

Je kan toch ook ASP je template engine laten zijn? Maak een file aan met al je logica erin, en daarin zet je alle variabelen die je nodig gaat hebben. Vervolgens include je je template files (gewoon ASP bestanden) waarin HTML staat, met op de plaats waar je een variabele nodig hebt een <% Response.Write varnaam %>. In PHP werkt dit, en volgens mij moet het in ASP ook geen probleem zijn, ook al is de manier van includen anders.

[maikel]

Verwijderd schreef op woensdag 24 november 2004 @ 21:23:
Wat zijn de mogelijkheden? Ik kon op dit onderwerp slechts één draadje vinden en daar stonden niet echt goede oplossingen naar mijn mening. Ik heb een aantal mogelijkheden mbt dit onderwerp hieronder kort beschreven.

ASP.NET User Controls
Persoonlijk vind ik dit geen goede oplossing, omdat je dan gebruik maakt van het code-behind model van Microsoft wat geen (goede) scheiding is van code en layout. In het topic wat ik gevonden had met de search had wel een redelijke oplossing, maar ik kan dat topic niet meer naar voren halen, omdat ik alleen maar "This page cannot be displayed" meldingen krijg als ik de search gebruik...

Hoezo heb je bij gebruik van de CodeBehind geen scheiding tussen code en layout?
In je aspx/ascx-file staat heel je layout en in de bijbehorende cs/vb-file staat je code.

Alle code voor bijv. de businesslogic kun je in aparte classes stoppen die je vanuit de codebehind-pagina aanspreekt.

[Alex]

Het hele doel van de code behind in ASP.NET is dat je de voorkant vult in je code behind.
Als je de scheiding van Code en HTML zelf goed wete te maken dan zul je zien dat je inprinciepe niets in de code behind met html hoeft te doen.
Dit is voordelig aangezin je niet opnieuw hoeft te compilen als je de aspx/ascx file aanpast. Als je de cs/vb file aanpast zul je opnieuw moeten compilen én in het geval dat je niet op de server host wara je compiled, zul je een nieuwe dll moeten uploaden. Met alle gevolgen van dien.

Daarnaast kun je in elke pagina via je code behind weer extra controls laden zodat je nooit, maar dan ook nooit extra functionaliteit gaat bouwen direct in je Code behing, maar samen met een stukje HTML aan de voorkant.

Ik denk dat je wel iets over een klepel gehoord hebt, maar de bel...?!

[gorgi_19]

Master Pages \o/

Verder heeft MS imho de koppeling met .aspx icm .aspx.vb ontzettend brak opgezet; je kan imho beter met server controls werken en die op de HTML plakken (of vanuit de code laten controleren of een control aanwezig is, en die binden). Zo voorkom je een sterke koppeling tussen de .aspx en .aspx.vb / .aspx.cs

[Verwijderd]

-NMe- schreef op woensdag 24 november 2004 @ 21:31:
Je kan toch ook ASP je template engine laten zijn? Maak een file aan met al je logica erin, en daarin zet je alle variabelen die je nodig gaat hebben. Vervolgens include je je template files (gewoon ASP bestanden) waarin HTML staat, met op de plaats waar je een variabele nodig hebt een <% Response.Write varnaam %>. In PHP werkt dit, en volgens mij moet het in ASP ook geen probleem zijn, ook al is de manier van includen anders.

Zelfs dan heb je nog redelijk wat asp tags erin zitten (teveel naar mijn mening) en dan vind ik de eerste oplossing toch nog beter, want je moet niet vergeten dat de templates ontwikkelt moeten worden door een niet programmeur...

gorgi_19 schreef op donderdag 25 november 2004 @ 10:07:
Master Pages \o/

idd. helaas mag ik geen websites uitleveren aan klanten die zijn ontwikkelt met een beta produkt

[NMe]

Verwijderd schreef op donderdag 25 november 2004 @ 18:52:
Zelfs dan heb je nog redelijk wat asp tags erin zitten (teveel naar mijn mening) en dan vind ik de eerste oplossing toch nog beter, want je moet niet vergeten dat de templates ontwikkelt moeten worden door een niet programmeur...

Die ASP tags bevatten alleen een print van een variabele, dat vreet een designer verder wel hoor.

[Verwijderd]

-NMe- schreef op donderdag 25 november 2004 @ 18:56:
[...]

Die ASP tags bevatten alleen een print van een variabele, dat vreet een designer verder wel hoor.

en loops? of wil je daarvoor dan usercontrols maken?

[ Voor 9% gewijzigd door Verwijderd op 25-11-2004 21:29 ]

[Verwijderd]

gewoon user controls '/ web controls gebruiken, of zelf een simpele parser schrijven. Ik gebruik een soort XML systeem, omdat de klant zelf zijn uiterlijk via XML kan aanpassen zonder bij de code te hoeven, werkt prima.

[TlighT]

Verwijderd schreef op donderdag 25 november 2004 @ 18:52:
[...]
idd. helaas mag ik geen websites uitleveren aan klanten die zijn ontwikkelt met een beta produkt

Je weet toch dat er ook masterpages implementaties zijn die werken met het huidige framework? Bijvoorbeeld hier en hier.

Verder is er nog de .NET port van Velocity (een veelgebruikte Java templating engine). In combinatie met bijvoorbeeld Maverick.NET (=MVC+Front Controller) heb je een echt stricte scheiding tussen presentatie en bl (maar je kunt dan ook geen server controls meer gebruiken).

[ Voor 23% gewijzigd door TlighT op 25-11-2004 23:41 ]

[Verwijderd]

Volgens mij ben je er al door xslt te gebruiken voor je niet edit schermen en naast je standaard editschermen, maak je een nieuwe (voor de andere layout) ASPX met dezelfde controls als je standaard editscherm, overerven van je standaard edit scherm en je kan alles helemaal anders neerzetten.

[Alex]

Verwijderd schreef op donderdag 25 november 2004 @ 21:29:
[...]


en loops? of wil je daarvoor dan usercontrols maken?

Dat is mogelijk, maar je gaat één stapje te ver! Ik werk atm met een CMS Sitecore en het gave daarvan is dat je heel mooi je .Net spul in je code behind duwt. De controls zitten in de ascxjes die sleepbaar n bewerkbaar zijn via een cliënt. Daarmee is gelijkd e grote grap dat je volledige HTML control hebt(et zaken als simpele itemTemples die voor zich spreken).
Een usercontrol maken is echt heel erg stom. Je loopt dan immers je doel vorobij. Zelfs het doel van HTML. Aangezien HTML(in samenwerking met CSS) voor de opmaka is en je code behind(de .vb/.cs) voor 'het vullen'. Daarbij laat je een klant toch niet aan HTML komen? Bij ons komen enkel de developers aan de HTML die ze aan ons programmeurs leveren.
En op het momnt dat je HTML schrijft met je Code behind zit je ook fout.

Ik merk dat veel mensen op die manier over ASP.Net oordelen. Maar wta ik bij die mensen op hun beurt mis is dat ze niet snappen waar HTML voor is. Eigenlijk een veredelde opmaaktaal.
Ovrigens zijn er zeker verbeteringen mogelijk aan ASP.Net, denk maar eens aan de HTML die neergedumpt wordt. Daarnaast zijn je postbacks vrij vaak niet meer valide in een nested control, of je moet ze op jouw beurt weer per control gaan afhandelen(wat ook wel weer handig kan zijn). Maar dat nemt niet weg dat het voor ontwikkelaars op dit moment in mijn ogen de beste 'tool' is.
Daarnaast moet je niet vergeten dat er eigenlijk geen taal is met een dergelijke krachtige IDE als Microsoft heeft gemaakt met het naampje Visual Studio.

[Verwijderd]

gorgi_19 schreef op donderdag 25 november 2004 @ 10:07:
Master Pages \o/

Verder heeft MS imho de koppeling met .aspx icm .aspx.vb ontzettend brak opgezet; je kan imho beter met server controls werken en die op de HTML plakken (of vanuit de code laten controleren of een control aanwezig is, en die binden). Zo voorkom je een sterke koppeling tussen de .aspx en .aspx.vb / .aspx.cs

Brak opgezet? Ik geef toe dat het model in .NET 1.x minder aantrekkelijk is als het model wat ze in 2.0 beta 1 op dit moment hebben, maar ik zie niet in waarom dit brak is. De "sterke koppeling" lijkt me vrij logisch. Ik vraag me af hoe jij de ideale scheiding tussen layout en code ziet.

Server controls hebben vrijwel niets te maken met deze discussie. Server controls gebruik je (normaal gesproken) als herbruikbare, generieke controls. Dit kan bijvoorbeeld een TreeMenu zijn, waar je geen keuze maakt wat betreft de datasource/opmaak/etc.

Usercontrols daarentegen gebruik je meestal voor applicatie-specifieke dingen en zijn doorgaans niet/minder herbruikbaar. Ze hebben een "layout" en "code" deel. In de "layout deel" kun je declaratief controls toevoegen aan de control hierarchie, etc. Dit zijn dingen die prima gedaan kan worden door clientside devs.
De logica achter de controls (/het design) kan in de codebehind geimplementeerd worden.

[Verwijderd]

Ik gebruik veel html-controls met runat="server". bv:

code:

<div id="divInfo" runat="server"></div>

Ik vind dat erg relaxed werken en ook onze grafisch vormgever snap het allemaal nog wat er gebeurd. Het enige nadeel van html-controls is dat ze standaard enorm veel viewstate vragen en dat ze geen property hebben om het uit te zetten.

[Verwijderd]

Verwijderd schreef op vrijdag 26 november 2004 @ 21:13:
Ik gebruik veel html-controls met runat="server". bv:

code:

<div id="divInfo" runat="server"></div>

Ik vind dat erg relaxed werken en ook onze grafisch vormgever snap het allemaal nog wat er gebeurd. Het enige nadeel van html-controls is dat ze standaard enorm veel viewstate vragen en dat ze geen property hebben om het uit te zetten.

Hoe kom je erbij dat dit soort html controls gebruik maken van van de viewstate? Ook al zouden ze daar gebruik van maken, zou je de property EnableViewState op false kunnen zetten. De basis klasse van alle controls is namelijk Control, en deze klasse heeft de property EnableViewState.

[ Voor 5% gewijzigd door Verwijderd op 26-11-2004 21:38 ]

[eghie]

Verwijderd schreef op vrijdag 26 november 2004 @ 21:13:
Ik gebruik veel html-controls met runat="server". bv:

code:

<div id="divInfo" runat="server"></div>

Ik vind dat erg relaxed werken en ook onze grafisch vormgever snap het allemaal nog wat er gebeurd. Het enige nadeel van html-controls is dat ze standaard enorm veel viewstate vragen en dat ze geen property hebben om het uit te zetten.

Verwijderd schreef op vrijdag 26 november 2004 @ 21:37:
[...]


Hoe kom je erbij dat dit soort html controls gebruik maken van van de viewstate? Ook al zouden ze daar gebruik van maken, zou je de property EnableViewState op false kunnen zetten. De basis klasse van alle controls is namelijk Control, en deze klasse heeft de property EnableViewState.

En anders gebruik je gewoon <asp:Panel> control, dat is wel gewoon een serversite control wat eig gewoon een divje is.

[MisterData]

Alex de Groot schreef op vrijdag 26 november 2004 @ 18:03:
[...]

Daarnaast moet je niet vergeten dat er eigenlijk geen taal is met een dergelijke krachtige IDE als Microsoft heeft gemaakt met het naampje Visual Studio.

offtopic:
Om hier even kort op in te gaan: voor Java (en dus JSP) is er een IDE die misschien nog wel krachtiger is dan VS.NET: Eclipse. Heeft onder andere ontzettend goede ondersteuning voor refactoring en dergelijke, wat ik in VS.NET nog niet ben tegengekomen

[Alex]

MisterData schreef op vrijdag 26 november 2004 @ 21:43:
[...]

offtopic:
Om hier even kort op in te gaan: voor Java (en dus JSP) is er een IDE die misschien nog wel krachtiger is dan VS.NET: Eclipse. Heeft onder andere ontzettend goede ondersteuning voor refactoring en dergelijke, wat ik in VS.NET nog niet ben tegengekomen

Ben het met je eens.. Maar de ondersteuning van JSP is nog niet halverwege de ondersteuning die er inmiddels al is voor ASP.Net. Enkel specialistische bedrijven ontwikkelen in JSP. Wij hebben op dit moment bij ons op het werk zelfs maar 2 met ervaring met JSP... op de 17 engineers...

[Verwijderd]

Alex de Groot schreef op zaterdag 27 november 2004 @ 11:33:
Enkel specialistische bedrijven ontwikkelen in JSP. Wij hebben op dit moment bij ons op het werk zelfs maar 2 met ervaring met JSP... op de 17 engineers...

Tsja, als je een .Net bedrijf bent zul je weinig JSP kennis aantrekken. Hetzelfde geldt omgekeert, bij een bedrijf dat veel met JSP werkt zul je hard moeten zoeken naar programmeurs met .Net ervaring. Toch is JSP niet minder krachtig dan ASP.NET en is ook daar een goede scheiding van code en layout mogelijk mbv van zaken als Struts.

[Alex]

Verwijderd schreef op zaterdag 27 november 2004 @ 11:54:
[...]


Tsja, als je een .Net bedrijf bent zul je weinig JSP kennis aantrekken. Hetzelfde geldt omgekeert, bij een bedrijf dat veel met JSP werkt zul je hard moeten zoeken naar programmeurs met .Net ervaring. Toch is JSP niet minder krachtig dan ASP.NET en is ook daar een goede scheiding van code en layout mogelijk mbv van zaken als Struts.

Wij zijn niet een echt .Net bedrijf. Wat je zegt over JSP is waar, maar wat ik bedoelde is eigenlijk de mogelijkheid om het bijvoorbeeld shared te laten hosten. Of de mogelijkheden om het te draaien. Ik zeg niet dat die er niet zijn, maar die zijn er gewoon veel minder. Zeker hier in Nederland. Zonder daar een waarde oordeel aan vast te hangen door te zeggen wat er beter is.
Mijn idee over dit soort zaken is: Elk taal heeft een bepaald doel/is in te zetten voro een bepaald doel. Daarin onderscheiden ze zich van elkaar.