I’ve been thinking a bit about the different ways platforms handle html and web content recently. Probably because I’m right in the middle of working on my company’s Customer Center and struggling to shift from the work I’ve done recently in PHP to the ASP.Net platform my company uses.
PHP supports a model that’s a lot closer to the way I think, though I don’t know if it’s actually a good model. You create your page, include other pages to fill in chunks of that page (like loading the header and footer) and, when needed, slap in some code amidst the page itself to dynamically load pieces. If you need a person’s name to appear in the top of the page when they’ve logged in, you can just put in the function call to getUserName(); and whatever that function returns gets put into the page. It’s a very procedural way of thinking through your page, and it’s comfortable.
ASP.Net – the default way, not their newer Model-View-Controller pattern – does things in this weird hybrid way that’s a totally uncomfortable way of thinking. You still create your base page – index.aspx or whatever – and into that page you can stick includes for other code and you can also call a templated header/footer file like you would in PHP. But the implementation is oddly circular. In an effort to avoid a separate header and footer file, ASP.Net uses Master Pages. Unlike PHP, you don’t get to say, on the page itself, “Stick the header here, then do this other stuff, then stick the footer here.”
Instead you build a Master Page that you lay out like a normal page, except that where the content would go, you put an asp:contentplaceholder tag. Then, at the top of the actual page, when you’re declaring the namespace for the page and where the code file lies, you say, essentially “Use this Master Page” which tells ASP.Net to take everything you wrote on the actual page and shove it into the place where the contentplaceholder tag is sitting. It makes a sort of sense, but it forces you to think about the page layout from two different directions, and to build your actual code in a way that doesn’t map to the way the page will look when it’s done.
This isn’t helped by the fact that additional included code is done using User Controls, that feel like another type of file just to have a different type of file. I guess it’s comfortable if you need a certain amount of forced abstraction, but it makes for pages that are really hard to pick apart. Nor does the ASP.Net model of separating the HTML part of the page from the code itself help with the clarity. They’ve got a fancy term for it – Code Behind – but it just means more time figuring out what’s loading and in what order.
PHP’s model certainly does not reward clarity, nor does it punish obscurity, but my experience with ASP.Net is that it enforces a certain opacity that isn’t good for development. The model works – I’ve used it for years and gotten good work done with it – but it’s uncomfortable.
But is it wrong? Is PHP’s procedurally minded comfort just a crutch? And is Model-View-Controller, which I haven’t delved into yet, a help or is it just another flawed abstraction that confuses as much as it clarifies? The whole nature of web development is coming up with ways of building templates that we can easily shove different things into as we need. What works for you? Anything? Nothing?