In addition to it's overwhelming speed I'd like to point out that Text::Xslate throws largely useful error messages on screen in case something is wrong with the markup.
Secondly, the idea of cascading templates (similar to TDL - Djangos Template Language) and blocks than can be nested and overloaded really help to build a clean view in web apps: One specifies the outer tepmlate *WITHIN* the template itself, as opposed to Template Toolkit and others that want this as a redering parameter.
To sum it up: It's speedy, has great error messages and supports template inheritance.
It needed just a little tweaking (SOAP lite must be at least 0.716) on the production server .. this module just works as expected.
I am using this on a couple of businesses and kept me from messing with SOAP. For those in a hurry (like me) I just stripped the neccessary code from paypal-checkout-example.pl. Works flawless for a few thousand transactions until now.
Before Mojo::DOM I used XML::Parser or XML::XPath for this requiring considerably more code for the same thing.
So if your job is just to change some attributes ot to remove certain elements, this Mojo::DOM ist *very* handy with a clean and simple API.
I have been using the great Spreadsheet::WriteExcel for years. But now I ran into the problem of the old XLS binary format being limited to 64K rows per worksheet so I searched CPAN, found this module and was overwhelmed by it having the same API. And it worked out-of-the-box, saving me a lot of time.
Incredibly useful module with a simple but flexible API.
Not only does it generate lots of non-repeating lorem-ipsum text, it also generate URLs, Names (of people), email addresses - all this type of random text you have to generate when prototyping webpages.
A very nice attempt to parse XML. For me, this module perfectly fills the gap between XML::Simple which I use for very minimal XML documents and XML::Schema for read/write access to complex stuff.
XML::Rules comes with a lot of built-in rules and a great "inferRulesFromExample" method that creates appopriate rules for you out-of-the-box. For me, this is a big time saver as I don't have to write XML schemas for medium-complex XML documents and still can tell the parser which tags shall be arrays (XML::Simple on steroids as the docs say).
I didn't experiment with writing XML docs nor did I test any kind of validation but I guess I'll stick to schema-based processing for that kind of work.
There should be some "Quick-Start" Tutorial that points to something like this:
my $rules = XML::Rules::inferRulesFromExample( <xml_example> );
print Data::Dump::dump( $rules );
# now refine the rules skeleton
my $parser = XML::Rules->new( rules => $rules );
my $data = $parser->parse( <xml> );
The procedure above saves me a lot of repetive tasks defining all possible tags and attributes by hand since most of XML tags are of type "no content", "content" or "as array no content".
This is like a nano-Moose. As proposed in the docs, I inlined this code in a little CGI script and then had the convenience to create throw-away classes that don't need have have more than some accessors and methods.
And could do it in Moose style. Very nice!
I'll use Mo instead of Object::Tiny in new few-liners with this one as it offers a nice upgrade path to Moose.
I tried this module for it's simplicity as a drop-in replacement for LWP::UserAgent. The API is very similar so I could just use it as a drop-in replacement for LWP.
Today, I used Furl for a small web scraping project - with quite disappointing results: Fetching ~ 50 URIs (non-parallel requests to a test server with quite deterministic response times) lasted ~ 30 seconds with Furl while LWP::Useragent did the same work in only 7 seconds.
This module saved my morning today. Normally, I use plain cpan to install Catalyst, a dozen plugins and other dependencies of some web projects I have to deploy. And no matter what I always have to answer some questions to cpan. Today I tried cpanm and all modules got installed without asking anything verbose questions like "would you like to install DDS as an alias to Data::Dumper::Streamer?". I unserstand why there is this question but when deploying large prerequisites I don't care. Really.
Again, thank you - cpanm saved me an hour of watching the screen. So I could have my breakfast.
This module just comes so handy. Instead of reading tons of RFCs and embedding images into built emails yourself (fetching, encoding, linking the part-id ...) you can simply throw some HTML at it. The only feature I had to add myself was to make the resolver not die if an image couldn't be found.
But this is the module I use in every project that has to send HTML emails with embedded images and since a few years it did a very good job.
I am using this module to manipulate the leaves of deeply nested structures. (I just want any scalar leaves). For me it's running bug-free for a while now and does exactly what's in the docs - the synopsis is self-describing. In addition, I like the iterator style to walk the leaves.
I do love the REPL shell. Sometimes I wonder if this or that would work so with re.pl you can simply evaluate it in an interactive shell just like you can do in interactive Ruby (IRB) or worse, a Basic shell ;-)
Looking at the powers of CatalystX::REPL (integrating REPL into Catalyst to interactively introspect your running app) I must admit that this module was the most helpful one on debugging I found on CPAN in the last months.
The only thing I consider to be strange is it's use of a lot of "black magic" modules, but how could sneaking the symbol table be done else?
This module provides shortcuts to substr($string,0,$number) (trim) and a one-liner regex replacement (strim). OK, why not?
But: The implementation of trim doesn't simply use substr but splits the string to an array and returns the joined first $number of it's elements. This works but is VERY slow (140 times slower than substr on a 30-char string). strim could be implemented simpler (and faster) without reversing the string twice by tweaking the used regex a bit.
I'm using this module for some projects and until now it works right using it as a proxy object to provide persistence for my Moose classes. I tried DB::CouchDB before and found this module way more complete and more easy to adopt.
I like the easy and clean interface that clearly reminds me of Rose::DB and Rose::DB::Object when it comes to splitting the connection to CouchDB (CouchDB::Client) and the objects stored in it (CouchDB::Client::Doc and ::View). The interface to views is fairly basic, still working correctly.
The only issue I have is a UTF-8 problem: If you're putting some UTF-8 encoded string in you'll get it out in latin1.
I cannot blame this module for this as this problem is specific to "couchdb 0.8.1-incubating" - same occurs when plainly interfacing couchdb by curl or wget, yet I still had to overload the req method to place an ungly encode/decode hack.
This module CAN be handy. I use it to color a diff between versions of html snippets in a CMS. Unfortunately, it uses a string LCS (see Algorithm::Diff) approach that is not handy and sometimes buggy when it comes to HTML tag attribute changes:
But all-in-all it's better than nothing if those "changesets" need not be ultra-reliable. If you feed simple, valid and pretty-printed XHTML to it, the results are quite good and very very easy to process: I simply put background-colored spans around changes and join it all together. Sometimes I have seen html_word_diff breaking inside of tags - this makes my simple approach render invalid XHTML. Yikes!
To be honest: I later tried with XML::Diff which is perfect for the task by means of correctness but it took way longer to get it the same thing working - HTML::Diff worked "quite well but imperfect" in a couple of minutes.
This module is very useful: How often did I search Catalyst's logs for that entry I was interested in.
Now, a simple $c->log->color( $somthing, 'yellow' ) lets me easily pick the message from myriads of logs. And, I really like the feature of displaying a dump of $something if it's a reference - this is well thought as I would do this manually in most (if not all) cases.
This module definitely brings some fun to XML processing. Throw in a schema to compile and the XML of some API and get fine memory structures - and backwards. Works very fine and stable with an API of moderate complexity (cinema ticketing) I had to face a couple of months ago.
I have used XML::Schema before, but directly feeding a schema and getting a parser (precisely, a reader) out - as in XML::Compile::Schema got the work faster done. In fact, this module saved me from the very (boring) details of schemas. Thank you!
Installation on windows boxes can be tricky as like any modules that depend on libXML.
Use in conjunction with YUI-Compressor is highly recommended for best (and most compatible) results.
This is just so practical to use, although the interface as documented in the "Recipes" section of the docs could be somewhat more deatiled. But in general this module adds so beauty and clarity to my code.
I came across this fine module while searching better ORM. Before using RDBO I used a very simple own one. I took a look at Class::DBI and found it too hard and too much typing to configure. Plain DBI was no longer an option over complexity.
Then RDBO came in and it was so clear how to config and fun to read the docs. Using RDBO I'm often blazed by the feature-richness, so things like Caching, lazy-loading and those things just work kind of out-of-the-box.
The only thing I'm sometimes worrying about are sometimes useless error messages that pop up upon misconfiguraion: So I know there is something wrong, but it's definitely not the "Can't call method "isa" on an undefined value at /usr/local/share/perl/5.8.8/Rose/DB/Object/Metadata.pm line 2106" line that telles me where.