Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

first version of Dancer 2 article

  • Loading branch information...
commit ae5ce312195fbd57be4f4d72bf6ca22b87b3de24 1 parent 97b8526
authored December 02, 2012
4  README
@@ -28,8 +28,8 @@ Flags:
28 28
       over multiple days)
29 29
 
30 30
 # Dancer2 - almost here posts - I think we could split this into a few:
31  
-[ ] - Why Dancer2 (re-use some content from last year?)
32  
-[ ] - What's new?  (Why is Dancer2 better?)
  31
+[R] - Why Dancer2 (re-use some content from last year?)
  32
+[R] - What's new?  (Why is Dancer2 better?)
33 33
 [ ] - When, dammit? (How far off are we?  Point to dev release hopefully, and
34 34
       mention it's being used in production for dogfooding)
35 35
 [ ] - What needs to be done?  Outline remaining tasks, request volunteers?
181  danceradvent/public/articles/2012/4-why-dancer2.pod
Source Rendered
... ...
@@ -0,0 +1,181 @@
  1
+=head1 Why you should use Dancer2 (and some thoughts, or the other way around)
  2
+
  3
+=head2 A look back
  4
+
  5
+It's been one year and four months since I did my first commit on Dancer2. The
  6
+first commits, besides setting up a dist.ini file are about the
  7
+C<Dancer::Core::Route> class.
  8
+
  9
+If you want to refresh your memories about why I decided that rewrite, you can
  10
+jump to L<this article|http://advent.perldancer.org/2011/8> of the previous advent 
  11
+calendar.
  12
+
  13
+Funny to see that when starting this rewrite marathon, I chose to begin with the
  14
+more essential part of the core: the route handler class. It's certainly not a
  15
+random choice, but I'm pretty sure it was not really made on purpose.
  16
+
  17
+Anyway, almost a year and a half has passed and it's now time to sheld some
  18
+light on Dancer2. I remember Franck Cuny telling me in december 2010 - when we
  19
+were starting the first advent calendar iteration - "You'll see, 2011 will be the
  20
+Dancer year". He couldn't have been more right. Many great things happened in
  21
+2011 for Dancer. So I was asking myself: what about 2012 and the upcoming year,
  22
+2013?
  23
+
  24
+If I should name it, I'd say that 2012 was "the Dancer 2 development year"
  25
+because most of the brainpower was used to grow Dancer2, to mature it and to
  26
+make it real. Of course Dancer1 continued to evolve a bit, but at some point we
  27
+froze it, to make sure we'll release 2.
  28
+
  29
+So what will be 2013? You already know it right? My bet goes on the "Dancer2
  30
+year". Everything is ready, Dancer2 is beautifully designed, efficient and
  31
+extensible yet very compatible with the Dancer 1 ecosystem. You'll love it, and
  32
+you should use it. Now. Here is why, and how.
  33
+
  34
+=head2 What is Dancer2 at the time of this writing?
  35
+
  36
+Before we start, let's clarify where we are today, about Dancer 2. Don't look
  37
+for it on CPAN, it's not there already, when we'll have something polished
  38
+enough we'll certainly roll a DEVELOPER release but we're not yet already (even
  39
+though very close).
  40
+
  41
+Dancer 2 is a GitHub project, you can browse the code on its page:
  42
+L<http://github.com/PerlDancer/Dancer2/> and you can grab the source like so:
  43
+
  44
+    git clone https://github.com/PerlDancer/Dancer2.git
  45
+
  46
+Although it's not sitting on CPAN, it's a stable source tree, we have more than
  47
+500 unit tests already and I'm able to say that Dancer2 is also able to run on
  48
+production because, well, that's what I do at work.
  49
+
  50
+The only area where yo ushould be cautious is with plugins or engines,
  51
+everything is in place to port them, but most of them aren't yet. So it's likely
  52
+that one extension of your app will need to be ported a bit to work with Dancer
  53
+2. It's an easy job to do though, thanks to all the work that has been done on
  54
+Dancer::Plugin to assure inter-operability.
  55
+
  56
+=head2 Design decisions for D2
  57
+
  58
+=head3 Pure OO code, based on Moo
  59
+
  60
+Before listing all the benefits of using Dancer 2, let's take a look at its
  61
+core, seeing what makes it so different from Dancer 1.
  62
+
  63
+First, Dancer 2 is written in pure object-oriented code, with
  64
+L<https://metacpan.org/module/Moo|Moo> as its meta-class layer.
  65
+
  66
+Why Moo? Well, it's Moose philosophy with efficiency in mind, written in pure
  67
+Perl5. It's fast and right to the point. How could another meta-class layer
  68
+could fit better Dancer?
  69
+
  70
+Thanks to Moo, and more generally to the Moose approach, Dancer2's core gets
  71
+very powerful tools in its backbone like lazyness construction, role composition
  72
+and method modifiers. That helped a lot to enhance the way things are
  73
+implemented.
  74
+
  75
+I could alsmost say that Dancer1 is written in Perl5 and Dancer2 is in Moo.
  76
+
  77
+=head3 No more shared singletons
  78
+
  79
+The most limitating and annoying design choice I wanted to get rid of, when
  80
+starting the Dancer rewrite, was the singletons usage. You know the drill, globals are
  81
+evil. That was a mistake I did in the early stage of development of Dancer1, we
  82
+lived with it, I think pretty well, but Dancer 2 needed to go a step further.
  83
+Without singletons. 
  84
+
  85
+Without globals, the code is properly decoupled, things know about themselves
  86
+and their direct neighbours, in fact, the code base now respects truthfully the
  87
+L<http://en.wikipedia.org/wiki/Law_of_Demeter|Law of Demeter>.
  88
+
  89
+This will for sure be a lot better for future evolution and code maintenance.
  90
+
  91
+=head3 Strict app scoping
  92
+
  93
+Another major change I wanted with Dancer 2, which I couldn't do in 1 because of
  94
+the globals limitation mentioned above, was the per-app encapsulation.
  95
+
  96
+I wanted that anything I did in a package was scoped there, for instance being
  97
+able to set a serializer in C<MyApp::API> without setting one C<MyApp::Blog>. In
  98
+Dancer 1 that's impossible, beause the settings registry is global to the
  99
+process (remember? I<Globals are evil>).
  100
+
  101
+With Dancer2, any pakage that C<use>s Dancer will be scoped into its own
  102
+Dancer::Core::App instance, where the settings registry will leave, and the
  103
+route handlers, and anything you could imagine to do within a Dancer package.
  104
+
  105
+In Dancer2, you can consider each of your packages in your application as a jail
  106
+where everything is nicely isolated from the outside. No more apps collision, no
  107
+more settings leaks from a part of the appliation to the other.
  108
+
  109
+=head2 Where are we with Dancer 2?
  110
+
  111
+First of all, let's make it clear: the whole DSL is supported. It means that
  112
+whatever you do when you use Dancer, you can do it with Dancer 2. It's the same
  113
+syntax, you won't even notice it.
  114
+
  115
+Because of the major design changes explained above, plugins cannot work
  116
+magically with Dancer 2. The change to apply are minimal but still, a plugin
  117
+needs to be adapted slightly. Dancer::Plugin provides everything to make sure a
  118
+plugin can run smoothly with Dancer 1 or 2, transparently. 
  119
+
  120
+At the time of this writing, most of the plugins in the ecosystem should be easy
  121
+to port, all we need is volunteers to help us test them, port the code and
  122
+submit pull requests to plugin authors.
  123
+
  124
+On the core side, we habe one thing to do to make the whole ecosystem ready for
  125
+Dancer2: allowing the same kind of transition for engines (template, session,
  126
+etc). In Dancer 1, an engine just needs to "extends" a base "abstract" class. In
  127
+Dancer 2, as we're running with Moo, this has been changed to roles
  128
+composition.
  129
+
  130
+=head2 Shoud you switch from D1 to D2, and how?
  131
+
  132
+It depends on what you want to do. If your application can be written with a
  133
+pure Dancer distribution, without plugins or engines, then yes, you definitely
  134
+can switch today.
  135
+
  136
+It you're using plugins in your app, your help is welcome: test your
  137
+application, report any plugin you're using that doesn't work and help us port
  138
+them.
  139
+
  140
+To power your app with Dancer2, as it's not released yet, here is what I
  141
+suggest:
  142
+
  143
+In your application, create a git submodule in vendor/Dancer2:
  144
+
  145
+  $ cd MyProject
  146
+  $ git submodule add https://github.com/PerlDancer/Dancer2.git vendor/Dancer2
  147
+
  148
+Then add this little snippet in your bin/app.pl to make sure you load any lib
  149
+from your vendor directory:
  150
+
  151
+    BEGIN {
  152
+        use FindBin;
  153
+
  154
+        while ( my $libdir = glob("${FindBin::Bin}/../vendor/*/lib") ) {
  155
+            unshift @INC, $libdir;
  156
+        }
  157
+    }
  158
+
  159
+    use Dancer 2.0;
  160
+
  161
+This way, when the app worker will start, it will push all C<lib> directory it
  162
+an find in C<./vendor/*> as possible location for modules. Hence Dancer 2 will
  163
+be found there.
  164
+
  165
+Works like a charm, and can be used as well for plugins you want to patch for
  166
+Dancer 2.
  167
+
  168
+Also, if you want to make sure your Dancer 2 copy in vendor is up to date:
  169
+
  170
+    $ git submodule update
  171
+
  172
+I'm using this technique at work for a Dancer 2 app we've deployed to
  173
+production, it's working great.
  174
+
  175
+
  176
+=head2 Author
  177
+
  178
+This article has been written by Alexis Sukrieh for the Perl Dancer Advent
  179
+Calendar 2012. 
  180
+
  181
+No copyright, public domain.

0 notes on commit ae5ce31

Please sign in to comment.
Something went wrong with that request. Please try again.