0

I was having a bit of a problem serving up a dot xhtml page using hypnotoad.

the xhtml file starts off like this so perhaps I am not declaring something that would allow hypnotoad to display it as something other than text when I head over to localhost port 8080.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta http-equiv="Content-Type" content="http://www.w3.org/1999/xhtml; charset=utf-8" />
        <title>
            Index
        </title>
        <link rel="stylesheet" href="book.css" type="text/css" />

When I just open up the page locally without a server in the middle it renders fine in Firefox, but when I created a myapp.pl and stuck it in a sub-folder by the name of public it serves it up but only as text on port 8080.

Any help would be appreciated.

Nicholai
  • 3
  • 1

1 Answers1

0

I'm not too familiar with Perl, certainly not it's headers though you could try the following...

require HTTP::Headers;
$h = HTTP::Headers->new;
$h->header('Content-Type' => 'application/xhtml+xml');

Of course you'll need to check if the client supports XHTML via the client's accept header. Keep in mind that Microsoft thinks IE7 literally supports . which is wildly far from the truth.

I serve XHTML as application/xhtml+xml at my site and use PHP so if you're familiar with that and Perl this may help bridge it a bit easier...

if (isset($_SERVER['HTTP_ACCEPT']))
{
 if (stristr($_SERVER['HTTP_ACCEPT'],'application/xhtml+xml'))
 {
  header('Content-Type: application/xhtml+xml');
 }
 else {header('Content-Type: text/html');}
}

I'm not sure what Perl's equivelant of PHP's include('file.pl'); would be though you want good structure.

_0_header_0 // Your primary header file that starts the includes tree, so-to-speak.

_0_header_1_base // Determines relative and absolute path for BOTH local/live server so the EXACT same code runs on local/live servers.

_0_header_2_sql // Connect to your database to be able to fetch content.

_0_header_3_sessions // Sessions, e.g. signed-in members/admins/etc, should be handled at this point.

_0_header_4_classes // Establish your programming classes here.

_1_functions_date // Site-wide functions such as converting Unix Epoch in to human readable date, other functions, etc. ...

_2_includes_01_xml // At this point you are no longer able to send headers.

_2_includes_02_dtd

_2_includes_03_head

_2_includes_04_title

_2_includes_05_meta_0

_2_includes_05_meta_01_description

_2_includes_05_meta_02_keywords

_2_includes_05_meta_03_language

_2_includes_05_meta_04_robots

_2_includes_05_meta_05_redirect

_2_includes_06_base // Use the base element to set the default base path.

_2_includes_07_css

_2_includes_08_js // Never put JavaScript in the body element or you will have a horrid mess.

_2_includes_09_body

...

I'm also not familiar with Hypnotoad HTTP server (though I get the Futurama reference). Ideally you want to do what is akin to Apache rewrites and have the content served by main handlers. In essence a file in another directory will serve the content sometimes...for which there is no actual directory, at least for custom pages. When you have established modules (e.g. blog, email, forums) you'd simply move the main handler files to that.

It's a general approach that I could spend hours getting in to though it's intended more of as a direction. I was doing single files with hoards of includes and was uncomfortable with things like databases for reasons such as not being able to quickly copy a folder and say the site was backed up. As long as you have some good backup system in place build such an approach as a new version and attempt to break things down to smaller versions. When you do have a fundamentally different approach code wise it's okay to have a version that might be months to a year or two to release. Just keep refining it over and over and over and push yourself for high standards (e.g. XHTML as application/xhtml+xml with Firefox (since other browsers won't give hide the page and give you the error outright). This has all been my general approach and now I have my own web platform that can run circles around all the other platforms I've seen for doing the things I need, want and will eventually to do.

John
  • 1
  • 13
  • 98
  • 177
  • I figured it out. `#!/usr/bin/env perl use Mojolicious::Lite; any '/' => sub { my $c = shift; $c->res->headers->content_type('application/xhtml+xml'); $c->res->content->asset( app->static->file('index.xhtml') ); $c->rendered(200); }; app->start;` This seems to render my index.xhtml page properly but all other dot xhtml pages that are linked from it still render as text. Wondering what else I would have to add to the perl file. Or perhaps I can add something to the top of each individual xhtml page so that the browser treats them as html and renders properly – Nicholai Aug 19 '14 at 22:34
  • Pardon me if I'm wrong about the following: do you have a universal header includes? All requests (GET, POST, DELETE, PUT, etc) should be handled and all headers (including media type/mime) should be handled there (except for some exceptions). Years ago I did a per-page headers if anything...in PHP you simply use `include('file.php');` or `include_once('file.php');` and the effects of that file, it's functions, etc are all inherited. Of course my system is Apache rewrites so it starts with headers and *then* figures out what resources to `include` and use. – John Aug 20 '14 at 10:08
  • No need for pardons my good man, but I would appreciate any further clarification you could offer. Where would this universal header includes theoretically go? I had this theory that the only reason the dot xhtml files weren't being rendered was because of something that was not included in their very code, something that perhaps tells the browser, yah this is an xhtml file, but render it as html. Somewhere at the top perhaps. I went down a rabbit hole on the W3C site but didn't really get anywhere. – Nicholai Aug 20 '14 at 10:58
  • The header file is the FIRST file include you make for *everything*. You will have to make exceptions for certain things over time though you can not realistically setup individual files (content-wise) to handle each page. Header file eventually extends downwards until you literally have ` – John Aug 21 '14 at 06:37
  • Updated my answer with the file structure (e.g. headers, functions and XHTML output) to give you a sense of approach. Keep in mind it is blatantly *not* the standard approach of most developers that dump fifty "standard" files inside of thirty "standard" folders. If you want an actual live website example see my site in my profile, use Firefox, right-click, View Page Info and you'll see the magical `application/xhtml+xml` mime. :-) – John Aug 21 '14 at 06:54
  • I've found the HTTP::Headers thing on CPAN. It's apparently pre-installed and I already had it, so I think what I will try to do is stick it at the top of the Perl file so that Perl knows to use it. The second block of code you put up is in PHP as I understand it so I will have to try and translate it over the course of learning Perl. – Nicholai Aug 21 '14 at 07:34
  • I just wanted to throw a couple of static pages up all linking up to each other, nothing fancy or dynamic. The thing that makes it tricky is apparently that these files are xhtml. I got them from an ebook by renaming the end of the file .zip and extracting them for use as templates, then rebuilt them from the ground up and thought I would make my own ebook but decided it would be cooler if I had a website where the homepage was a table of contents and then linked to various other writings. Thanks for all the help John, I will print this page and study it for new insights. – Nicholai Aug 21 '14 at 07:35
  • If they are static pages (e.g. no Perl) then having *example.xhtml* with a *.xhtml* file extension will typically (AFAIK) be served as application/xhtml+xml (and probably won't be rendered as text/html in IE8 and lower). Glad to help. :-) – John Aug 22 '14 at 08:43