Download the PHP package mindplay/implant without Composer
On this page you can find all versions of the php package mindplay/implant. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download mindplay/implant
More information about mindplay/implant
Files in mindplay/implant
Package implant
Short Description Simple packaging and dependency sorting for embedded JS and CSS assets
License LGPL-3.0+
Informations about the package implant
mindplay/implant
Simple packaging and dependency sorting for embedded JS and CSS assets.
Introduction
This library provides a simple, open mechanism for packaging assets, e.g. Javascript and CSS files, and managing dependencies between them.
Asset packages are (singleton) classes, which define their dependencies on other asset packages, and populate a view-model with lists of JS and CSS asset URLs.
This library does not define any fixed set of asset types or locations - it's not limited to any specific model shape, which means you can use it not only for JS and CSS assets, but for anything you can imagine as an asset, such as inline scripts, web-fonts menus, images, locations in a layout, whatever.
Package granularity is also your choice - for example, you could choose to package related scripts with required CSS files as a combined asset package, or you could choose to package them individually, say, if the dependency order of scripts and CSS files differ.
It also does not output HTML tags or render anything, as this is actually the easy part, as you will see in the examples below.
Installation
With composer:
composer require mindplay/implant
Tutorial
Asset packages are classes implementing the AssetPackage interface, which enables them to declare their dependencies on other package types, and to define the assets associated with the package, by populating an (arbitrary) model object.
Package classes must have an empty constructor, because the AssetManager constructs packages automatically as needed. (note that this doesn't mean you can't inject dependencies into you package classes - see "peppering" explained below.)
As a case example, let's say you wanted to package JQuery and Bootstrap - first off, you're going to need a model that supports JS and CSS:
Let's assume you wanted to use JQuery from the CDN, rather than hosting it on your server:
Note that we cannot use a static type-hint in defineAssets()
because this would violate
the interface signature - we use @param
to type-hint for IDE support instead.
Also note that listDependencies()
must be implemented, and must return an empty array,
to explicitly define that this package has no dependencies.
Next, let's package your locally-hosted bootstrap assets:
Pay attention to listDependencies()
, which defines a dependency on our JQueryPackage
,
which must always be loaded before our BootstrapPackage
.
Now that you assets are packaged, you're ready to roll:
Notice that we didn't need to manually add the JQueryPackage
- and more importantly, if
you had added it manually, the order in which you add things makes no difference; the
order in which the packages are applied to your model is based on defined dependencies,
not on the order in which your packages are added. Sweet!
Finally, take your model to a view/template somewhere and render it:
Note the (of course, optional) type-hint for IDE support.
The final output is something like:
And you're done!
The unit test provide a specification, and a running example is also provided.
Injections
You can directly inject assets, in the form of an "anonymous" asset package, e.g. without having to declare a class. This has the benefit of being able to do it on the fly, with the disadvantage of being unable to reference the package - in other words, a directly injected asset package may have dependencies, but other packages cannot depend upon it; in some situations, such as adding assets directly from a controller or view, this is perfectly acceptable.
Example:
In this example, we add a page-specific initialization script, which requires JQuery - this
injected package depends upon JQueryPackage
, which will be applied before it; note again that
this anonymously injected package cannot be identified, which implies that no other package
may depend upon it.
Peppering
Sometimes your package classes are going to have external dependencies, maybe even just
simple things like a root path or a flag - while a package class is required to have an
empty constructor, you can use property or setter injection, by "peppering" your package
classes; for example, let's say you added a $minified
flag to your BootstrapPackage
(from before) to toggle using the minified scripts - you can switch it on/off, like so:
Any callback functions added in this way, will be applied when the packages are created.
Note that type-hints not matching any added package will be quietly ignored.