0

I have been working on content management systems for about 7 years. 2 years ago created my own. Currently building a newew, better and bigger version.

However, fell into dilemma. I have a core file, that gets included to all pages. Core file makes sure of adding functions, config, mysql connection etc. I also have added Header("Content-Type: text/html; charset=UTF-8"); on the top of the code in the core file.

Recently I had to make a xml-generator, with Header("content-type: text/xml; charset=UTF-8");. First, of course I couldn't get the xml working, because I forgot about my content-type setting in the core file.. Later I just added the content-type: text/xml after the core file include..
Basically everything works, but I wish polish this project to the finest.

So I'm thinking now, is adding the "content-type: text/html" in the core file, a good idea?

I had an idea, to include the core file like this: include($rootpath . 'inc/core.php?content-type=xml');, then in the core file, the header will be set based on the $_GET['content-type'].. Is that a good solution?

2
  • Would it be a good characterization to say that your CMS deals with multiple kinds of responses and that you want set headers based on the kind of response you're serving? To me, it seems like a great problem to abstract to some interface or abstract class and then have the various concrete types of response implement the actual setting of headers.
    – Pelshoff
    Aug 16, 2011 at 21:36
  • @Pelshoff: Well, until now I've used the cms for html and similar type pages. However, xml-generator was a good example of the responsibility, that the core file has. However, adding content-types to each core-needs-included-files aka. "standalone files" does not seem that neat. Maybe having text/html in the core, and overriding it if needed, like with the xml-generator.. is still the neatest way? Aug 16, 2011 at 21:43

2 Answers 2

1

Instead of having the include() implicitly produce a bunch of stuff including header(), you could have it provide a startResponse() function which can take an array of extra headers to provide (useful if you also want to add e.g. cache-control, content-disposition, etc. at some point).

If you want to get really fancy you could probably have the include also call ob_start, have startResponse() call ob_end_flush() after it emits the headers, and then have an object (constructed in the include) have its __destruct call startResponse() if it hasn't been called already.

1

I don't like loose ends, so I will answer this question myself, based on my research and testing.

In a nutshell, YES it is a good idea in most cases. As you want to avoid adding it manually to every index file, that requires the core file. However, real question is.. how useful is setting the content-type and encoding in the first place...?! My experience has shown, that this can avoid possible problems in the future.

When you need to escape from the content-type text/html in index-file, that is actually XML. Simply add the new content-type after the core-file gets included.

Making a function, that sets the content-type is just extra space and doesn't really reflect on the functionality. If anything, it is not optimal solution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.