Docendo discimus

$self->explain

  • Calendar

    November 2017
    M T W T F S S
    « Sep    
     12345
    6789101112
    13141516171819
    20212223242526
    27282930  
  • Archives

  • Recent Posts

  • Bling

Posts Tagged ‘Template Toolkit’

Top Searches (July)

Posted by brunorc on July 27, 2009

Update: Diego pointed out something very important, so this post had to be significantly updated.

Someone came here searching for catalyst mason variables stash. It brought me to the question: how do I access stash from the Mason view? The answer is: the same way as in TT(Site) view. Mason page is just passed the stash content, so it’s enough to declare variables we want to use in our view.

A small example: let’s put something like this in our controller:

sub uruk_hai :Local :Args(0) {
    my ( $self, $c ) = @_;

    $c->stash->{message} = 'We will feast on manflesh!';

    $c->stash->{template} = 'uruk_hai.html';
}

Now if we want to use TT(Site), our template will look like this:

<h2>[% message %]</h2>

In Mason it looks like this:

<%args>
# don't die if there's no message
$message => undef
</%args>
<h2><% $message %></h2>

Moreover, the Catalyst::View::Mason module declares some useful globals, like $c, $base and $name, so we can choose between Mason and TT without sacrificing anything.

Advertisements

Posted in Catalyst for intimidated | Tagged: , , , , , , , , | 2 Comments »

Catalyst is easy – installation on Windows

Posted by brunorc on July 19, 2009

Perl introduces itself

Strawberry Perl introduces itself on Windows

Some of us use Windows. That’s OK, there are cases when this platform is useful. It can be also useful for Catalyst development. There are at least two solutions:

  • install VMWare, then Ubuntu, then go to the relevant post
  • install Strawberry Perl on Windows, and then install Catalyst

Good news are: if you like Windows, you can use it for Catalyst development (I wouldn’t use it for deployment, though).

First of all – Windows does NOT come with Perl. Really! And the same goes for Python and Ruby. Quite strange… but easy to overcome. There is a nice Perl distribution – Strawberry Perl – prepared especially for Windows. It has nice no-brain installer, so everything you have to do is to go the website and pick the version you like.

Yes, there are two. The only problem with choosing one is that while 5.10 is more modern and has some goodies, it may affect the ease of your Catalyst development – it is known as the “unknown error” bug. The 5.10.1 should be released soon, but at the moment 5.8.9 would be a safe bet.

Anyway, I assume you picked one, downloaded it, installed and you are ready to get Catalyst. It will require some tampering with command line, so get ready.

CPAN shell in action

CPAN shell in action

First open the command line window and run the command perl -V. This will show you all the information about the installed Perl interpreter (see the picture – in my case it is 5.10.0 version, but the 5.8 should be very similar). When you are sure you have Perl installed on your system, go to the Start -> Programs -> Strawberry Perl -> CPAN client. You will get another command line window with CPAN shell running inside. It starts with downloading some bits of necessary information, chewing it and when it’s ready, it welcomes you with cpan > prompt. Now type

install Catalyst::Runtime

and press Enter. As your system is quite empty, you will have to install some packages Catalyst depends on. It takes some time and you may have to answer some questions or confirm some actions now and then. When this operations finishes you will be able to run Catalyst applications on your Windows machine.

CPAN shell asking for dependencies

CPAN shell asking for dependencies

But the point is to develop such applications. For this we need the Catalyst::Devel package, but before we go into this, we have to fight with some minor glitch. The problem is, that Template Toolkit installation breaks on Windows. It breaks only on building the XS module (the pure C backend, which is faster than the Perl one; we can sacrifice it, as on development machine we don’t need to be blazingly fast), and the good news are, that we are asked if we want to use it, and we can say “no”. However the bad news are, it tries to use it during the test phase of the installation, then fails, and then refuses to install.

So, my suggestion is to overcome it that way:

cpan > force install Template

Now we will be able to install it even if tests fail. Use it sparingly, cause most of the time tests should determine if package is ready to be installed, and passing the test suite is a good measure for this readiness. Also remember to answer “no” while being asked for XS – otherwise the build process will break and even the force option won’t help.

Catalyst::Devel asking about "unknown bug"

Catalyst::Devel asking about 'unknown bug'

After that we are ready to finish the installation:

  • install Catalyst::View::TT
  • install Catalyst::Devel – if you decided to use 5.10, remember to answer yes for the “unknown error” question (default is no)
    Update: I checked it on Strawberry Perl 5.10.0.5 (from April 2009) and it is not fixed in this version

Now you are ready to begin your adventure with Catalyst on Windows. You have to remember two things, though:

  • use catalyst.bat instead of catalyst.pl for creating your application
  • while using the scripts created by Catalyst, like script/myapp_create.pl or script/myapp_server.pl, you have to specify that they should be run as under Perl interpreter, so you have to use the perl script/myapp_server.pl
  • don’t use script/myapp_fastcgi.pl – at the moment there’s no easy support for running Perl webapplications using FastCGI on Windows

That’s all. The 99% of the Catalyst development should be OS agnostic. And every other Perl module you would need can be installed using CPAN shell. Enjoy!

Posted in Catalyst for intimidated | Tagged: , , , , , , , , , , | 10 Comments »

Catalyst is easy – fourth movement

Posted by brunorc on July 4, 2009

Sooner or later mixing HTML with actual application code will start to look very ugly. While it can be good for some rough drafts, real apps demand something more.

Catalyst treats all views in the same manner, so is really up to you to choose a model. Before using Catalyst I wrote some applications in Mason, so I was really happy being able to use this module as the View layer – also because of its outstanding documentation (and a book). Then I discovered TT (Template Toolkit), which have been used in Catalyst tutorial and I liked it – also because of its outstanding documentation!

I won’t get into details of installation of Mason, TT nor their respective Catalyst::View modules in this post. However, soon I’ll describe the installation procedure on Mac OS X, Ubuntu and (maybe even) Windows. On most systems you can do this using the cpan script. At this moment I assume you are able to install required modules. If not, just glance over this post and get back to it once you know how to install all the necessary stuff (maybe from one of my next posts).

I arbitrary decided to use TT. This is a good choice, not even but especially if you used to work with Mason before. That’s because Template Toolkit is what its name says. Sure, it lacks some capabilities of Mason, but in most cases they are not needed, since Catalyst already provide us with something at least similar. Using TT one is not tempted to stuff the logic into the view layer, acting rather the opposite way – eliminating the code from view, making the latter clean and simple.

But since it have to be easy, I won’t use the bare TT. Instead I will suggest you to use the marvellous TTSite module, which just builds the whole structure you need to have your web application powered by TT templates:

script/helloworld_create.pl view TTEasy TTSite

As you can see, it creates two directories in root, the root directory of documents served by our application. One of them – the src dir – contains all files that should be processed by TT and sent to the user. The other one – lib – is full of the TTSite magic, which moves all the configuration hassle almost out of the way.

DANGER, Will Robinson!

Chances are you won’t limit your Catalyst experience only to my blog. I wholeheartedly advise it to you; however, bear in mind that you will find tons of TT examples, addressing the Catalyst object as c, like [% c.uri_for('blah') %]. Two words of warning then:

  • Catalyst object inside TT is actually the context object, also known as the $c variable (thanks, Diego)
  • the name of this object is actually a config variable, so it can be changed

Having said this, I’m going to use the “c” convention. More on this topic you can read in the Friendly Manual, and remember to see the Synopsis, where examples for both cases are shown.

DANGER AGAIN, Will Robinson!

However, the helper script for View::TTSite assumes we want to use the “Catalyst” object instead of “c”, so it may be a good idea to fix some files already created. To do this, we have to find them first in the root directory (I assume we are in the helloworld directory). We can suppose that word “Catalyst” will be somewhat popular there, so better idea is to search for this word followed by dot; and since we’re going to use grep, we have to escape the dot:

grep -r 'Catalyst\.' root/
root/lib/config/main: IF Catalyst.debug;
root/lib/config/main: MACRO debug(message) CALL Catalyst.log.debug(message);
root/lib/config/url:[% base = Catalyst.req.base;

In the first file we have to change Catalyst to c, but the second one will be more interesting. According to the Friendly Manual, the “c” convention offers us two aliases: base and name. So, in the end, the root/lib/config/url file can be changed from this:

[% base = Catalyst.req.base;
   site.url = {
     base    = base
     home    = "${base}welcome"
     message = "${base}message"
   }
-%]

to this:

[% site.url = {
     base    = base
     home    = "${base}welcome"
     message = "${base}message"
   }
-%]

And now we can restart the server, but we won’t see any difference, because until now we just set the body. And when Catalyst sees that the body is already set, it assumes it shouldn’t be processed by View, thus passing the raw body directly to the client.

So, to enjoy the beautiful TTSIte view we have to try some quick hack – let’s go to the end of the index action of the Root controller and change it a bit:

    #$c->response->body( $template );
    $c->stash->{template} = 'welcome.tt2';

Colours! We have colours! But wait, why it gives us a link to the nonexisting page? Let’s fix it, adding the message action:

sub message :Local :Args(0) {
  my ( $self, $c ) = @_;

  $c->stash->{template} = 'message.tt2';
}

Now we can refresh the page and voila! But since there’s a form, why not to fill it and submit?

Ouch. Still no message. But if we open the message.tt2 file we will see that it is passed as a parameter called “message”. So there’s no problem:

sub message :Local :Args(0) {
  my ( $self, $c ) = @_;

  $c->stash->{message} = $c->req->params->{message};

  $c->stash->{template} = 'message.tt2';
}

As an exercise for a reader I leave you with changing “Your Name Here” to something more meaningful.

We have just skimmed the topic of View and there’s definitely more to come. But next posts will be probably more focused on the installation of Catalyst and its dependencies.

Posted in Catalyst for intimidated | Tagged: , , , , , , , , , | 2 Comments »