use Perl

• what a gyp! (Score:1)

  by xsawyerx (8978)

  So we didn't lose, Mojo lost - but we didn't win, so Mojo won. I'm confused.

  Should be noted that it seemed like you were more inclined to use "set" in your code when you could have just changed the configuration file (as is shown in the docs):

  template: "template_toolkit"
  engines:
      template_toolkit:
          start_tag: '[%'
          stop_tag:  '%]'

  (taken directly from the POD)

  P.S.

  We're actually working on creating a CPAN distribution-like directories.
  • Re: (Score:2)

    by Alias (5735)

    Mojo is winning on the cumulative result over all weeks so far, but did not pull ahead.

    As you'll see from the code checkout, my application does not have a config file.

    This also isn't really the kind of thing you'd want in a config file, it's an inherent part of the application. You aren't going to change it on one particular machine compared to another machine.
    • Re: (Score:1)

      by xsawyerx (8978)

      Mojo is winning on the cumulative result over all weeks so far, but did not pull ahead.

      Positive and negative comparisons are a matter of semantic. Every "win" is a "loss for the opponent". Suckless can say "we write good programs", instead they decided to say "We write programs that don't suck as much as the others."

      However, even though you disliked a certain feature of Mojo, and disliked it more than you liked the way it is in Dancer - you still awarded no points to Dancer. Kinda sucked, but oh well, maybe we can change the name of Dancer to "Not Mojo". :)

      This also isn't really the kind of thing you'd want in a config file, it's an inherent part of the application. You aren't going to change it on one particular machine compared to another machine.

      Configuration files aren't just thin
      • Re: (Score:2)

        by Alias (5735)

        Code in your configuration is still code, now it's just in a different language and mixed into your real configuration data in a place that is further away from the other code, making it harder to maintain.

        I don't want to put anything into a config file that I wouldn't expect a non-Perl programmer sysadmin to potentially change.
        • Re: (Score:1)

          by xsawyerx (8978)

          I don't want to put anything into a config file that I wouldn't expect a non-Perl programmer sysadmin to potentially change.

          You've got a point there. Fair enough. :)
• Bit harsh re: the app generator (Score:1)

  by huxtonr (8912)

  IMHO etc.
  There are views/ with an index and a "main" layout - I can guess what they're about.
  Three config files, I can guess how that's supposed to work - must be a dev/test/live switch somewhere
  Public dir with css and images - sounds OK. The 404/500 are clearly error pages. Might not want them, but at least I know how to do them now.
  The top100.p[lm] are clearly my main app files.
  All that's left are the app.psgi and dispatch files. I don't know what they're for, but I'm a newbie, so I don't know l
• OO and dispatching (Score:1)

  by zby (4817)

  One of the core features of web frameworks is dispatching - i.e. connecting the http address with a subroutine. This can be done in a few main ways:

  1. DSL with anonymous subs - this what you described above and it is the most common in recent web frameworks. The problem I can see with that code is - how it plays with the standard OO techniques like inheritance and some more advanced ones like Moose Roles. Even if this can be made to play along I am sure there will be lot's of corner cases making it diffic
  • Re: (Score:1)

    by kixx (5946)

    There's also the "put it all in a central dispatch file" (a la Django's URLconf [djangobook.com], or even MojoX::Routes [cpan.org])

    The disadvantage is that you can't just drop a controller class into a file to be automatically picked up by the app, you have to modify the dispatch file too.

    But this turns to an advantage when you wish to selectively enable parts of you app (again, Django's admin feature comes to mind).
• Template Toolkit for Mojo (Score:2)

  by ask (83)

  I'm not sure what your rules are for installing extensions for the framework, but there's a TT renderer for Mojo:

  http://search.cpan.org/~abh/MojoX-Renderer-TT-0.31/lib/MojoX/Renderer/TT.pm [cpan.org]

  (Install it, add the lines from the synopsis to your startup() method and name your templates foo.html.tt).

  With Mojolicious::Lite I think it'd be something like

                use MojoX::Renderer::TT;
                my $tt = MojoX::Renderer::TT->build(

  --
  

  -- ask bjoern hansen [askbjoernhansen.com], !try; do();
• Dancer code could have been more concise (Score:1)

  by ironcamel (9693)

  I would have put the template configuration in the config.yml configuration file. Or you could just use the default <% and %> start end tags in your templates. It wouldn't be the end of the world. I know that it is a matter of style and personal preference, but with a little white space formatting the dancer version could have been written more concisely like so:
  
#!/usr/bin/perl
use Dancer;
use Template;
use CPANDB { maxage => 3600 * 24 * 7 };

  # Route block
get '/' => sub { template 'index' };

  dance
• comparison done? (Score:2)

  by gizmo_mathboy (782)

  Any chance of week 3 of the comparison coming?