The dawn of the combining robots

Yesterday I wanted to say a lot of things about Dancer2 and Apps, but I was a bit sleepy, so I keep the discussion on simple topics. Now I want to talk about something I experienced in the passage from Dancer 1 to Dancer 2 and how it fooled me.

When I started using Dancer 1 I was a young (well, younger than now) and I did dirty things, as young people do. Things like putting Dancer routes directly in the bin/app.pl script.
Talking about Dancer 1 this is not a really dirty thing, Dancer 1 declarations are always global so the problem is just "esthetic".

Routes under lib directory, in a perl module, give a feeling of tidiness, nothing more.

Problem is that, working this way, you start thinking about bin/app.pl as your app, as the center of your site. This is a lot confusing when Dancer2 come along.

You should think about bin/app.pl as just your "launcher", keeping it as empty as you can, using it just to configure what code you want to load in your site.

The dancer2 init script will not help you thinking this way. Launching it you'll have:

• bin/appl.pl with import Dancer2 
• lib/APPNAME.pm with just import Dancer2 :syntax 

What does this mean? It means you're working just with one app, declared in the bin/app.pl and all the code you'll write in pm files will be referred to it. This app will have name "main" and your design will start in a not-so-modular way.

Evil evil Dancer2 init, wanting to keep developers in the Dancer1 global world, hiding the great powers of Dancer2 Apps!

What should you do? In my opinion you should leave import Dancer in the bin/app.pl (you can't make webapp start without it), but you should also use import Dancer in your lib/APP.pm files. Files, yes, more than one, because you should split up functionality (and navigation) in more than one perl module.

Then, your bin/app.pl will become:

import Dancer2 #a "main" app will still be created
import APP1 #some routes and logic
import APP2 #different routes and logic

and so on...

This way, just commentig one line (or uncommenting another) you can turn on/off features, behaviours, navigations and the global structure of your site is easy to understand.

A little thing to close the post. Try sometimes to launch your developement server this way:
DANCER_DEBUG_CORE=1 bin/app.pl
Bootstrap will give you notifications about th Apps start. Here you'll see site structure in a very clean way, something the code itself can't do.

Doctor Dancer2Apps

...or: How I learned to stop worrying and love the framework.

Apps are one of the most gorgeous things introduced by Dancer 2. They allow developers to take very sexy design decisions and encourage modular developement, with a lot of reusable code released on CPAN to make people happy.

Apps are not something new in web frameworks (nothing is actually new in this world). Django, one of the most important Python frameworks, is based on them.
Apps are a really explicit concept in Django. Every time you start a project you must define apps, there's no other way to do it (as in Python zen).

Dancer2 is pure perl, so apps  are a bit more subtle and if you come from Dancer1 you could miss them. There's no App->new, no creation moment, no actual ritual to conjure an app in this dimension.

How do you create an App?

Easy: every module has Import Dancer2 is an App.

Yes, I know, there's nothing simpler than importing a module and you cannot believe something so simple is so powerful but so it is. You import Dancer2 => you create an App.

Then?

Then the world of the modular design is open to you, you can start thinking clever about writing your webapp. You can help world to be a better place... well, a better place where write Dancer websites, at least.

Everything decided inside an App is just inside it and cannot leave it.
Let us thinking about a site where every navigation starting with /funnylayout need a particular layout. You could  check all the routes but why? This is just a "module" of your webapp with a particular behaviour.

Create a packege with a geeky-but-professional name: package MySite::Funny
Make it an app (no chicken blood needed!): import Dancer2
Decide a common prefix for all your navigations: prefix => '/funnylayout'
Set the layout: set layout => 'funny'
That's all, monks!

Now write all the routes you want, knowing they will have the same behaviour. Knowing that if you move them to another site, they'll still have the same behaviour.

Why aren't you excited? Can't you understand? Well, let me speak a little more about Django and one of the most importand feature of it: Django Admin. It's a very fast way to have a backend for a site and let users manage their data.
Dancer's most similar thing is SimpleCRUD. It's just a Dancer Plugin and it does wonderful things but it has problems like HTML interfaces hardcoded in the subs and very little space for improvement.
What if someone start developing and app with all the code of SimpleCRUD in it, made cleaner by a complete use of Dancer2 framework, with templates, plugins and all that stuff? You would just import it to access all your ORM data. You would change it to rewrite its interface or change its flow. Sky would be the limit!

Understand this or go with the Wotan worshipper on the hill, barking to the moon.