I think this might be handled inconsistently. So I'm trying to first come to a conclusion about what is the correct approach here, and then in a second step, I want to adapt the code as necessary.
In many cases, these two are exactly the same, but they don't necessarily have to match in all cases as Resource names can be edited.
Benefits of resource name:
- Users can adapt the name at a later time according to B-Fabric constraints.
- Especially should there be a conflict like the same filename used in two different folders for different files, it could be resolved by the user.
Benefits of actual file name:
- We already know it's a valid filename and can trust this property without applying some transformation (e.g. if there is a slash in the name).
- Less complex.
I am leaning strongly in favor of using the actual filename here.
However, this should be coupled with a feature in the Resource class for consistency accross the code base and the question how to name the field (maybe .filename would have the most consistent naming as it is clear that this is not "Resource" and it's the name of the "file")
I think this might be handled inconsistently. So I'm trying to first come to a conclusion about what is the correct approach here, and then in a second step, I want to adapt the code as necessary.
In many cases, these two are exactly the same, but they don't necessarily have to match in all cases as Resource names can be edited.
Benefits of resource name:
Benefits of actual file name:
I am leaning strongly in favor of using the actual filename here.
However, this should be coupled with a feature in the
Resourceclass for consistency accross the code base and the question how to name the field (maybe.filenamewould have the most consistent naming as it is clear that this is not "Resource" and it's the name of the "file")