Sorry for the OT, but you started :-)
]]>Dr Strangecode, or how to stop worrying and learn to love Perl 6!
]]>For now I would only recommend the use of Djet for the adventurous and skilled Perl developer.
]]>Djet is a Node Based Content Management System. It's a rather advanced one, using features from modern Perl and PostgreSQL. It's meant to be used behind some kind of frontend server, e.g. Nginx, or at least a Web Cache like Varnish.
The data is defined by a basetype that decides what to do when someone requests that specific path pointing to that specific datanode.
Djet is running on "raw" PSGI, a wonderfully simple interface. A big part of what Djet does is to find the matching node, and as such the "route" in Mojo- and Dancer-land, so
any higher level framework wouldn't add anything in that direction.
With PSGI there's access to all the wonderful middleware that's already written.
Apart from Moose, perhaps the most important Perl piece of Djet is Web::Machine At some point during a refactor, I realized that I needed help to do REST in a proper fashion. This somewhat underdocumented module applies pure magic to the request to decide what to return. Well, perhaps not magic, but taking care of all the small twists and turns coming from the various headers is no small task. Web::Machine does just that.
I have loads of ideas for Djet features, including a blog, a discussion system, and some way to get an overview of my projects. First, though, is a webshop and some kind of payment integration.
Djet is currently not on CPAN. I haven't figured out how to make sure that the required software is installed, and skip the tests if e.g. PostgreSQL is not up to the minimum release (soon to be 9.4). It will probably be released there as well, but for now, the place to find it is https://github.com/kaare/Djet.
]]>The issues will be tracked in Github in the future. There has been some talk about moving selected trac issues over, but it hasn't been a top priority.
I know Gabor is in the process of reviewing http://padre.perlide.org/ but please keep in mind that things take time, and that's a ressource nobody has.
]]>Thanks for your comment.
The link you give is really to the Padre distribution, which is only one out of 99 repositories. There are support distributions, plugins, etc also,
I'll admit Padre is the central one, but the main link (https://github.com/PadreIDE) is given in the post, though perhaps a bit hidden.
]]>Alas it's been suffering from lack of care for a couple of years now. Not because of lack of need or interest, but because nobody seems to have the time. And perhaps somebody needs to step up and grab the torch. Perhaps it's you?
]]> Well, one more thing adds to the fact that Padre was languishing; it was still in a subversion repo and you needed a commit bit to get something into it. Not to mention the fact that using svn really makes you feel sad.Padre is a huge project, with almost 20,000 commits in almost 100 different distributions. I'm by no means the champion of any of these, but I decided to try to convert Padre to Github.
Now, there was already a Padre organization on Github , so I just had to explore Net::GitHub.
It turned out one of the biggest problems was getting the commit author information right. Kevin Dawson had already done a great job to get all the authors, and while I tried to load all the repos on Github, he found as many as possible.
Looping over all the distributions like this
git svn clone -A authors --authors-prog=./au http://svn.perlide.org/padre/trunk -T $reponame
and massaging the name and stuff into place (I won't bore you with the details), and after having created the repo on Github with
$gh->repos->create( { "org" => "PadreIDE", "name" => $reponame, "description" => "$reponame is a Padre repository", "homepage" => "https://github.com" } )it's just a matter of pushing it. Now, I hope some of you will get on board again. There are tons of ideas, almost 20,000 commits (Git counts 18883, last svn revision number is 19831). and cloc http://cloc.sourceforge.net/ says
2787 text files. 2301 unique files. 1086 files ignored.http://cloc.sourceforge.net v 1.62 T=17.29 s (82.5 files/s, 18924.5 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Perl 1122 48437 34697 135509
C++ 125 7113 6761 56674
C/C++ Header 53 1505 1598 9406
CSS 13 1048 95 6458
YAML 24 201 194 4839
HTML 42 852 192 4121
make 2 250 115 2427
Javascript 10 505 369 1799
Pascal 4 219 596 319
JSON 2 1 0 185
XML 2 3 13 172
C 1 35 33 127
RobotFramework 1 0 0 114
DOS Batch 4 12 0 58
SQL 3 23 25 53
Bourne Shell 8 7 5 36
COBOL 1 4 1 16
ActionScript 1 1 0 13
Ruby 3 4 0 7
Ada 1 0 0 5
Java 1 0 3 5
Tcl/Tk 1 0 1 3
PHP 1 0 0 3
Haskell 1 1 0 2
-------------------------------------------------------------------------------
SUM: 1426 60221 44698 222351
-------------------------------------------------------------------------------
OK, wrapping up: Look, make pull requests, hang out in the irc channel padre on irc.perl.org. I think it will be worth it.
]]>use Moose;
with 'Role::REST::Client';
and you will be able to use ->get, ->post, and so on with Role::REST::Client handling the encoding, (de)serialization, etc of the call. Thanks to many contributions from Wallace Reis, Matt Phillips and Mark Stosberg it is very configurable and robust.
I've been getting error reports for some time, but a cursory glance through the code showed no faulty use of hashes. I've used all my ressources at $work, so I haven't had time to dig into this problem, until Сергей Романов (sergeyromanov) poked me with a pointy test case. The problem was easy to find, two parameters to ->new relying on their individual order.
Problem is fixed and uploaded to CPAN as Role::REST::Client 0.15
]]>