Rename veiled artifacts to remove underscore prefix.
However for the generated files that are published, it seems a bit ugly and unexpected. And after the experience with implementing blog posts in GUISE-108, it should be simple enough to simply remove the underscore prefix for the target filename. This will allow us the convenience of designating artifacts as "private", but still have their filenames look "normal" on the actual site. In other words, the prefix _ would be like a flag set in the filename itself. Before this might have seemed like a hack, but now it appropriate to say that we have certain filename patterns (such as for blog posts) to indicate certain types or attributes of artifacts.
This ticket would be a good place to add a configuration for the veiled artifact prefix, already mentioned in GUISE-42. Adding a way to disable it altogether would be nice as well.
I think we'll move the veil check out of the context to the mummifier level as well for consistency.
As mentioned above, The veil check is being moved to the abstract page mummifier implementation. In addition, rather than veiling applying to an entire directory tree, it will now only apply to a single level. The idea is that veiling just hides something from navigation; if you're still able to get inside a veiled directory and somehow there are pages there with regenerated navigation lists, then these navigation lists will still be regenerated correctly.
The only time this made a difference anyway was when an empty directory tried to generate a phantom content file; in an asset directory tree (with CSS and JSS files, for instance), one would not want these to be generated. Thus there will is another ticket to create an asset designation that will apply to the entire tree and prevent pages from being generated.
One insight from this ticket in conjunction with is that filename unveiling and post subdirectory determination from the filename should be done by the parent artifact mummifier (typically that of the directory), not of the mummifier of the artifact itself the filename of which is being modified.
But for now it shouldn't be an issues, and we can have any mummifier just unveil up the hierarchy.
After more contemplation, it seems better just to fix this now. Determination of child target paths on a per-level basis by the mummifiers (rather than wholesale by swapping the root base) is not only better conceptually, it will bring lots of benefits and ease implementation of new features; it is being implemented in GUISE-125.
Unveiling files is easy, but we have to be careful to also unveil directories. That in theory is also easy, but then it turns out that artifacts may be (are) inside directories, so we will need to somehow unveil path segments up the hierarchy, on the fly.
Currently the isVeiled() check is at the Mummy context level, yet the unveiling happens at the mummifier level. I think we'll move the veil check out of the context to the mummifier level as well for consistency. The tricky part here is that theoretically a mummifier might use some pattern for some other meaning within its subtree, but a mummifier for a child artifact might not know that. So in the future if we get really complex mummifiers, we'll need to have a way for child artifact mummifiers to delegate to parent artifact mummifiers for veil detection and unveiling. But for now it shouldn't be an issues, and we can have any mummifier just unveil up the hierarchy.
It's tempting to use a regular expression to define the file name pattern, e.g. in URF:
This matches any name that begins with _. And because of the matching group, we can make the replacement really flexible, that is we replace the expression with the first matching group, in this case removing the preceding underscore. This allows more interesting replacements, such as removing beginning and ending characters:
It also makes it easy to allow veiling but disable replacement: simply remove the matching group:
This would allow veiled filenames that do not modify their filenames during mummification (in this case, the prefix is not removed).
And finally we can even disable veiling altogether if we use a regular expression which cannnot match anything, such as: