Download the PHP package vector88/webutils without Composer

Web Utilities

Overview

The Web Utilities package is intended to provide some utilities to make common web-related operations quick and easy to perform.

The package currently contains helpers for:

• XML generation and parsing
• HTTP request generation and response parsing

This package is set up for integration with Composer and Laravel, but you can just as easily download and use the heavy-lifting classes independently.

Installation

1. Execute composer require vector88/webutils to include webutils in your composer project.

Configuration

If you want to use this package with Laravel, you will need to add some entries to your config/app.php file to make use of the providers and facades:

If you're not using this with Laravel, all you need to do is include the PHP files you'd like to use! you can do this using the autoload script, or through direct inclusion.

Usage

HTTP Request Helper

The HTTP Request Helper is designed to make HTTP requests trivial, for requests that live somewhere in complexity between file_get_contents and curl_setopt, which is where many APIs seem to sit.

Here's an example that showcases most of the features:

If you're not using Laravel, building the request changes a tiny bit:

XML Helper

The XML Helper is designed to make easy work of XML objects. At the document level, it's able to:

• Load existing DOMDocument instances
• Create new XML trees
• Parse XML strings
• Output XML strings

At the node level, there are a number of methods available to make reading and writing nodes trivial. On the reading level, there are also methods to work with collections of nodes.

Heads up: most stuff simply returns NULL if it can't get a value.

Using the XML Helper

If you are using the XML Helper with Laravel, you can take advantage of the IOC mechanisms.

If you are using the XML Helper outside of Laravel, you can just create a new instance and work with the methods from there.

Loading an XML String

Using an Existing DOMDocument

If you have a DOMNode that is attached to a DOMDocument, you can also do this to treat the DOMNode as the "root element" for many of the operations that the XmlHelper can perform:

Creating a new XML object

Finding Elements

Say we have the following XML loaded into an XmlHelper instance named $xml:

Retrieving Individual Elements

The following code could be used to retrieve the <catalogue> node (as a DOMNode instance):

As the XmlHelper mostly backs on to DOMXPath, it's entirely possible to provide an XPath string. To retrieve the first book element...

Because XPath is XPath is XPath, you can retrieve the same element a million ways:

Retrieving Collections of Elements

I'm sure you knew that when you saw findFirst there might also be a findAll method.

Again, this method retrieves the DOMNode entries corresponding to the elements that are retrieved.

Retrieving an XmlHelper for Elements

If you'd rather retrieve an XmlHelper instance for the element you're searching for, you can get one directly by using the helper() method:

Note that the helper() method doesn't quite operate the same as the findX() methods: it actually prepends ./ to the XPath before it's processed. This is handy because everything is relative to the current element, but if you're trying to do other stuff, it's bad, because everything is relative to the current element.

The reason that ./ is prepended is that it allows the helper to be re-used at a sub-node level - that is to say, all element queries will always be relative to the current DOMNode, rather than the root of the DOMDocument.

For example:

Retrieving multiple XmlHelper Instances for Elements

It is also possible to retrieve an array of XmlHelper instances for a corresponding collection of DOMNode...

Retrieving Element Values

This is where the useful stuff is in this library. If you have an XmlHelper instance wrapped around one of the <book /> elements listed above, you can use some helper methods to retrieve the node values.

If you want to do things in one fell swoop, you can make use of the wonders of XPath and target the element indirectly.

In addition to string() and integer(), there is also float() which will retrieve a floating point value, and dateTime() which will retrieve (you guessed it) a DateTime element. the call to dateTime() requires a second argument, which is the date format string. This format string is the same as what would be used in DateTime::createFromFormat(), so look it up if you're not sure what to put in there.

Retrieving Multiple Element Values

There are also array versions of the above functions which allows you to get an array of values of the given type from all nodes that match the given XPath.

Same goes for floats() and dateTimes().

Retrieving Attribute Values

It's probably what you'd expect:

Also available: integerAttribute() and floatAttribute().

DOM Manipulation

There are only a few simple methods here as it's not really part of the original purpose of this package (but you're welcome to expand upon it!)

XML String Generation

Use the toString() method to generate an XML string from the underlying document. Note that the XML will be generated from the "root node" of the helper that you're using.

TODO: Add a way for you to retrieve the underlying element, the root element, or a helper for one of those things, so you can get back to the root element somehow.

Namespace Integration

The XML Helper is able to work with elements in namespaces. Simply declare a namespace, and then use your namespace prefix to work with the elements in that namespace.

When using an XML Helper to generate an XML Helper for a child or children, namespaces are cloned and passed on at the time of generation, so you don't need to redeclare namespaces for subsequent calls.

Great, but I can do all of this stuff using DOMDocument and DOMXPath...

To be fair, this helper is just a front for DOMDocument and DOMXPath, but I made it because I'm lazy (ironic, I know).