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 _______________________________________________ dancer-users mailing list [email protected] http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
