manager-ui
manager-ui copied to clipboard
zesty-io
Code App: File Pathfile Slash Issue
Describe the bug The problem is you can create a custom view file with or without the forward slash and the file (if routed to the same directory) will fall in the same directory. But when you run the parsley include call you HAVE to call the file by the name you created it with. Our customer has run into the issue that he has created some files with the forward slash and some without. and so his include statements are not uniform.
Slack Reference thread: https://zesty-io.slack.com/archives/C02MAQ54S13/p1660856527409679
@zcolah question, so should we allow the users to create a file name without slash? Because if it's allowed, I think I have to create a logic whenever a user saves the form, the system will automatically append a "/" at the beginning of the filename.
Hello @bltarkany , Zosh told me that you're the best person to ask on this problem.
@JacobDiazCruz the logic will need to be configured in a way that will not create breaking changes to parsley calls that are currently in place.
whether that is to create a logic whenever a user saves the form, the system will automatically append a "/" at the beginning of the filename(a ui indicator should be present in the input to signal this to the user) OR require validation that the user has entered the content with the forward slash -- I would defer to the dev team on which process would fall more inline with current code standards and user expectations
If you automatically append the forward slash I would definitely test that it will not break existing parsley calls. I would seek out Andres and Stuart for the better path on the logic that should be applied
Our system treats and has been treating some/path/file.html and /some/path/file1.html as two distinct filenames so I don't think changing this is gonna be trivial.
We need more information on how many users create files with a leading '/' versus without it and only if there is a significant outlier could we attempt a migration. Because going either route of pre-appending '/' or removing '/' is gonna throw a wrench in clients that operate one way over the other.
For example: If a client typically names their files without a slash and uses them in parsley as such {{ include some/path/test.txt }} and then we start automatically appending leading slashes to new files then if they create another file they will have no way of knowing a slash is being added now {{ include /some/path/test2.txt }} and will attempt to just include as they usually do without the slash. Not to mention that they will still have files that DO NOT have a leading slash which will make it even more confusing. And vice versa if we remove slashes.
libs/a.txt is a different file than /libs/a.txt but visually they are represented the same
User DOES have the ability to see what the file name is to determine if slash is present or not
@zcolah @bltarkany How big of a pain point has this been for users? Can we see this as a reasonable user error?
CC: @shrunyan
@agalin920 I have only seen this brought up by 1 user. The same user did state that he brought it up years ago but no change was made.
Additionally, our docs indicate creating a custom endpoint code file with the forward slash in multiple locations. I have yet to find a doc that does not indicate this. The fact that this user in particular has files created without a forward slash looks to be an oversight and I have not had any other tickets come in with this issue. Nor the issue of calling the parsley include file incorrectly because of an accidental dropped forward slash during the file creation.
@agalin920 Should I now proceed with the logic that appends the "/" whenever the user saves the form that doesn't have one? Or will it have an implication on the saved file?
Need to make a decision on what solution we want. In my opinion we should either enforce a '/' at the beginning or no '/'. Either way it will still be disruptive to a camp of users that prefer one way over the other