We have some issues with source paths, destination paths, and URLs.
Source path and source name
Until recently, a source path was required for every Asset. I changed that to be optional so that we could generate an RSS feed, which has no source path. Nor does it have a source name. This is a symptom of a bigger issue.
Content that's pulled from the web or a database, etc., won't have a source path. It might have a source name, or maybe not.
Content that's generated at runtime won't have a source path or a source name.
That said, content that's pulled from the web or a database might want to include other source info, such as the URL it was pulled from, or the database query that was used to obtain the data.
We should revisit the concept of an asset source, as well as a page source, to ensure that we're not restricting use-cases.
Destination path and URL
When working with Pages it's difficult to know what convention is being followed, or should be followed, with regard to leading slashes ("/"). This is because a destination file path is relative to the build directory and should never have a "/". On the other hand, the URL path is in relation to the base website URL, e.g., "https://blog.flutterbountyhunters.com" + "/my-article".
Additionally, it's not always clear whether a trailing "/" should be included. The output file path for pretty URLs must have a trailing "/" when writing "my-post/index.html" based on "my-post/". However, from a URL perspective, the trailing "/" for pretty URLs isn't required, e.g., "http://blog.flutterbountyhunters.com/my-article/" is equivalent to "http://blog.flutterbountyhunters.com/my-article".
We should revisit the type system to see if we can work with file paths and URLs and avoid these conflicting path syntaxes until it's time to write them to strings.
We have some issues with source paths, destination paths, and URLs.
Source path and source name
Until recently, a source path was required for every
Asset. I changed that to be optional so that we could generate an RSS feed, which has no source path. Nor does it have a source name. This is a symptom of a bigger issue.Content that's pulled from the web or a database, etc., won't have a source path. It might have a source name, or maybe not.
Content that's generated at runtime won't have a source path or a source name.
That said, content that's pulled from the web or a database might want to include other source info, such as the URL it was pulled from, or the database query that was used to obtain the data.
We should revisit the concept of an asset source, as well as a page source, to ensure that we're not restricting use-cases.
Destination path and URL
When working with
Pages it's difficult to know what convention is being followed, or should be followed, with regard to leading slashes ("/"). This is because a destination file path is relative to the build directory and should never have a "/". On the other hand, the URL path is in relation to the base website URL, e.g., "https://blog.flutterbountyhunters.com" + "/my-article".Additionally, it's not always clear whether a trailing "/" should be included. The output file path for pretty URLs must have a trailing "/" when writing "my-post/index.html" based on "my-post/". However, from a URL perspective, the trailing "/" for pretty URLs isn't required, e.g., "http://blog.flutterbountyhunters.com/my-article/" is equivalent to "http://blog.flutterbountyhunters.com/my-article".
We should revisit the type system to see if we can work with file paths and URLs and avoid these conflicting path syntaxes until it's time to write them to strings.