[dancer-users] Dancer Advent Calendar 2015

[Warren Young]

On Oct 25, 2015, at 3:12 PM, John Stoffel wrote:
> 
> - I'd love to see a simple example of searching with multiple fields and
>  pagination of the results.

That sounds like a front-end problem, plus a back-end problem.  Dancer is just the thing in between schlepping data between the two.

How is this a Dancer problem?

> how do people recommend this be handled?

In 2015, you do it with endless scrolling:

  https://github.com/fredwu/jquery-endless-scroll

Pagination is soooo 2001.

If by some chance you have not yet seen this in action, do a search at DuckDuckGo, and start scrolling down.  Notice that it is not “10 blue links” followed by a next/prev bar.  It just keeps going.

You don’t have to use jquery.endless-scroll.js for this.  (Or jQuery, for that matter.)  I looked into it, and it ended up being not too many lines of code to just roll it myself.  But, studying jquery.endless-scroll.js as an example of how to do it will probably tell you what you want to know.

>  Esp when you want to give people
>  the ability to modify their searches, etc.  

A necessary part of endless scrolling is remembering the search parameters you used last, because your next onscroll Ajax query will pass those again, mostly unchanged, except for the “start” value.  You can hold them in JS variables, or hidden HTML fields, or HTML local storage, or...

> - A Good example of how to put in authentication and some of the
>  issues surrounding it. 

This is beginning to sound like “write my app for me.”  

Most of the past Advent calendars have had authentication-related articles:

  http://advent.perldancer.org/2010/17
  http://advent.perldancer.org/2011/13
  http://advent.perldancer.org/2012/2
  http://advent.perldancer.org/2012/16
  http://advent.perldancer.org/2014/19

> - more details examples of getting Dancer2 up and working with Apache,
>  NGinx, etc.

I didn’t have any trouble using the existing docs to do this with my app.  

I’ll grant that the Dancer docs don’t just drop an httpd.conf or nginx.conf file on you, but there are plenty of articles elsewhere online that explain how to do the non-Dancer parts.

The only confusing part I’m aware of is Dancer2-specific, where the PSGI layer takes over the choice of port number, which overrides a bunch of stuff that’s only relevant to Dancer1, but which remains in D2.  (e.g. The port setting in config.yml.)

But this isn’t a documentation problem so much as getting someone with a commit bit to decide they want to remove all the non-PSGI TCP listening port configuration stuff and its documentation, so that PSGI is the only way to do it.

> the leap upto the next level gets steep quickly.  

That’s because Dancer doesn’t try to do everything for you.  It just provides a box of tools, which you are expected to either know how to use, or at least be capable of learning how to use them.

Take your first example: if Dancer did DBMS integration and Ajax scrolling code and everything in between, it would be a huge monster of a framework that only worked well for apps that happened to fit its particular way of doing things, like Rails, or Catalyst, or… 

If you want a highly-opinionated framework that tries to do everything for you, you know where to get it.  Dancer is not that kind of web framework, and thank Bog for that.

> Seeing all the help people have been giving Richard in his questions
> about writing and doing his app has been awesome.

I don’t like how he’s been trying to single-handedly turn this list into a tutorial on front-end development.  I’ve been ignoring his threads for weeks, because they were so reliably off-topic when I was paying attention.