This along with XML::LibXML::Proxy is my intro to contributing in the CPAN. For the name, like for Proxy I have cleared it with Shlomi Fish, the current maintainer of XML::LibXML, so that part's OK.

This adds a few convenience methods to XML::LibXML::Element, mostly "ferry()" which greatly simplifies the process of marshaling data from Libxml into a native structure of Perl objects/hashes of one's choosing. My upcoming business-related modules depend on this to succinctly express the relationship between its objects and the XML structure it relates to, in "to_node()/from_node()" methods throughout.

This ferry() simplifies traversing and flattening XML structures, into hashes and/or object instances with setter methods.

Also included are helper functions attr(), create() and add() to help creating XML structures.

Test coverage's 100%, so I think I'm all set to upload.

This is my first expedition into CPAN territory. :) For the name, I have the blessing of Shlomi Fish, the current maintainer of XML::LibXML, so that part's settled.

Motivation: my project validates potentially a lot of different DTDs, so I needed to set up some form of local caching. Libxml2's "catalogs" are not appropriate for this because my project doesn't know in advance what versions it'll have to validate (it's not something popular like HTML) and I didn't want to reinvent an entire caching mechanism from scratch. I looked into using XML::LibXML::InputCallback of course, but those cannot be used to override Libxml's built-in "nanohttp" client for HTTP, it only allows adding new protocols. So I resorted to the extreme: XML::LibXML::externalEntityLoader().

With that, I just use LWP::UserAgent to request the URL through the defined proxy, which in my specific case is a local Nginx caching forward proxy.

I documented in KNOWN BUGS that using this quick hack breaks support for "file:///" and other schemes, because externalEntityLoader() is a catch-all. A future version could handle those but I simply had no need for it in my project and wanted to keep things simple.

The core of it is really just a few lines, and I found no elegant tests to include, so "t/" only includes the basics.

Device::TPLink is a collection of modules designed to make it easy to control TP-Link's family of smart home products with Perl. They should support all devices that are supported by the Kasa cloud service, but as of now I have only been able to test with the HS200(US) smart light switch and the HS105(US) mini smart plug. If you are on the same LAN as the device (or can reach the device with a TCP connection, you can send commands directly to the device, otherwise you will need to get a token from the Kasa service and interact with the device through the cloud.

This is the first module I've written in many moons and the first that I've thought was worth submitting to CPAN. Before submitting, the module needs to be cleaned up. Right now the POD documentation is largely boilerplate from the module-starter script, and tests need to be written. That said, you can turn lights on and off with this thing right now,

I am not associated with TP-Link in any way, except as a user of their products. The TP-Link protocol information came from several sources, including the "IT Nerd Space" blog, softScheck's "tplink-smartplug" project on GitHub, and GadgetReactor's "pyHS100" project on GitHub.

Feedback is appreciated. I guess that's obvious, since I'm posting here...

This module originated because SVG::Timeline did not meet my requirements.

I communicated with the author and went through the code with an intention of contributing to it, but realized that it follows a different design philosophy and use case.

The major difference with SVG::Timeline are as follows

• Start and End are actual DateTime Objects.
• Auto-calculation of timescale ( min, hours, days, months, years ) based on the events and grid size.
• Auto Layout to fit multiple events on same row.
• Tooltips.

I am right now looking to put it in a differnt namespace.

As I have come to relaise that DBIx is not the place for it as it does not extend DBI at all or wrap very muuch.

Perhaps becuse is will have many Modules under it does it need its own Brand?

DA::*

DataAccessor::*

Accessor::*

Was thinking of thinking of sticking it under

DB::*

but that is suppose to be for Debug (tough most of the moduels in that space have to do with DB)

Data::*

might not be a good place as that really deals with the data itself not a DB

Any suggestions??

The library is intended for determining if a network interface gets its information via DHCP and the known details of the leases issued to the interface.

This module is a harness to take in network device (think switches, routers, etc) configuration, parse them, and output them in specified formats.

As an example, it takes an Cisco ASA config, parse the objects, object-groups, NATs, etc.

The harness is used by the command line utility 'ncp'.

The specific parsers and output drivers are dynamically loaded based on the command line arguments.

This module provides a mechanism to chain any number of data sources together for reading through a single file handle. This is convenient if you have multiple sources of which some are very large and you need to pretend that they are all inside a single source.

One application is to pretend to wrap a huge file of XML elements in a root element so that it becomes acceptable to XML parsers such as XML::Twig, without actually having to create a modified copy of the huge file:

use IO::ReadHandle::Chain;
use XML::Twig;

$prefix = '<wrapper>';
$suffix = '</wrapper>';
$cfh = IO::ReadHandle::Chain->new(\$prefix, 'huge.xml', \$suffix);
$twig = XML::Twig->new( twig_handlers => { ... } );
$twig->parse($cfh);

NOTE: Read < for &lt; and > for &gt; above. I cannot figure out the Markdown to make them show up correctly.

A demonstration Perl Dancer CRUD web application written for my capstone course at Independence University