Aspectual artifact types.
Refactor artifacts into more general types such as SimpleFileArtifact, along with a multi-aspect AspectualArtifact, a type of CompositeArtifact.
When implementing GUISE-112, the conceptualization of what an "artifact" is evolved. They are now best understood as semantic placeholders in the site plan (). Artifacts are meant:
To indicate the resource place in the artifact tree.
To provide a metadata description of the resource.
To indicate any tree-related attributes (e.g. navigability).
To indicate any child artifacts.
To indicate the source of the content (the file and/or any alternate input stream) for mummification.
To indicate the destination of the content.
Artifacts thus give a sort of logical tree of the produced resources, although they might not correspond directly to the tree of resource paths (e.g. child post artifacts actually produce multiple sub-collection paths). Each artifact would be mostly agnostic to any particular type of content passing through it; this would be handled by its associated mummifier. The artifact would be sort of a coordination point.
Thus there seems to be no purpose for the PageArtifact other than to indicate that it is a navigable artifact—something that could be done with any general artifact. That is, there is currently no use in semantically marking the artifact as a "page". (In fact if we were to need such a marker, it should be noted that DefaultXhtmlPhantomArtifact technically should be marked as a "page" as well—it currently is not.) In fact OpaqueFileArtifact is currently implemented no differently than a PageArtifact, except that it is marked not navigable.
Thus we can replace PageArtifact, PostArtifact, OpaqueFileArtifact with a SimpleFileArtifact that allows specification of whether it is navigable and whether it is a post.
In addition we need a type of composite artifact that can offer several "aspects", or predefined views of the artifact. The archetypal aspectual artifact is an image artifact, which will have () a "preview" aspect that is smaller (and potentially even an even smaller "thumbnail" aspect). As discussed in GUISE-178, the term "aspect" here (which is from the Latin aspectus: "to look at") is a middle ground between "facet", which has more of a sense of "part of a whole"; and "perspective, which is more subjective and depends on how it is being viewed by the viewer. Thus "aspect" means some intrinsic, predefined way of looking at the resource.
Create an interface AspectualArtifact that extends CompositeArtifact to allow processing of its contained aspect artifact, each of type AspectArtifact. The AspectualArtifact will allow lookup of its aspects by some aspect ID such as preview, and each AspectArtifact will allow its aspect ID to be retrieved.
The underlying JEXL implementation of MEXL currently doesn't support simply foo.bar('foobar') as an expression if the Foo method is getBar(String), so let's rename AspectualArtifact.getAspect(String) to just AspectualArtifact.aspect(String) for now to make the MEXL expressions more concise and fluent.