Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DYN-4687 - docs browser and docs generator produce .md files with names that are too long. #13588

Merged
merged 15 commits into from
Dec 6, 2022

Conversation

sm6srw
Copy link
Contributor

@sm6srw sm6srw commented Dec 1, 2022

Purpose

This pull request does:

  • add support for fixed length named md files in the fall back folder
  • add a new rename verb to the generate markdown tool
  • add tests

Declarations

Check these if you believe they are true

  • The codebase is in a better state after this PR
  • Is documented according to the standards
  • The level of testing this PR includes is appropriate
  • User facing strings, if any, are extracted into *.resx files
  • All tests pass using the self-service CI.
  • Snapshot of UI changes, if any.
  • Changes to the API follow Semantic Versioning and are documented in the API Changes document.
  • This PR modifies some build requirements and the readme is updated

Release Notes

(FILL ME IN) Brief description of the fix / enhancement. Mandatory section

Reviewers

(FILL ME IN) Reviewer 1 (If possible, assign the Reviewer for the PR)

(FILL ME IN, optional) Any additional notes to reviewers or testers.

FYIs

(FILL ME IN, Optional) Names of anyone else you wish to be notified of

@sm6srw sm6srw added the WIP label Dec 1, 2022
@sm6srw sm6srw changed the title WIP: DYN-4687 - docs browser and docs generator produce .md files with names that are too long. DYN-4687 - docs browser and docs generator produce .md files with names that are too long. Dec 2, 2022
@sm6srw sm6srw removed the WIP label Dec 2, 2022
@mjkkirschner
Copy link
Member

@QilongTang @sm6srw I think it's worth consider if this will affect localization in any negative way - I can't remember exactly what the localization process is for these files today.

@sm6srw
Copy link
Contributor Author

sm6srw commented Dec 2, 2022

@QilongTang @sm6srw I think it's worth consider if this will affect localization in any negative way - I can't remember exactly what the localization process is for these files today.

I will look into how this works today and go from there. Thanks!

@QilongTang
Copy link
Contributor

@QilongTang @sm6srw I think it's worth consider if this will affect localization in any negative way - I can't remember exactly what the localization process is for these files today.

I will look into how this works today and go from there. Thanks!

All the node help docs are located in each language folder these days. They are localized and will be post to other language folder same as other resources. The default doscs are in en-US folder as part a copy step during build.

/// </summary>
/// <param name="bytes">hash as a byte array</param>
/// <returns>hash a valid filename string</returns>
internal static string GetFilenameFromHash(byte[] bytes)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is the encoding/decoding logic specific to filenames ? looks pretty generic to me

Copy link
Contributor Author

@sm6srw sm6srw Dec 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What we get back are guaranteed to work as a file name in all file systems. That's why I named it that way (and used base32).

var path = Path.GetDirectoryName(file);
var newFile = Path.Combine(path, shortName + ".md");
File.WriteAllText(newFile, $"<!--- {baseName} --->\n" + content);
File.Delete(file);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we need to expect permission issues? only devs will run this command ?

Copy link
Contributor Author

@sm6srw sm6srw Dec 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will get exceptions if that is the case and those are catched and reported at a higher level in the handle function for the rename command. Yes, this is an internal tool. It is not shipped.

private static void RenameFile(string file, string baseName, string shortName)
{
var content = File.ReadAllText(file);
content = content.Replace(baseName, shortName);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you saving the hashed name in the file contents as well?

Copy link
Contributor Author

@sm6srw sm6srw Dec 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nop, only the original name. But I could easily do it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant to ask what is the purpose of line 50 if it's not necessary to save the hashed name in the file?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is for replacing the base name of all support files (images and example files etc). Sorry, I misunderstood your question.

@sm6srw
Copy link
Contributor Author

sm6srw commented Dec 5, 2022

@QilongTang @sm6srw I think it's worth consider if this will affect localization in any negative way - I can't remember exactly what the localization process is for these files today.

I will look into how this works today and go from there. Thanks!

All the node help docs are located in each language folder these days. They are localized and will be post to other language folder same as other resources. The default doscs are in en-US folder as part a copy step during build.

What you describe is what I have seen in my testing. I took a look at our latest 2.17 and 2.18 release zips and how this looks like in other locales. I think we are OK. These new renamed files that we introduce (and we will only have a few) should behave as the others. I will merge this and then watch our daily builds. I have no plans right now to get this into 2.17.

@sm6srw sm6srw merged commit 83161e3 into DynamoDS:master Dec 6, 2022
@sm6srw sm6srw deleted the DYN-4687 branch December 6, 2022 17:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants