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
Some parts of the TxNative class already allow the user to provide their own implementations of various components via dependency injection. The AbstractCache class being a good example of this. It would be good if users could also provide their own implementation of the CDSHandler class.
Users can already point the TxNative class at a different instance of the Transifex CDS via cds_host, and since the code for the CDS is available at https://github.com/transifex/transifex-delivery there's nothing stopping them creating their own CDS (using transifex-delivery as documentation on what endpoints need to be available and how they should behave) and pointingTxNative at this to provide their own implementation at the service level, rather than the application level. However, if your application handles content delivery, then you're forced to either split this out in a separate service (which might be a good thing, but equally might not be), or your application is forced to make requests to itself over localhost (which I really don't want to do - and I can't imagine anyone else would either).
Allowing users to provide their own CDSHandler would provide a lot more flexibility, allowing users to bolt on extra functionality - maybe the source strings are coming from different sources that don't have visibility of one another and you want to check for duplicates to remove wasted effort translating duplicate strings, or maybe you want to run some sort of analysis on the source strings before pushing them to the CDS. Maybe you want to use a local database for content delivery, meaning you don't need to push and pull the translations over HTTP at all. These are just some examples off the top of my head to try to justify the development effort required here.
If this is something that Transifex don't have resource to do, but are happy to adopt it should another contributor carry out the work, then I'm happy to fork and submit a PR for this if I can find some spare time to do so.
The text was updated successfully, but these errors were encountered:
Some parts of the
TxNative
class already allow the user to provide their own implementations of various components via dependency injection. TheAbstractCache
class being a good example of this. It would be good if users could also provide their own implementation of theCDSHandler
class.Users can already point the
TxNative
class at a different instance of the Transifex CDS viacds_host
, and since the code for the CDS is available at https://github.com/transifex/transifex-delivery there's nothing stopping them creating their own CDS (usingtransifex-delivery
as documentation on what endpoints need to be available and how they should behave) and pointingTxNative
at this to provide their own implementation at the service level, rather than the application level. However, if your application handles content delivery, then you're forced to either split this out in a separate service (which might be a good thing, but equally might not be), or your application is forced to make requests to itself overlocalhost
(which I really don't want to do - and I can't imagine anyone else would either).Allowing users to provide their own
CDSHandler
would provide a lot more flexibility, allowing users to bolt on extra functionality - maybe the source strings are coming from different sources that don't have visibility of one another and you want to check for duplicates to remove wasted effort translating duplicate strings, or maybe you want to run some sort of analysis on the source strings before pushing them to the CDS. Maybe you want to use a local database for content delivery, meaning you don't need to push and pull the translations over HTTP at all. These are just some examples off the top of my head to try to justify the development effort required here.If this is something that Transifex don't have resource to do, but are happy to adopt it should another contributor carry out the work, then I'm happy to fork and submit a PR for this if I can find some spare time to do so.
The text was updated successfully, but these errors were encountered: