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