- edited description
Add support for package structures
One of the biggest issues, at least in my opinion, with Apex development is the lack of typical java package structures. As far as I know, Salesforce isn't going to be supporting this anytime in the near future. But Illuminated Cloud has an opportunity to, at least pseudo package structures.
The IntelliJ Plugin API provides a way for developers to create what are essentially "display only" folders. In other words, you can display files in what appear to be packages in the IDE, but still keep all your source code in the typical "classes" folder Salesforce requires Apex code to be placed in.
I'm an Android developer and I learned about this via this plugin for Android's layout files. But where that plugin leverages this API for xml
files, it could also be leveraged for cls
files or any other files related to Salesforce development. I've been working on this type of plugin for Apex myself, but I think Illuminated Cloud could greatly benefit from it as well.
Ultimately, I would love to be able to package my Apex code by features.
Instead of something like this:
classes/
FooController.cls
FooRepository.cls
FooFactory.cls
BarController.cls
BarRepository.cls
BarFactory.cls
We could have something like:
classes/
foo/
FooController.cls
FooRepository.cls
FooFactory.cls
bar/
BarController.cls
BarRepository.cls
BarFactory.cls
Comments (7)
-
reporter -
repo owner - changed status to duplicate
Duplicate of
#74. -
repo owner Andrew, I'm folding this into issue
#74which I opened myself quite a bit back. Salesforce DX adds support for arbitrary folder structure which, while not the same as actual packaging/namespacing in that there's no lexical scope aspect, does provide the benefit of organizing your code base the way that you want. Given that SFDX is the way that Salesforce is guiding the development model, I resolved the linked issue with the idea that in (hopefully short) time, SFDX will provide the solution to this for most folks. Additionally to make this type of thing work for non-SFDX projects when using other tools for deployment such as the Force.com Migration Tool (ant targets), additional work is required outside of IC.Note that right now IC does support multiple modules and source roots in a single non-SFDX project. This allows you to, for example, separate test classes from production classes so they're not all munged together, or separate logical "modules" of work from one another and still be part of the same project.
-
reporter Okay, that's understandable. SFDX is definitely the way to go moving forward.
Note that right now IC does support multiple modules and source roots in a single non-SFDX project. This allows you to, for example, separate test classes from production classes so they're not all munged together, or separate logical "modules" of work from one another and still be part of the same project.
This sounds awesome, I wasn't aware.
-
repo owner Yeah, take a look at this repo for an example of an IC project with two source roots, one for production and one for test:
https://github.com/blueprinthealth/sirono-common
If you'd like an example a multi-module project, I can provide that as well. Just let me know.
-
reporter I like that repo. I really like some of the classes you have, like
Logger
andAssert
.And yeah that would be great, I would be interested in seeing a multi-module one as well.
-
repo owner - removed component
Removing component: IntelliJ IDEA (automated comment)
- Log in to comment