Many praise the .Net framework because of the possibility of making object oriented web applications based on an n'tiered software design.<BR>But in my search for the optimal way of maintaining and reusing the website user interface (the presentation layer) I have run into two ways of doing so, each with different advantages over normal scripting code, but without being compatible with each other. My question is: is there a solution to this problem?<BR><BR>1. Separating designers from developers.<BR>One praised way of coding with .Net is the use of codebehind files that takes care of the business logic, while the aspx-page itself contains the presentation - the webdesign. This gives makes work differentiation much easier between developers and designers, since they don't have to work on the same files any more. On the aspx-page the designer uses user controls and styles them and combines them the way he wants, and the developer provides the content for these user controls in a compiled code-behind file.<BR>But how does one then maintain a consistent and easily updated general template design of all pages, when each page needs to be designed by combining different user controls?<BR><BR>2. Templates through page inheritance.<BR>To achieve this general template one can create a new class that inherits from the page class and contains the general design, but makes room for 'placeholders' (specific page content). Then each codebehind file inherits from this pagetemplate and adds the specific controls or whatever in the relevant placeholders. <BR>But this approach looses the work differentiation advantage of the first approach since now the html/xml tags are no longer separated from the high level server language and are much more difficult to understand and maintain.<BR><BR>So is there a way around this paradox, and if not, which approach would you take?
Page Template Paradox - separating design and cont
- Thread starter StanXG
- Start date