Aaaaaand the logic (such as it is) for syntax stuff is pretty much is where I wanted it.

Still needs a pile of work, but like this, we can test mangling/highlighting engines seperately to the code which causes things to be highlighted, which is nice as you can replace highlighting strategy and individual highlighter implementations independently.

diff --git a/.gitignore b/.gitignore
index 44ce73e..f9fcc5d 100644 (file)
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,4 @@
-inc/
+./inc/
 Thumbs.db
 Gitalist-*
 *.swp

diff --git a/lib/Gitalist/Model/ContentMangler.pm b/lib/Gitalist/Model/ContentMangler.pm
index 400f629..1f48b57 100644 (file)
--- a/lib/Gitalist/Model/ContentMangler.pm
+++ b/lib/Gitalist/Model/ContentMangler.pm
@@ -1,7 +1,45 @@
 package Gitalist::Model::ContentMangler;
 use Moose;
+use MooseX::Types::Moose qw/HashRef/;
 use namespace::autoclean;
 
 extends 'Catalyst::Model';
 
+# FIXME - Never cleared!!
+has _languages => (
+    isa => HashRef,
+    is => 'ro',
+    default => sub { {} },
+    traits => ['Hash'],
+    handles => {
+        _add_language => 'set',
+        languages => 'keys',
+        css => 'values',
+    },
+);
+
+# FIXME This method is a gross hack.
+#
+# We need to work out what types of content mangles we have for various things based on hit type
+# file name and mime type, and perform the appropriate bits..
+
+# We need to support multiple languages, and we also want to be able to do HTMLizing (for e.g. Pod)
+
+sub process {
+    my ($self, $c) = @_;
+
+    # XXX Hack hack hack
+    my $language = $c->stash->{language} || '';
+    $language = 'Perl' if $c->stash->{filename} =~ /\.p[lm]$/i;
+    # FIXME - MOAR..
+
+    $self->_add_language($language, $c->uri_for('/static/css/syntax/' . $language . '.css')) if $language;
+    
+    if ($c->stash->{blobs} || $c->stash->{blob}) {
+        for($c->stash->{blobs} ? @{$c->stash->{blobs}} : $c->stash->{blob}) {
+            $_ = $c->view('SyntaxHighlight')->render($c, $_, { language => $language });
+        }
+    }
+}
+
 __PACKAGE__->meta->make_immutable;

diff --git a/lib/Gitalist/View/SyntaxHighlight.pm b/lib/Gitalist/View/SyntaxHighlight.pm
index 2f77e44..9c28341 100644 (file)
--- a/lib/Gitalist/View/SyntaxHighlight.pm
+++ b/lib/Gitalist/View/SyntaxHighlight.pm
@@ -9,32 +9,10 @@ use Syntax::Highlight::Engine::Kate::Perl ();
 
 use HTML::Entities qw(encode_entities);
 
-# What should be done, but isn't currently:
-#
-# broquaint> Another Cat question - if I want to have arbitrary things highlighted is pushing things through a View at all costs terribly wrong?
-# broquaint> e.g modifying this slightly to highlight anything (or arrays of anything) http://github.com/broquaint/Gitalist/blob/a7cc1ede5f9729465bb53da9c3a8b300a3aa8a0a/lib/Gitalist/View/SyntaxHighlight.pm
-#       t0m> no, that's totally fine.. I'd tend to push the rendering logic into a model, so you end up doing something like: $c->model('SyntaxDriver')->highlight_all($stuff, $c->view('SyntaxHighlight'));
-# broquaint> I'm thinking it's a bad idea because the Controller needs to munge data such that the View knows what to do
-# broquaint> You just blew my mind ;)
-#       t0m> ^^ That works _much_ better if you split up your view methods into process & render..
-#       t0m> ala TT..
-#       t0m> i.e. I'd have 'highlight this scalar' as the ->render method in the view..
-#       t0m> And then the 'default' thing (i.e. process method) will do that and shove the output in the body..
-#       t0m> but then you can write foreach my $thing (@things) { push(@highlighted_things, $c->view('SyntaxHighlight')->render($thing)); }
-#       t0m> and then I'd move that ^^ loop down into a model which actually knows about / abstracts walking the data structures concerned..
-#       t0m> But splitting render and process is the most important bit.. :) Otherwise you need to jump through hoops to render things that don't fit 'nicely' into the bits of stash / body that the view uses by 'default'
-#       t0m> I wouldn't kill you for putting the structure walking code in the view given you're walking simple arrays / hashes.. It becomes more important if you have a more complex visitor..
-#       t0m> (I use Visitor in the design patterns sense)
-#       t0m> As the visitor is responsible for walking the structure, delegating to the ->render call in the view which is responsible for actually mangling the content..
-
 sub process {
     my($self, $c) = @_;
 
-    for($c->stash->{blobs} ? @{$c->stash->{blobs}} : $c->stash->{blob}) {
-        $_ = $self->render($c, $_, { language => $c->stash->{language} });
-    }
-
-    $c->forward('View::Default');
+    $c->res->body($self->render($c, $c->res->body, $c->stash));
 }
 
 sub render {