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.
blame => $blame,
head => $repository->get_object($hb),
filename => $filename,
-
- # XXX Hack hack hack, see View::SyntaxHighlight
- language => ($filename =~ /\.p[lm]$/i ? 'Perl' : ''),
blob => join("\n", map $_->{line}, @$blame),
);
- $c->forward('View::SyntaxHighlight')
+ $c->forward('Model::ContentMangler')
unless $c->stash->{no_wrapper};
}
blob => $blob->content,
head => $head,
filename => $filename,
- # XXX Hack hack hack, see View::SyntaxHighlight
- language => ($filename =~ /\.p[lm]$/i ? 'Perl' : ''),
action => 'blob',
);
- $c->forward('View::SyntaxHighlight')
+ $c->forward('Model::ContentMangler')
unless $c->stash->{no_wrapper};
}
action => 'blobdiff',
);
- $c->forward('View::SyntaxHighlight')
+ $c->forward('Model::ContentMangler')
unless $c->stash->{no_wrapper};
}
action => 'commitdiff',
);
- $c->forward('View::SyntaxHighlight')
+ $c->forward('Model::ContentMangler')
unless $c->stash->{no_wrapper};
}
if ($c->stash->{Repository}) {
$c->stash->{HEAD} = $c->stash->{Repository}->head_hash;
}
+ $c->stash(syntax_css => [$c->model('ContentMangler')->css]);
}
sub error_404 : Action {
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;
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 {
-[%- IF language %]<link rel="stylesheet" type="text/css" href="[% c.uri_for('/static/css/syntax/' _ language _ '.css') %]"/>[% END -%]
+[%- FOREACH file = syntax_css %]<link rel="stylesheet" type="text/css" href="[% file %]"/>[% END -%]
projects / catagits/Gitalist.git / commitdiff