search

SCWells72 / sirono-common

Common Apex utility classes and frameworks used by Sirono products
Apache License 2.0
110 stars 28 forks source link

Apply sirono_ prefix to components #3

Open PeterLin888 opened 6 years ago

PeterLin888 commented 6 years ago

Hi Scott, Thank you for your excellent "Sirono-common Apex Class Library" at DF18! I noticed that you mentioned about Unlocked Packages which will be GA on Oct 13, 2018.

And you also mentioned that you were waiting for the official ways to publish this open source repository as some kind of packages (probably second generation packages, e.g. Unlocked Packages).

It seemed that there are three ways to get this repository library to install in our Production org or Business org.

  1. You package it for us and we install it using the 04t version id provided by you. 1.1 Unlocked Package without Namespace 1.2 Unlocked Package with a Namespace 1.3 Second Generation Managed Package with a Namespace

  2. We as users of this repository package it by ourselves, i.e. we git clone this and publish our own packages and install it using our own 04t version id. 2.1 Unlocked Package without Namespace (I believe a lot (if not most) of the Salesforce enterprise customer will choose this option.) 2.2 Unlocked Package with a Namespace (not sure if anyone will choose this option) 2.3 Second Generation Managed Package with a Namespace (ISV only?)

  3. Copy and paste...

For 2.1 opiton above, similar to force-di 12 (e.g. di_Injector.cls), would you like to consider refactoring all the class name with a sirono_ prefix (e.g. sirono_CollectionUtil.cls)?

In this way (2.1 option as above), as users of this repository, we will have some benefits as below.

  1. The sirono_ prefix will help separate the class names with the other local existing class names.
  2. [Git pull and create a new Unlocked Package version] will simply easily upgrade our own version to a new 04t version id and then we can install it.
  3. We will always have opportunities to review and decide whether we want to accept all or part of the changes from the repository.

Assuming if you choose the option 1 above.

Personally, I prefer 2.1 option above similar to the force-di. I will try to use your powerful IC2 to see how much efforts I need to add sirono_ prefix to all classes in this repository.

Thank you so much for this sirono-common repository and the IC2. Peter

SCWells72 commented 6 years ago

Hey, @PeterLinBiz. Thanks for logging this request to allow us to continue this discussion. What I'm thinking about doing is adding a script to the repo that you could run to add a prefix of your choice to the names of the library types and all usages of those types within the library and another one you could use to remove that prefix. To respect the rather low limits on Apex type name lengths, the default/standard prefix would likely be sc, e.g., sc_Logger, sc_CollectionUtil, etc. Basically if you wanted to apply a prefix, you'd just do something like:

$ bin/addPrefix.sh <target-directory> [<optional-namespace>]

and the script would copy the contents of the sirono-common Git repo into the required target directory (to avoid changing files in-place) with the desired prefix, either the explicitly-specified one or the default of sc if unspecified. Either way the prefix will also include a trailing underscore.

I certainly appreciate that in order to incorporate types from this class library into another project, you often want/need to isolate those types from your own, and in the absence of a first-class scoping mechanism in Apex (aside from managed package namespaces), this type of explicit name-mangling is what we have. However, since the library was released without any type of prefix, I also don't want to break existing consumers of it. That's why I'm considering this optional prefix approach.

And of course at some point I still hold out hope that Salesforce will address this properly with second-generation packaging so that open source projects can isolate themselves from their consumers without the weight of ISV-oriented managed packages which carry a tremendous weight even in 2GP.

What do you think about this approach for the near-to-medium-term?

PeterLin888 commented 6 years ago

Hey @SCWells72 , I really like the idea of a script of $ bin/addPrefix.sh . So, every time when you have a new commit, I can pull it and have my own scLogger, and I can have my private sc repo.

I wonder whether you plan to have a repo as https://github.com/blueprinthealth/sirono-common-sc to hold the sc_ version.

If not, is it okay for me to push an after script sc_ version to GitHub as my public repo https://github.com/PeterLinBiz/sirono-common-sc ?

Thanks again for the "bin/addPrefix.sh"!!! Peter

SCWells72 commented 6 years ago

@PeterLinBiz I'm chatting through this with my team. Before I provide a concrete response here, let me work with them on the way we definitely want to proceed and then I'll answer your questions more specifically. I should have more information soon.

PeterLin888 commented 5 years ago

@SCWells72 I found that my production org only contains one Apex Class TriggerHandler.cls which has name conflict with this excellent library. I will probably just use Illuminated Cloud 2.0 to refactor its name and deploy all in this library using an Unlocked Package without any prefix. It seemed that I don't need to worry about whether I want a "sc_" prefix. And thanks a lot to you and your team for sharing this library as open source.

SCWells72 commented 5 years ago

Hi, @PeterLinBiz. I'm so sorry that this has languished as it has. I'd been meaning to reach out to you recently to provide some kind of update. We have been absolutely slammed with a customer implementation and this hasn't received due attention.

I'm very glad you were able to adopt the library without much of a ripple effect, but I also apologize again for the lack of attention to this request.