Protean web framework
March 26, 2012 12:53 PM Subscribe
Is there a web framework/toolset that can handle (consistently) the whole spectrum from static content to full applications?
I've inherited a website that's all over the place -- much of it is straight HTML, but there are also a lot of PHP pages of varying complexity, ranging from little bits of inline code to full-blown applications, as well as CGI (mostly Perl), some Java apps (via mod_jk), and a smattering of other technologies.
Each of these pieces was arguably a good choice for its particular need -- no point in invoking a full framework for straight static content, for example -- but this fragmentation is visible from the outside as inconsistency in look and behavior, leading to an unpolished and unprofessional user experience, so I'd like to start bringing things into a common framework.
My experience is coming more from the back end, so the systems I know (Django, Rails, SpringMVC, etc) are predicated on the idea that the app is running things and individual pages are just for surfacing its data. And while they "support" static content, they don't do it particularly well IMO. That really won't work here -- there is a lot of static/mostly static content, and it can't be treated as an afterthought.
Meanwhile, while I've never really liked PHP, in part because I haven't seen it work well for full-blown apps, its model of code injected into a page does work well for static content that might have just a couple bits of dynamic data in it.
So what I'm looking for is something that can work well at both ends of the spectrum as well as points in between, eg:
* Totally static page (but headers/footers/nav should be data-driven)
* Static page with a couple bits of dynamic content
* Dynamic content with full app functionality (eg. sessions, etc) but still driven by the page
* Typical MVC stack
My go-to for web development is Django, so my current approach basically a version of the staticfiles app that maps to any .html file in the public document path and processes it as a template, so "static" files can invoke Django template tags, but this runs into the reasons the staticfiles app is discouraged for production deployments. I like the idea of Hyde, allowing static-but-data-driven pages to be produced by an app but served by something like Apache, but I'd need something like this to work "on demand" rather than replacing the application server.
The other option I see is to accept that PHP does its thing well and stick with that for the simple cases, and basically try to build the common libraries into more of a framework.
Any thoughts / suggestions?
I've inherited a website that's all over the place -- much of it is straight HTML, but there are also a lot of PHP pages of varying complexity, ranging from little bits of inline code to full-blown applications, as well as CGI (mostly Perl), some Java apps (via mod_jk), and a smattering of other technologies.
Each of these pieces was arguably a good choice for its particular need -- no point in invoking a full framework for straight static content, for example -- but this fragmentation is visible from the outside as inconsistency in look and behavior, leading to an unpolished and unprofessional user experience, so I'd like to start bringing things into a common framework.
My experience is coming more from the back end, so the systems I know (Django, Rails, SpringMVC, etc) are predicated on the idea that the app is running things and individual pages are just for surfacing its data. And while they "support" static content, they don't do it particularly well IMO. That really won't work here -- there is a lot of static/mostly static content, and it can't be treated as an afterthought.
Meanwhile, while I've never really liked PHP, in part because I haven't seen it work well for full-blown apps, its model of code injected into a page does work well for static content that might have just a couple bits of dynamic data in it.
So what I'm looking for is something that can work well at both ends of the spectrum as well as points in between, eg:
* Totally static page (but headers/footers/nav should be data-driven)
* Static page with a couple bits of dynamic content
* Dynamic content with full app functionality (eg. sessions, etc) but still driven by the page
* Typical MVC stack
My go-to for web development is Django, so my current approach basically a version of the staticfiles app that maps to any .html file in the public document path and processes it as a template, so "static" files can invoke Django template tags, but this runs into the reasons the staticfiles app is discouraged for production deployments. I like the idea of Hyde, allowing static-but-data-driven pages to be produced by an app but served by something like Apache, but I'd need something like this to work "on demand" rather than replacing the application server.
The other option I see is to accept that PHP does its thing well and stick with that for the simple cases, and basically try to build the common libraries into more of a framework.
Any thoughts / suggestions?
Best answer: From what I've seen, handling various levels of static vs. dynamic content is done through intelligent caching of partial templates. In other words, go ahead and use whatever framework you like, behind a webserver like nginx or Apache for straight static content, and figure out partial template caching.
But first, check that treating mostly static templates as normal templates is actually a performance issue. I'm sceptical that is.
posted by fatbird at 1:27 PM on March 26, 2012
But first, check that treating mostly static templates as normal templates is actually a performance issue. I'm sceptical that is.
posted by fatbird at 1:27 PM on March 26, 2012
ExpressionEngine, which is based on CodeIgniter seems like it would be a good solution. You could could create templates to keep everything looking the same, put your static content into the EE database, then use static templates to call in the other dynamic content. Then start going through each bit of dynamic content and updating as needed.
posted by dawkins_7 at 1:45 PM on March 26, 2012
posted by dawkins_7 at 1:45 PM on March 26, 2012
Uhm, define "static". I mean, in Rails there's nothing keeping you from having a views folder filled with .html files. If you've got content that really should never change (yet could still benefit from being wrapped inside a layout) I don't see why Rails can't help you.
posted by pmv at 2:02 PM on March 26, 2012
posted by pmv at 2:02 PM on March 26, 2012
I don't see anything wrong with your current approach. Before you mentioned you used Django at the end of your question, I was going to recommend using it. But what's that you say about staticfiles being discouraged for production? I haven't seen that before. It's been part of the main Django distribution since 1.3, so I assume they consider it production-ready.
posted by zsazsa at 2:28 PM on March 26, 2012
posted by zsazsa at 2:28 PM on March 26, 2012
Response by poster: Thanks for all the responses. I was worried that this might be too broad/vague to get any feedback, so I'm glad to see it.
Foci, one of your links looks pretty much exactly like my current approach, which makes me think I'm not on a completely wrong track.
fatbird, I'm guessing you're talking from a Rails context. It looks like Rails has more capability here than Django (since its include mechanism doesn't really have an obvious caching strategy) -- I'll definitely look into this a bit more. I agree that I shouldn't assume too much about the cost of template processing -- apparently CodeIrony agrees. But I'd also like to avoid all that other non-template overhead as well -- in theory it might just be request routing and file reads, but I think middleware might be a big grey area.
dawkins_7, I've actually used EE (although not as a developer) and evaluated a few CMS solutions, and I rejected all of them because they treat static content in one way (markup edited as rich text and stored in a db) and dynamic content in a completely different way (as an html/custom-tagged template stored in a file or embedded in the application). My whole problem is that most of my pages straddle the line between the two, so I can't have wholly different solutions for each. Am I misunderstanding what EE offers?
pmv, I haven't seen that -- in the typical case there's a public path with static files in it. I'm guessing this is for the same reason that Django does something similar -- because the application layer isn't really geared to serve static content in a serious way, and expects a dedicated server like Apache to handle it. Am I just reading too much into this convention?
zsazsa, I'll look into it some more but my understanding was that staticfiles was provided for development, and in fact will refuse to even run in production without some explicit config changes.
posted by bjrubble at 2:46 PM on March 26, 2012
Foci, one of your links looks pretty much exactly like my current approach, which makes me think I'm not on a completely wrong track.
fatbird, I'm guessing you're talking from a Rails context. It looks like Rails has more capability here than Django (since its include mechanism doesn't really have an obvious caching strategy) -- I'll definitely look into this a bit more. I agree that I shouldn't assume too much about the cost of template processing -- apparently CodeIrony agrees. But I'd also like to avoid all that other non-template overhead as well -- in theory it might just be request routing and file reads, but I think middleware might be a big grey area.
dawkins_7, I've actually used EE (although not as a developer) and evaluated a few CMS solutions, and I rejected all of them because they treat static content in one way (markup edited as rich text and stored in a db) and dynamic content in a completely different way (as an html/custom-tagged template stored in a file or embedded in the application). My whole problem is that most of my pages straddle the line between the two, so I can't have wholly different solutions for each. Am I misunderstanding what EE offers?
pmv, I haven't seen that -- in the typical case there's a public path with static files in it. I'm guessing this is for the same reason that Django does something similar -- because the application layer isn't really geared to serve static content in a serious way, and expects a dedicated server like Apache to handle it. Am I just reading too much into this convention?
zsazsa, I'll look into it some more but my understanding was that staticfiles was provided for development, and in fact will refuse to even run in production without some explicit config changes.
posted by bjrubble at 2:46 PM on March 26, 2012
Best answer: Whoops. I was confusing staticfiles and flatpages. Yes, using django's django.contrib.staticfiles.views.serve isn't what you want, as it's definitely isn't for production, like you said. Sorry about that.
However, making a simple wrapper view that exposes a directory tree of .html files that use Django's template language would be pretty trivial. Here's an app someone wrote that does just that. And, bonus, it actually seems to let you reverse URLs that it's responsible for.
posted by zsazsa at 3:01 PM on March 26, 2012
However, making a simple wrapper view that exposes a directory tree of .html files that use Django's template language would be pretty trivial. Here's an app someone wrote that does just that. And, bonus, it actually seems to let you reverse URLs that it's responsible for.
posted by zsazsa at 3:01 PM on March 26, 2012
Response by poster: Thanks, django-staticpages looks like a great starting point! Not sure how I missed it before.
posted by bjrubble at 3:32 PM on March 26, 2012
posted by bjrubble at 3:32 PM on March 26, 2012
This thread is closed to new comments.
posted by Foci for Analysis at 12:59 PM on March 26, 2012