You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Instead of checking by filename TsxProvider (or a new base class) could provide a function to check if a source can be resolved by the Provider.
Why should this be improved
As I have mentioned in #69 (nice) I am currently working on a CLI to optimize tmx files. For this I resolve tsx files relative to the respective tmx file. Currently this has to be done by parsing to XML beforehand and resolving the tsx locations and then generating a TsxProvider for each. This seems rather inefficient
Any risks?
I believe that this carries minmal risk, since the current functionality could be easily kept as a implementation of a new TsxProviderBase. Therefore no public contracts, naming or functionality would need to change, while greatly extending the capability of custom TsxProvider`s.
More information
I would gladly prepare a PR for this and improving documentation both in the README.md (which currently is wrong) and in code to explain this behaviour! I have already implemented this in the "#70-tsx-provider" branch of my fork.
The text was updated successfully, but these errors were encountered:
I was also curious which purpouse the static parse(String key) method on TsxProvider servers, since static methods can not be extended in superclasses or extensions in dart as far as I know. This confused me in the beginning and since the method is ever only able to throw an exception I think it could just be removed?
What could be improved
Instead of checking by filename TsxProvider (or a new base class) could provide a function to check if a source can be resolved by the Provider.
Why should this be improved
As I have mentioned in #69 (nice) I am currently working on a CLI to optimize tmx files. For this I resolve tsx files relative to the respective tmx file. Currently this has to be done by parsing to XML beforehand and resolving the tsx locations and then generating a TsxProvider for each. This seems rather inefficient
Any risks?
I believe that this carries minmal risk, since the current functionality could be easily kept as a implementation of a new TsxProviderBase. Therefore no public contracts, naming or functionality would need to change, while greatly extending the capability of custom TsxProvider`s.
More information
I would gladly prepare a PR for this and improving documentation both in the README.md (which currently is wrong) and in code to explain this behaviour! I have already implemented this in the "#70-tsx-provider" branch of my fork.
The text was updated successfully, but these errors were encountered: