Dancer Advent Calendar 2015
Hi everyone! Last year we've ran the Dancer Advent Calendar 2014[1] containing 24 articles on how to use Dancer2, what it can do, what features it has, etc., which was very successful. We would like to have another Dancer Advent Calendar this year. This means 24 more articles. We need *you*. I'm collecting articles on topics ranging from: * Something you do in Dancer (a trick you have, a suggestion on how to use it). * Projects you made that use Dancer. * Plugins you like, plugins you wrote. * Topics I haven't thought of! The Github project for the Advent Calendar is: https://github.com/PerlDancer/advent-calendar Please feel free to submit pull requests with your articles, open issues and email back to the list (or to me) your suggestions. Anything goes. Let's have another set of great articles showing off what we have and what we can do. Thanks, Sawyer. [1] advent.perldancer.org/2014
On Oct 23, 2015, at 2:38 PM, Sawyer X <xsawyerx@gmail.com> wrote:
email back to the list (or to me) your suggestions.
The generated dancer -a code and the examples mostly show simple cases which are fine starting points, but they don’t tell you how to scale the app if it starts getting large. General Perl-in-the-large principles help, but there are aspects of how that interacts with Dancer that aren’t obvious. If you start with the generated code and extend it in the most straightforward manner, you end up with all your code in lib/App.pm, with a flat route definition set. This is bad, and it is the problem I want to address. When you write a program with thousands of lines and a deep URL hierarchy, you start to want to break it up, but the current docs don’t really tell you how to do that sensibly. Dancer is not a policy-free framework, which means that it not only doesn’t force you to do it the right way, it doesn’t even give hints about what the right way might be. It may be too much for a single article, but I would like to cover topics such as: 1. Nested route definitions: # User management pages prefix ‘/user’ => sub { get ‘/login’ => … post ‘/logout’ => … }; # Major user-visible web app feature for logged-in users prefix ‘/feature’ => sub { prefix ‘/record’ => sub { # Define RESTful CRUD API for /feature/record objects del ‘/:id’ => … get ‘/:id’ => … post ‘/’ => … put ‘/’ => … }; }; # An API for use by the site’s JS code and possibly third parties prefix ‘/api’ => sub { prefix ‘/something’ => … }; Not only does defining your URL hierarchy this way instead of in the flat way that is most obvious avoid a lot of redundancy (‘/feature/record/:id’), defining things this way often makes patterns jump out at you, allowing an improvement in the way you design your URL scheme. 2. Moving almost all code out of the generated lib/App.pm into other *.pm files in that directory, possibly nested into a directory hierarchy. (lib/App/Module.pm, etc.) Naming schemes, how to call between modules, etc. 3. Given 1 and 2, how to shard the route definitions among lib/App/*.pm, so that each Perl module includes only the routes that it defines code to handle, rather than dumping the whole route definition into the main lib/App.pm file generated by dancer -a. 4. Given 1 and 2, how to name the content of the views directory. (e.g. views/app/feature.tx or views/app/feature/page-fragment.tx) Policy-heavy frameworks use the calling URL to work out where the template files are, but Dancer doesn’t enforce that. Working out a good naming scheme is essential for maintainability. 5. Your ideas here!
On Sat, Oct 24, 2015 at 1:16 AM, Warren Young <wyml@etr-usa.com> wrote:
On Oct 23, 2015, at 2:38 PM, Sawyer X <xsawyerx@gmail.com> wrote:
email back to the list (or to me) your suggestions.
The generated dancer -a code and the examples mostly show simple cases which are fine starting points, but they don’t tell you how to scale the app if it starts getting large. General Perl-in-the-large principles help, but there are aspects of how that interacts with Dancer that aren’t obvious.
If you start with the generated code and extend it in the most straightforward manner, you end up with all your code in lib/App.pm, with a flat route definition set. This is bad, and it is the problem I want to address.
When you write a program with thousands of lines and a deep URL hierarchy, you start to want to break it up, but the current docs don’t really tell you how to do that sensibly. Dancer is not a policy-free framework, which means that it not only doesn’t force you to do it the right way, it doesn’t even give hints about what the right way might be.
I generally agree that you need to take care when growing on how to extend. Rather than because we're "policy-free" (I like the term), we just haven't realized that we should (and if this is your point, I agree with you) make an effort to document how we recommend doing it, rather than just making it possible. I wrote an article about the "appname" feature which helps with that, and the "setup" method practice I have, but those probably haven't done a good job at addressing the issue. Having an article that says "here's how we recommend extending your application" sounds like a worthwhile goal.
It may be too much for a single article, but I would like to cover topics such as:
1. Nested route definitions:
# User management pages prefix ‘/user’ => sub { get ‘/login’ => … post ‘/logout’ => … };
# Major user-visible web app feature for logged-in users prefix ‘/feature’ => sub { prefix ‘/record’ => sub { # Define RESTful CRUD API for /feature/record objects del ‘/:id’ => … get ‘/:id’ => … post ‘/’ => … put ‘/’ => … }; };
# An API for use by the site’s JS code and possibly third parties prefix ‘/api’ => sub { prefix ‘/something’ => … };
Not only does defining your URL hierarchy this way instead of in the flat way that is most obvious avoid a lot of redundancy (‘/feature/record/:id’), defining things this way often makes patterns jump out at you, allowing an improvement in the way you design your URL scheme.
2. Moving almost all code out of the generated lib/App.pm into other *.pm files in that directory, possibly nested into a directory hierarchy. (lib/App/Module.pm, etc.) Naming schemes, how to call between modules, etc.
3. Given 1 and 2, how to shard the route definitions among lib/App/*.pm, so that each Perl module includes only the routes that it defines code to handle, rather than dumping the whole route definition into the main lib/App.pm file generated by dancer -a.
4. Given 1 and 2, how to name the content of the views directory. (e.g. views/app/feature.tx or views/app/feature/page-fragment.tx) Policy-heavy frameworks use the calling URL to work out where the template files are, but Dancer doesn’t enforce that. Working out a good naming scheme is essential for maintainability.
5. Your ideas here!
I think this is a wonderful idea for not just a single article, but multiple articles. Also, I think we can turn this into user documentation article that stays with Dancer. We've discussed at the conference having documentation that relates to meta-topics. For example, one person has took it upon herself to try and write some documentation on how to configure Dancer2 on Apache or FCGI or how to transition from CGI to Dancer2. We can take an additional direction of code on tips, recommendations, and so on. All of these can be apart from the core documentation (could be in the same distribution) and could be a good resource to point users to. What do you think about making it a series of posts and merging them into the core distribution under some class not under the manual, so it could be distributed with Dancer?
On Oct 24, 2015 10:49 AM, "Sawyer X" <xsawyerx@gmail.com> wrote:
What do you think about making it a series of posts and merging them into the core distribution under some class not under the manual, so it could be distributed with Dancer?
What you are describing sounds more like a wiki.
"Yitzchak" == Yitzchak Scott-Thoennes <sthoenna@gmail.com> writes:
Yitzchak> On Oct 24, 2015 10:49 AM, "Sawyer X" <xsawyerx@gmail.com> wrote:
What do you think about making it a series of posts and merging them into the core distribution under some class not under the manual, so it could be distributed with Dancer?
Yitzchak> What you are describing sounds more like a wiki. No! These should be part of the docs for the core distribution if at all possible. Otherwise bit rot will set in and it won't get updated as quickly. Also, test cases based on the docs would be a good idea I think, so as to reinforce the self correction aspect. John
On Sun, Oct 25, 2015 at 6:30 AM, Yitzchak Scott-Thoennes <sthoenna@gmail.com> wrote:
On Oct 24, 2015 10:49 AM, "Sawyer X" <xsawyerx@gmail.com> wrote:
What do you think about making it a series of posts and merging them into the core distribution under some class not under the manual, so it could be distributed with Dancer?
What you are describing sounds more like a wiki.
It could be a wiki but no one opens a wiki when looking for documentation for a CPAN distribution. So we're trying to come up with a distribution channel that works.
On Oct 24, 2015, at 11:48 AM, Sawyer X <xsawyerx@gmail.com> wrote:
On Sat, Oct 24, 2015 at 1:16 AM, Warren Young <wyml@etr-usa.com> wrote:
On Oct 23, 2015, at 2:38 PM, Sawyer X <xsawyerx@gmail.com> wrote:
email back to the list (or to me) your suggestions.
The generated dancer -a code and the examples mostly show simple cases which are fine starting points, but they don’t tell you how to scale the app
I generally agree that you need to take care when growing on how to extend. Rather than because we're "policy-free" (I like the term), we just haven't realized that we should (and if this is your point, I agree with you) make an effort to document how we recommend doing it, rather than just making it possible.
I very much want Dancer to remain policy-free. Frameworks like Catalyst that make all of these decisions for you are easier to start with, but every time your design choice runs into one of the framework’s design choices, the framework usually wins, forcing you to change your app to conform. This is not to say that Catalyst and such are bad. They’re fine if your app fits their design. For Catalyst, that means MVC, which implies that the M, V, and C either are all in Perl, or can be sensibly wrapped in Perl code that Catalyst can call directly. My app is not like that. To the extent that there is a “model” at all in the app, it’s two or three layers away from the Perl code, and not really factored as an MVC-style Model anyway. Likewise, there really is no Controller in my app, and if I had to extract it as such, it would be composed mainly of JavaScript and C++ code, rather than being Perl code that interacted closely with Dancer, the Model, and the Views. There are plenty of Views in my Dancer app, but without a linked Model or Controller, there is no MVC going on. All of this makes an MVC framework either useless or an impediment for my sort of app. Dancer works much better for this sort of app, because it’s just a box of tools. It doesn’t tell me how to write my app. The downside is that I have to do some work that another framework might do for me. I’ll take that tradeoff happily. But to drag all of this back on the immediate topic, it is useful to see one way that those tools can be used. If someone else came up to you and wanted to write substantially the same sort of article, you should accept, because that developer will do it differently. And that’s a good thing!
I wrote an article about the "appname" feature which helps with that,
You mean this one, I presume: http://advent.perldancer.org/2014/10 Yes, it’s a good point. My article should touch on these points again, without entirely repeating them. I must confess, I’m still using D1, so this issue has not affected me.
the "setup" method practice I have
This one? http://advent.perldancer.org/2014/18 I think that’s orthogonal to what I want to cover.
On Tue, Oct 27, 2015 at 12:05 AM, Warren Young <wyml@etr-usa.com> wrote:
On Oct 24, 2015, at 11:48 AM, Sawyer X <xsawyerx@gmail.com> wrote:
On Sat, Oct 24, 2015 at 1:16 AM, Warren Young <wyml@etr-usa.com> wrote:
On Oct 23, 2015, at 2:38 PM, Sawyer X <xsawyerx@gmail.com> wrote:
[...]
I wrote an article about the "appname" feature which helps with that,
You mean this one, I presume: http://advent.perldancer.org/2014/10
Yes, it’s a good point. My article should touch on these points again, without entirely repeating them.
Agreed.
I must confess, I’m still using D1, so this issue has not affected me.
That's okay, but we *are* looking for articles that target D2, not D1. D1 is frozen and D2 allows much more - that's definitely what we want to teach moving forward.
the "setup" method practice I have
This one? http://advent.perldancer.org/2014/18
Yes, sir.
I think that’s orthogonal to what I want to cover.
Another way is good. :)
"Sawyer" == Sawyer X <xsawyerx@gmail.com> writes:
Sawyer> Last year we've ran the Dancer Advent Calendar 2014[1] containing 24 Sawyer> articles on how to use Dancer2, what it can do, what features it has, Sawyer> etc., which was very successful. Sawyer> We would like to have another Dancer Advent Calendar this year. This Sawyer> means 24 more articles. Sawyer> We need *you*. Sawyer> I'm collecting articles on topics ranging from: Sawyer> * Something you do in Dancer (a trick you have, a suggestion on how to use it). Sawyer> * Projects you made that use Dancer. Sawyer> * Plugins you like, plugins you wrote. Sawyer> * Topics I haven't thought of! Topics suggestions: - I'd love to see a simple example of searching with multiple fields and pagination of the results. My big use case is searching databases in a library to presenting results. Migrating from an old PHP app would be awesome. Which would involve a mix of POST/GET calls... how do people recommend this be handled? Esp when you want to give people the ability to modify their searches, etc. I suspect thoughts on Javascript integration would be needed here. - A Good example of how to put in authentication and some of the issues surrounding it. - I'd also like to second Warren's comment asking for how to structure bigger apps and howto scale them up better. Documentation - more details examples of getting Dancer2 up and working with Apache, NGinx, etc. Or some way to automatically generate templates to be used for common situations. The docs are so so... something more concrete would be ideal. I guess I like how easy it is with Dancer (like the early RoR stuff) it is to do simple things, but the leap upto the next level gets steep quickly. Seeing all the help people have been giving Richard in his questions about writing and doing his app has been awesome. I've been saving a bunch of emails away and I do hope to one day make more use of them.
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.
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
On Oct 27, 2015, at 9:07 AM, John Stoffel <john@stoffel.org> wrote:
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.
I'm trying to use Dancer to solve a problem I currently solve with PHP?
Modern web design usually breaks such an app into several layers: DBMS, caching engine (e.g. memcached), middleware (e.g. Dancer), proxy server (e.g. nginx), and front-end library (e.g. Angular or jQuery). No single layer will do everything for you. You have to know all of the layers separately before you can see how to use them in concert to build the whole app. The everything-in-PHP days are disappearing. Because of that, expecting a site dedicated to just one of these layers to cover all of the other layers is unrealistic. The Dancer mailing list shouldn’t be covering Redis, Postgres, Bootstrap, etc. They have their own lists and forums.
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.
Dancer will not solve all of your problems. But then, no other single technology will, either.
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. :-)
Do you suppose that’s what your paymasters were thinking when they hired you? “I hope this guy custom-develops some old tech for us.” My day job is in a related field to yours. I know about sites using “ancient” technology. The thing is, these sites aren’t uniformly ancient. They adopt the latest-and-greatest whenever they get the budget to upgrade. The only difference between them and the consumer and business worlds is that they then they stay on that increasingly-aged bleeding-edge tech for another 10 years. Deploying 14-year-old tech today means it’ll be a quarter century old when it’s finally decommissioned. I’m not telling you to give your clients bleeding-edge untested tech. Google Reader popularized endless scrolling in 2005. It’s been the standard way of doing such things for most of a decade.
It used to be that you could write a user facing app in one language.
The consequence of that is that you had to send all processing back to the server, which is slow, and you had to do it all in an interpreted language, which is slow. Then we invented Ajax, and memcached, and reverse proxies, and more, all to make the web faster. Study after study shows that faster web sites make users happier, purely because they are faster. Anything that increases round-trip time is a problem. Pagination causes user-visible round-trips. Endless scrolling solves that problem by loading the next screenful of records in the background, before the user knows they need them. Processing still takes human-scale time, but because the user rarely sees it happen, your app appears to run faster. Faster is good.
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.
Yes, and Dancer is potentially similar, in that it has a built-in web server that can work for many real-world applications, allowing you to write more of your code in Perl. If you want something even more extreme, look at the various Erlang web stacks, where even the DBMS might be in Erlang. Nevertheless, you still need to write a fair bit of your app in JavaScript if you want it to be fast, purely because every round trip on the web takes human-scale time, even on a LAN. The more you can do on the client side or in the background, the better.
I don't have the time/energy to become a master of JavaScript, etc.
JavaScript is a much simpler language than Perl. There never has been a time in computing where you could know only one programming language and be considered well-rounded. Until you can get browsers to run Perl code, you’re going to have to have at least some facility with JavaScript if you’re going to write web apps.
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.
It’s not so much that those tutorials were glossing over the real world, it’s that a highly-opinionated framework like Rails puts restrictions on the apps that can sensibly be written in it. You can write non-CRUD apps in Rails, but you’re fighting the framework constantly to do it. Dancer doesn’t make you fight it to do strange things, but it doesn’t hold your hand to help you do strange things, either. It just presents a box of tools and gets out of your way. Observing that perldancer.org does not contain a library media management system is like observing that a wood shop does not contain trundle beds. How, then, do trundle beds come into being?
Taking two steps back from the current position of this thread, I think John is raising a valid point here: He uses Dancer in a certain way. It might not be the responsibility of the main documentation to document his usage, but it would be nice to have an article which does. We hope to have the Dancer Advent Calendar cover new features and tips, but also useful articles - whether they are Dancer-specific or around the perimeter of Dancer usage (like a service or website written in it, or an example on a common application usage). I've added it to the list of ideas, and if anyone wants to write it, please let me know. Thanks John and Warren. :) On Wed, Oct 28, 2015 at 6:53 AM, Warren Young <wyml@etr-usa.com> wrote:
On Oct 27, 2015, at 9:07 AM, John Stoffel <john@stoffel.org> wrote:
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.
I'm trying to use Dancer to solve a problem I currently solve with PHP?
Modern web design usually breaks such an app into several layers: DBMS, caching engine (e.g. memcached), middleware (e.g. Dancer), proxy server (e.g. nginx), and front-end library (e.g. Angular or jQuery).
No single layer will do everything for you. You have to know all of the layers separately before you can see how to use them in concert to build the whole app. The everything-in-PHP days are disappearing.
Because of that, expecting a site dedicated to just one of these layers to cover all of the other layers is unrealistic. The Dancer mailing list shouldn’t be covering Redis, Postgres, Bootstrap, etc. They have their own lists and forums.
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.
Dancer will not solve all of your problems. But then, no other single technology will, either.
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. :-)
Do you suppose that’s what your paymasters were thinking when they hired you? “I hope this guy custom-develops some old tech for us.”
My day job is in a related field to yours. I know about sites using “ancient” technology. The thing is, these sites aren’t uniformly ancient. They adopt the latest-and-greatest whenever they get the budget to upgrade. The only difference between them and the consumer and business worlds is that they then they stay on that increasingly-aged bleeding-edge tech for another 10 years.
Deploying 14-year-old tech today means it’ll be a quarter century old when it’s finally decommissioned.
I’m not telling you to give your clients bleeding-edge untested tech. Google Reader popularized endless scrolling in 2005. It’s been the standard way of doing such things for most of a decade.
It used to be that you could write a user facing app in one language.
The consequence of that is that you had to send all processing back to the server, which is slow, and you had to do it all in an interpreted language, which is slow.
Then we invented Ajax, and memcached, and reverse proxies, and more, all to make the web faster. Study after study shows that faster web sites make users happier, purely because they are faster. Anything that increases round-trip time is a problem.
Pagination causes user-visible round-trips. Endless scrolling solves that problem by loading the next screenful of records in the background, before the user knows they need them. Processing still takes human-scale time, but because the user rarely sees it happen, your app appears to run faster. Faster is good.
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.
Yes, and Dancer is potentially similar, in that it has a built-in web server that can work for many real-world applications, allowing you to write more of your code in Perl.
If you want something even more extreme, look at the various Erlang web stacks, where even the DBMS might be in Erlang.
Nevertheless, you still need to write a fair bit of your app in JavaScript if you want it to be fast, purely because every round trip on the web takes human-scale time, even on a LAN. The more you can do on the client side or in the background, the better.
I don't have the time/energy to become a master of JavaScript, etc.
JavaScript is a much simpler language than Perl.
There never has been a time in computing where you could know only one programming language and be considered well-rounded.
Until you can get browsers to run Perl code, you’re going to have to have at least some facility with JavaScript if you’re going to write web apps.
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.
It’s not so much that those tutorials were glossing over the real world, it’s that a highly-opinionated framework like Rails puts restrictions on the apps that can sensibly be written in it. You can write non-CRUD apps in Rails, but you’re fighting the framework constantly to do it.
Dancer doesn’t make you fight it to do strange things, but it doesn’t hold your hand to help you do strange things, either. It just presents a box of tools and gets out of your way.
Observing that perldancer.org does not contain a library media management system is like observing that a wood shop does not contain trundle beds. How, then, do trundle beds come into being? _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
Sawyer> Taking two steps back from the current position of this Sawyer> thread, I think John is raising a valid point here: He uses Sawyer> Dancer in a certain way. It might not be the responsibility of Sawyer> the main documentation to document his usage, but it would be Sawyer> nice to have an article which does. Thanks for the vote of confidence in my needs/wants, I appreciate it. Sawyer> We hope to have the Dancer Advent Calendar cover new features Sawyer> and tips, but also useful articles - whether they are Sawyer> Dancer-specific or around the perimeter of Dancer usage (like Sawyer> a service or website written in it, or an example on a common Sawyer> application usage). Another subject for the calendar just hit me yesterday. My wife's website has a column in the DB called 'url' which is just what it says, a long ass URL pointing to image(s) for a record. They moved them, so the URL had to change. I ended up doing a quick: <% a.url = a.url.replace('old','new') %> inside the view, but I know that this isn't really the best way, since it puts application logic into the view. I really should A) fix the damn DB to 1) have the correct URL or 2) just have the single parameter number I really need listed, with the rest of the URL built since the .pm file. But I did this because it was simpler than messing about with the results returned from the Dancer::Plugin::DBIC when doing the query. Basically, I do the ultra simple: if (length $query) { @results = _perform_search($regexp,$limit); } template 'search', { query => $query, regexp => $regexp, tobold => $tobold, results => \@results, count => $#results+1, #limit => $limit, title => "Search the Collection", }; }; Where my query is simply: my @r = $schema->resultset('Name')->search( { full_name => { regexp => '[[:<:]]'.$regexp.'[[:>:]]' } }, { order_by => { -asc => 'full_name' }, prefetch => 'account', #rows => $limit, })->all; return @r; And yes, I need to convert this to a FULLTEXT match instead to speed it up. But!! The key idea was to fun a simple foreach loop on @results and massage the data. But since it's down two levels, it was a pain. So, after all this ... maybe I should just write an actual article on the tradeoffs of doing work in the view vs doing it in the controller. It's ideal to do it all in the controller, but sometimes the view is simpler... Comments? John
It sounds to me like you want to change the URLs in the DB and add a small Rewrite Middleware around your app to change all older URLs to the new scheme. Maybe one line of code for the rewrite, additional 2-3 for wrapping it with Plack::Builder (if you aren't already) in order to enable the middleware. On Fri, Oct 30, 2015 at 5:16 PM, John Stoffel <john@stoffel.org> wrote:
Sawyer> Taking two steps back from the current position of this Sawyer> thread, I think John is raising a valid point here: He uses Sawyer> Dancer in a certain way. It might not be the responsibility of Sawyer> the main documentation to document his usage, but it would be Sawyer> nice to have an article which does.
Thanks for the vote of confidence in my needs/wants, I appreciate it.
Sawyer> We hope to have the Dancer Advent Calendar cover new features Sawyer> and tips, but also useful articles - whether they are Sawyer> Dancer-specific or around the perimeter of Dancer usage (like Sawyer> a service or website written in it, or an example on a common Sawyer> application usage).
Another subject for the calendar just hit me yesterday. My wife's website has a column in the DB called 'url' which is just what it says, a long ass URL pointing to image(s) for a record. They moved them, so the URL had to change.
I ended up doing a quick:
<% a.url = a.url.replace('old','new') %>
inside the view, but I know that this isn't really the best way, since it puts application logic into the view.
I really should A) fix the damn DB to 1) have the correct URL or 2) just have the single parameter number I really need listed, with the rest of the URL built since the .pm file.
But I did this because it was simpler than messing about with the results returned from the Dancer::Plugin::DBIC when doing the query.
Basically, I do the ultra simple:
if (length $query) { @results = _perform_search($regexp,$limit); }
template 'search', { query => $query, regexp => $regexp, tobold => $tobold, results => \@results, count => $#results+1, #limit => $limit, title => "Search the Collection", }; };
Where my query is simply:
my @r = $schema->resultset('Name')->search( { full_name => { regexp => '[[:<:]]'.$regexp.'[[:>:]]' } }, { order_by => { -asc => 'full_name' }, prefetch => 'account', #rows => $limit, })->all; return @r;
And yes, I need to convert this to a FULLTEXT match instead to speed it up.
But!! The key idea was to fun a simple foreach loop on @results and massage the data. But since it's down two levels, it was a pain.
So, after all this ... maybe I should just write an actual article on the tradeoffs of doing work in the view vs doing it in the controller. It's ideal to do it all in the controller, but sometimes the view is simpler...
Comments? John _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Sun, Oct 25, 2015 at 10:12 PM, John Stoffel <john@stoffel.org> wrote:
"Sawyer" == Sawyer X <xsawyerx@gmail.com> writes:
Sawyer> Last year we've ran the Dancer Advent Calendar 2014[1] containing 24 Sawyer> articles on how to use Dancer2, what it can do, what features it has, Sawyer> etc., which was very successful.
Sawyer> We would like to have another Dancer Advent Calendar this year. This Sawyer> means 24 more articles.
Sawyer> We need *you*.
Sawyer> I'm collecting articles on topics ranging from: Sawyer> * Something you do in Dancer (a trick you have, a suggestion on how to use it). Sawyer> * Projects you made that use Dancer. Sawyer> * Plugins you like, plugins you wrote. Sawyer> * Topics I haven't thought of!
Topics suggestions:
- I'd love to see a simple example of searching with multiple fields and pagination of the results. My big use case is searching databases in a library to presenting results. Migrating from an old PHP app would be awesome. Which would involve a mix of POST/GET calls... how do people recommend this be handled? Esp when you want to give people the ability to modify their searches, etc.
I suspect thoughts on Javascript integration would be needed here.
Good idea. Added!
- A Good example of how to put in authentication and some of the issues surrounding it.
There is one planned for Dancer2::Plugin::Auth::Extensible by Andy.
- I'd also like to second Warren's comment asking for how to structure bigger apps and howto scale them up better.
Yup! I want to add it but first I want to know if this will be a single article, a series, etc.
Documentation
- more details examples of getting Dancer2 up and working with Apache, NGinx, etc. Or some way to automatically generate templates to be used for common situations. The docs are so so... something more concrete would be ideal.
Automatically generating templates for it is a very interesting idea. Raise a ticket, maybe? As for articles, these are good article ideas. Added! Thank you for all the comments!
On 27 October 2015 at 06:32, Sawyer X <xsawyerx@gmail.com> wrote: > On Sun, Oct 25, 2015 at 10:12 PM, John Stoffel <john@stoffel.org> wrote: > >>>>>> "Sawyer" == Sawyer X <xsawyerx@gmail.com> writes: > > - I'd also like to second Warren's comment asking for how to structure > > bigger apps and howto scale them up better. > > Yup! I want to add it but first I want to know if this will be a > single article, a series, etc. On this topic, perhaps someone who has written a non-trivial, open-source Dancer app--big enough to have to split up code into numerous modules--could write a walkthrough of the basics of their application. When I was getting to grips with Dancer, I searched GitHub for large Dancer2 apps to give me ideas on how to set up, structure, and test my own. It can be a useful way of learning a tool if you have clear, well-documented examples to look at.
Hello there! My worthless 2c: Based on our experience with the Perl Weekly, people usually click on 1 maybe 2 articles. So I think it is quite unlikely many people will be able to follow the Advent calendars. I also think it is quite hard to read so many articles in such a short period of time. Especially as several other Advent calendars are competing to our attention. Google Analytics of http://advent.perldancer.org/ tells me that most of the month the site gets about 1500-1800 visits / month In December 2013 it got 3500 visits, in December 2014 it got 4,400 visits. The http://perldancer.org/ site gets about 7-8,000 visits / month. Instead of and Advent calendar in December, I'd suggest to spread out the 24 articles and have one published every 2 weeks during 2016. Though it does not need to wait till January. It could be started next week. Then we could include them in the Perl Weekly and other Dancer enthusiasts could also spread the links. I'd also suggest to publish the articles on the http://perldancer.org/ site and to move all the content from http://advent.perldancer.org/ to the http://perldancer.org/ and to create a unified table of context for all the articles, but that's a slightly different story. regards Gabor
The suggestion is good, however I'd just add the note that a similar thing was proposed for Catalyst but it didn't work. The proposal was to stop Catalyst Advent Calendar and publish an article just once a month, but finally there were no articles, and at the end of the year the Advent Calendar was published again. It could work for Dancer if the article publishing on every 2 weeks is better controlled/monitorized though. --Octavian ----- Original Message ----- From: Gabor Szabo To: Perl Dancer users mailing list Sent: Monday, October 26, 2015 6:59 AM Subject: Re: [dancer-users] Dancer Advent Calendar 2015 Hello there! My worthless 2c: Based on our experience with the Perl Weekly, people usually click on 1 maybe 2 articles. So I think it is quite unlikely many people will be able to follow the Advent calendars. I also think it is quite hard to read so many articles in such a short period of time. Especially as several other Advent calendars are competing to our attention. Google Analytics of http://advent.perldancer.org/ tells me that most of the month the site gets about 1500-1800 visits / month In December 2013 it got 3500 visits, in December 2014 it got 4,400 visits. The http://perldancer.org/ site gets about 7-8,000 visits / month. Instead of and Advent calendar in December, I'd suggest to spread out the 24 articles and have one published every 2 weeks during 2016. Though it does not need to wait till January. It could be started next week. Then we could include them in the Perl Weekly and other Dancer enthusiasts could also spread the links. I'd also suggest to publish the articles on the http://perldancer.org/ site and to move all the content from http://advent.perldancer.org/ to the http://perldancer.org/ and to create a unified table of context for all the articles, but that's a slightly different story. regards Gabor ------------------------------------------------------------------------------ _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
Hi Gabor, I agree with most of your points, and particularly about consolidating the articles in a single location; ideally there would also be an index or tags so that users could find all the articles about, say, plugins, or the use of 'appname'. I'd argue for adding it to the Dancer distribution and mirroring it on a website, rather than just having it online somewhere, mostly because it is much easier to have a single resource for documentation, and if it can be accessed offline, that's even better! Re: the advent calendar, the advantage is that it focusses people on writing articles by a specific deadline, as well as inspiring those who would not usually contribute to write something up and share it with the community. Even if the articles are not all read in December, they provide a useful lasting resource, as the access stats you've quoted show. I think it'd be hard to motivate people to contribute for a fortnightly article -- from my own experiences of organising a monthly news email, it very quickly becomes a chore. A one-off or annual event is far more likely to be successful. Cheers! Amelia. On 25 October 2015 at 21:59, Gabor Szabo <gabor@szabgab.com> wrote:
Hello there!
My worthless 2c:
Based on our experience with the Perl Weekly, people usually click on 1 maybe 2 articles. So I think it is quite unlikely many people will be able to follow the Advent calendars.
I also think it is quite hard to read so many articles in such a short period of time. Especially as several other Advent calendars are competing to our attention.
Google Analytics of http://advent.perldancer.org/ tells me that most of the month the site gets about 1500-1800 visits / month In December 2013 it got 3500 visits, in December 2014 it got 4,400 visits. The http://perldancer.org/ site gets about 7-8,000 visits / month.
Instead of and Advent calendar in December, I'd suggest to spread out the 24 articles and have one published every 2 weeks during 2016. Though it does not need to wait till January. It could be started next week. Then we could include them in the Perl Weekly and other Dancer enthusiasts could also spread the links.
I'd also suggest to publish the articles on the http://perldancer.org/ site and to move all the content from http://advent.perldancer.org/ to the http://perldancer.org/ and to create a unified table of context for all the articles, but that's a slightly different story.
regards Gabor
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Oct 25, 2015, at 10:59 PM, Gabor Szabo <gabor@szabgab.com> wrote:
Instead of and Advent calendar in December, I'd suggest to spread out the 24 articles and have one published every 2 weeks during 2016.
I think the Advent calendar is good because it gives authors a concrete goal to hit. You can’t slip the schedule, you have to get something out, on-time. No procrastination! However, some of this content could also move into the docs, where it’s more readily discoverable and more likely to be maintained in years to come.
On Mon, Oct 26, 2015 at 5:59 AM, Gabor Szabo <gabor@szabgab.com> wrote:
Hello there!
My worthless 2c:
Based on our experience with the Perl Weekly, people usually click on 1 maybe 2 articles. So I think it is quite unlikely many people will be able to follow the Advent calendars.
I also think it is quite hard to read so many articles in such a short period of time. Especially as several other Advent calendars are competing to our attention.
This isn't the only value in them. An additional value is being able to refer back to them, to pass them between us, to share. They can be later promoted into actual running code, into documentation, etc. They serve a lot of purpose beyond click counters.
Google Analytics of http://advent.perldancer.org/ tells me that most of the month the site gets about 1500-1800 visits / month In December 2013 it got 3500 visits, in December 2014 it got 4,400 visits. The http://perldancer.org/ site gets about 7-8,000 visits / month.
Instead of and Advent calendar in December, I'd suggest to spread out the 24 articles and have one published every 2 weeks during 2016. Though it does not need to wait till January. It could be started next week. Then we could include them in the Perl Weekly and other Dancer enthusiasts could also spread the links.
It's hard to maintain such an effort. As counter intuitive as it might sound, it's easier to maintain a consorted effort of writing a bunch of articles rather than having to write one every two weeks. You lose focus, you lose the drive, you lose the contributors. After you've written them, you can always then distribute them again in blogs and on other distribution channels like Perl Weekly. That option doesn't go away, such as the usefulness of an article past the "clickability" range of it.
I'd also suggest to publish the articles on the http://perldancer.org/ site and to move all the content from http://advent.perldancer.org/ to the http://perldancer.org/ and to create a unified table of context for all the articles, but that's a slightly different story.
I agree having it on the main website is useful. I disagree it should be completely removed from advent.perldancer.org. I definitely agree it's a [slightly] different story.
participants (7)
-
Amelia Ireland -
Gabor Szabo -
John Stoffel -
Octavian Rasnita -
Sawyer X -
Warren Young -
Yitzchak Scott-Thoennes