[dancer-users] Dancer Advent Calendar 2015

[John Stoffel]

Warren> 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.

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

Warren> How is this a Dancer problem?

Because I'm trying to use Dancer to solve a problem I currently solve
with PHP?  Dancer is a means to an end for me.  If it doesn't help me
get to where I want to be, then I'll drop it and move on.  I'm using
it in production right now, but I'm constantly looking for better
solutions.

>> how do people recommend this be handled?

Warren> In 2015, you do it with endless scrolling:

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

Warren> Pagination is soooo 2001.

This is for a library thats been around for 200+ years... being 14
years behind the times is fine with them, and me.  :-)  

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

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

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

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

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

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

Not really, it's more asking for a template that I then turn into my
app.  The app involves lots of different tools all interacting with
each other.  It used to be that you could write a user facing app in
one language.  Now if you want to do it in the web you need to know
the backend tool (Dancer/Perl), front end (HTML & CSS & JavaScript)
and the database (SQL).  I can understand why Node.js is making
headway, because it drops down the number of seperate tools/languages
you need to know to get your app out the door.

To me, Dancer is good because I know perl well.  I don't know
Javascript and since my day job is IT, I don't have the time/energy to
become a master of JavaScript, etc.  So to me, using Dancer let's me
leverage my perl skills to do more where I *don't* know the language
as well.  

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

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

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

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

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

Right, I've done this too.  I just think it could be improved.
Getting more people to use Dancer involves making the transistion to
it simpler and easier.  

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

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

>> the leap upto the next level gets steep quickly.  

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

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

I looked into Rails quite deeply at one point and ended up never using
it because all it was good for was blog engines.  LOL

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

Sure, I understand that. But having a wide variety of example apps is
key here.  One of the problems I had with most Rails tutorials was
that they all assumed you needed to do CRUD or a blog.  Nothing more.
They all glossed over the real world uses in my mind.  

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

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

I've been finding them useful in alot of ways.  But I'm not a full
time web developer, so it's much more my level.  

John