Aspectual artifact types.


Refactor artifacts into more general types such as SimpleFileArtifact, along with a multi-aspect AspectualArtifact, a type of CompositeArtifact.

General Artifacts

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.

Aspectual Artifacts

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.




Garret Wilson
January 30, 2021, 10:42 PM

The underlying JEXL implementation of MEXL currently doesn't support simply'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.

Your pinned fields
Click on the next to a field label to start pinning.


Garret Wilson


Garret Wilson