blob: 8e2ee4e2bb91b0c381bd96d2923e0b698ca2545f (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
The intent of "shared" is to provide utility code that samples and tools
can share.
*** Shared code MUST go in "internal" if it is ALSO used by
*** the APEX SDK or by any APEX Module.
*** However, code in "internal" MUST be self-contained. ***
That is, it should not rely on the APEX SDK. Otherwise tools need to
drag in all of APEX in order to compile, and we end up with a statically
linked APEX library living along side a dynamically linked APEX library.
Description (from the APEX Architecture Document):
* Internal shared code (in APEX/shared/internal) - this is
used by APEX internal code, but is designed to be self-contained.
That is, it doesn't rely on code from the framework or modules.
In this way, "friend" projects like tools can share this code
with APEX without having to include the the rest of the APEX
source. For example, streaming utilities are defined here, as
well as the APEX streaming version number. Tools need this to
create and stream out APEX objects using the proper versioning
system.
* Public shared code (in APEX/shared/external) - these are
utilities that tools and external applications like sample apps
can share. For example, an implementation of the user renderer
is here, used by the DestructionTool and SimpleDestruction
sample. Code in this category should not be used by internal
APEX source. This helps to decouple the code used for applications
from the APEX SDK version.
|