Now that Guise Mesh () integration into Guise Mummy is going well, these mesh templates are going to need to do things based upon their surrounding artifacts. For example one of the main motivations for implementing meshing now is to have something more flexible and long-term for an image gallery (). A page with an image gallery would need to know the list of images meeting a certain criteria in the same directory as the page and optionally in subdirectories.
Currently Guise Mummy has a "plan" phase, in which the mummifiers decide what they will generate for the site. The result is the tree of artifacts, but otherwise this "plan" has no existence as an entity. This ticket would create an actual MummyPlan object that provide access to the tree of artifacts. More interestingly it would allow a way to query for artifacts meeting certain criteria. The MummyPlan instance would be stuck in the Guise Mesh context using the variable name plan, and allow queries looking something like this:
The MummyPlan.queryArtifacts() method would return an ArtifactsQuery object, which is sort of like a builder except that is an instance of Iterable<Artifact>. Its methods prepare the query, and its iterator() method would be equivalent to a build() method. As an Iterable<Artifact> it would work just fine with Guise Mummy mx:each iteration ().
Most importantly this implementation supports:
Querying artifacts from the same level of the current artifact.
Filtering by content type, supporting wildcards (e.g. image/*).
It's unclear how this would interact with navigation determination and the post/directory widget of and GUISE-131. Currently "navigation" for regenerating menus uses PageMummifier.navigation(), which uses a NavigationManager and takes into consideration a set of navigation configuration files which may be in the source directories. (It's possible that the NavigationManager logic could be moved to the MummyPlan, but that may not be needed right now.)
However the directory widget simply asks the PageMummifier for its available navigation artifacts (with no special configuration files) and filters/sorts them as specified in the widget. In other words, it does the sort of query of the "plan" being considered in this ticket. Thus the directory widget may be a candidate to be replaced altogether by the new plan artifact query subsystem.
Now that Guise Mesh () integration into Guise Mummy is going well, these mesh templates are going to need to do things based upon their surrounding artifacts. For example one of the main motivations for implementing meshing now is to have something more flexible and long-term for an image gallery (). A page with an image gallery would need to know the list of images meeting a certain criteria in the same directory as the page and optionally in subdirectories.
Currently Guise Mummy has a "plan" phase, in which the mummifiers decide what they will generate for the site. The result is the tree of artifacts, but otherwise this "plan" has no existence as an entity. This ticket would create an actual
MummyPlan
object that provide access to the tree of artifacts. More interestingly it would allow a way to query for artifacts meeting certain criteria. TheMummyPlan
instance would be stuck in the Guise Mesh context using the variable nameplan
, and allow queries looking something like this:The
MummyPlan.queryArtifacts()
method would return anArtifactsQuery
object, which is sort of like a builder except that is an instance ofIterable<Artifact>
. Its methods prepare the query, and itsiterator()
method would be equivalent to abuild()
method. As anIterable<Artifact>
it would work just fine with Guise Mummymx:each
iteration ().Most importantly this implementation supports:
Querying artifacts from the same level of the current artifact.
Filtering by content type, supporting wildcards (e.g.
image/*
).Ordering by name.