Acme-CPANModulesBundle-Import-MojoliciousAdvent-2018

 view release on metacpan or  search on metacpan

LICENSE  view on Meta::CPAN

TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.

                     END OF TERMS AND CONDITIONS

        Appendix: How to Apply These Terms to Your New Programs

  If you develop a new program, and you want it to be of the greatest
possible use to humanity, the best way to achieve this is to make it
free software which everyone can redistribute and change under these
terms.

  To do so, attach the following notices to the program.  It is safest to
attach them to the start of each source file to most effectively convey
the exclusion of warranty; and each file should have at least the
"copyright" line and a pointer to where the full notice is found.

    <one line to give the program's name and a brief idea of what it does.>
    Copyright (C) 19yy  <name of author>

devdata/https_mojolicious.io_blog_2018_12_04_testing-hooks-and-helpers_  view on Meta::CPAN

We can test all those things, too!</p>

              </section>
              <section id="section-2">
                  <h1>Hooks</h1>

<p>To thoroughly test hooks, I need to find ways to configure my test
cases. I could count on my application to do it, and find the right
routes to test the right behavior. But, that creates larger tests that
integrate different parts and makes test failures harder to debug. What
I want is to isolate the thing I&#39;m testing. The best way to do that is
to create routes that test only what I want to test.</p>

<p>What if I have a hook to log exceptions to a special log file, like so:</p>

<pre><code>#!/usr/bin/env perl
use Mojolicious::Lite;
# Log exceptions to a separate log file
hook after_dispatch =&gt; sub {
    my ( $c ) = @_;
    return unless my $e = $c-&gt;stash( &#39;exception&#39; );

devdata/https_mojolicious.io_blog_2018_12_19_you-only-export-twice_  view on Meta::CPAN

directory:</p>

<pre><code>$ ./myapp.pl export --base /yancy --to /var/www/preaction.me/yancy
</code></pre>

<p>And, if I want, I can use <a href="https://mojolicious.org/perldoc/Mojolicious/Guides/Cookbook#Adding-a-configuration-file">the Mojolicious Config
plugin</a>
to change the default settings, including what pages to export, the export
directory, and a base URL.</p>

<p>The best part is that the export command handles redirects. So, when we&#39;re
using <a href="http://metacpan.org/pod/Mojolicious::Plugin::PODViewer">the PODViewer
plugin</a> and get
redirected to <a href="http://metacpan.org">MetaCPAN</a>, the page gets updated with the
redirected location!</p>

<p>In the future it&#39;d be nice if this command were made into a plugin so that it
could have hooks for customizing the exported content or additional checks for
broken links. If anyone is interested in helping out with this work, let me
know and I can help get them started!</p>

devdata/https_mojolicious.io_blog_2018_12_20_testing-dancer_  view on Meta::CPAN

                <!-- theme suggests 1300x500 -->
                <img alt="Dancers and judges at a dance competition" src="/blog/2018/12/20/testing-dancer/banner.jpg">
              </div>

            <div class="post-content">

              <section id="section-1">
                  <p>Authors of Dancer (and other) PSGI applications are probably accustomed to <a href="https://metacpan.org/pod/distribution/Dancer2/lib/Dancer2/Manual.pod#TESTING">testing</a> with <a href="https://metacpan.org/pod/Plack::Test">Pla...

<p>During advent last year, I wrote about <a href="https://mojolicious.org/perldoc/Test/Mojo">Test::Mojo</a>, showing the many easy and (dare I say) fun ways that you can use it to test your Mojolicious applications.
If you missed it, go <a href="https://mojolicious.io/blog/2017/12/09/day-9-the-best-way-to-test/">check it out</a>.</p>

<p>I expect there are at least a few of you out there who read that and think, &quot;I&#39;d love to use that, but I don&#39;t use Mojolicious!&quot;; well, you&#39;re in luck!
With just a little role to bridge the gap, you can use Test::Mojo to test your PSGI applications too!</p>

              </section>
              <section id="section-2">
                  <h2>Mounting PSGI Applications</h2>

<p>Mojolicious itself doesn&#39;t use the <a href="https://metacpan.org/pod/PSGI">PSGI</a> protocol, owing to certain features that it doesn&#39;t provide and which are necessary for certain asynchronous operations.
That said, you can serve a Mojolicious application on a PSGI server by using <a href="https://mojolicious.org/perldoc/Mojo/Server/PSGI">Mojo::Server::PSGI</a>.

devdata/https_mojolicious.io_blog_2018_12_23_mojolicious-and-angular_  view on Meta::CPAN

<h2>Integrating the Apps Further</h2>

<p>To show how the applications can interact, we&#39;ll now build a simple demo to show an api call to a Mojolicious backend routes from the Angular frontend and display the result in Angular.
Since, this is not an Angular blog I will not go too deep explaining Angular; there are plenty of resources in internet for that.</p>

<h3>Create a new route in the Mojo App</h3>

<p>Add a route <code>advent/2018/detail</code> in Mojolicious app class which just responds to http <code>get</code> request.
For some demo data, I&#39;ll just use the first articles from the 2018 Mojolicious advent calendar as a detail list.
In a full mojo app it is best to put routes methods in <code>AppName/Controller/SomeModule.pm</code>, but this is just for quick demo so we can use <a href="https://mojolicious.org/perldoc/Mojolicious/Guides/Growing#Simplified-application-class">hybr...

<pre><code>$r-&gt;get(&#39;advent/2018/detail&#39; =&gt; sub {
    my $self = shift;

    return $self-&gt;render(
        json =&gt;
            [
                {
                    title  =&gt; &#39;Welcome &amp; MojoConf Recap&#39;,
                    day    =&gt; 1,