-
Notifications
You must be signed in to change notification settings - Fork 1
Working with Projects
- Creating a Project
- Deleting a Project
- Moving a Project
- Copying a project
- Combining Projects
- Moving or Copying Items
- Organizing Projects
- Cross Project Calls
Use the ]acre.CreateProject command to create a new project.
It is also possible to create a project from scratch in the operating system by creating a new folder for the project, and putting in either a sub folder named APLSource or a text file named acre.config. The existence of either one of these items in a folder indicates to Acre Desktop that the folder is an Acre project folder. Both the APLSource sub folder and the configuration file may be empty.
To delete a project, delete the project folder in the operating system.
To move the location of a project in the workspace, edit the acre.config and change the ProjectSpace parameter. To move a project on the disk, move the folder.
To copy a project, open it with tracking turned off and create a new project:
]OpenProject c:/MyProject #.CopyOfMyProject -track=off
]CreateProject c:/CopyOfMyProject #.CopyOfMyProject
Alternatively, you can copy the project folder in the operating system. In this case you will need to edit the acre.config if you want to change the change the project space.
To combine two or more projects, open all of the desired projects under a single namespace, and then create a new project from this namespace:
]OpenProject c:/project1 #.Combined.Project1 -track=off
]OpenProject c:/project2 #.Combined.Project2 -track=off
]OpenProject c:/project3 #.Combined.Project3 -track-off
]CreateProject c:/combined #.Combined
A single item or an entire tree of items may be moved or copied, within or between projects, by using the operating system to copy or move the desired files or folders. You may also want to rename the files or folders.
A project may be opened or loaded into any namespace, at any depth, including the root namespace, #.
However, no project may be opened under another project. This means that in practice,
one should avoid root projects, as a root project precludes opening any additional project. This
restriction applies only to opening a tracked project, which is the default. No restriction applies
if the -track=off option is used.
There is not much reason to instantiate projects very deeply in a namespace hierarchy either.
If you only have one project, and its name is likely to be unique, then it may be instantiated directly under the root. For example:
#.Rumba
If you are likely to have multiple projects, or if your project names are not distinctive, then it is better to instantiate all of your projects one level down, under a common namespace. It is customary to use your company name. For example:
#.CarlisleGroup.Utilities
#.CarlisleGroup.Rumba
#.CarlisleGroup.FlipDB
A large company might introduce another level in the hierarchy to organize projects by department.
It is a good idea to organize your projects on disk in the same way; mimic the namespace hierarchy in your folder hierarchy. A typical programmer might work on multiple projects within his company, contribute to several open source projects, and use multiple projects from other companies. Thus the folder structure might look like:
c:\APLProjects
c:\APLProjects\CarliseGroup\Rumba
c:\APLProjects\CarlisleGroup\FlipDB
c:\APLProjects\Dyalog\dfns
c:\APLProjects\Dyalog\MiServer
c:\APLProjects\Dyalog\HTTPUtils
c:\APLProjects\APLTeam\LogDog
c:\APLProjects\APLTeam\Meddy
In this example, the folder c:\APLProjects maps directly to the root namespace #.
Function in one project can obviously call functions in another project via absolute paths. Alternatively, and preferably, relative paths may be used. However, using ## one or more times to move up and over in the hierarchy is still awkward and verbose, and somewhat rigid.
When one project relies heavily on another, it is better to establish a reference in the main project (and in all of the main project's sub-spaces) to the sub-project. This is typical with utility projects, where it also convenient to shorten the name of the project when naming the reference For example, if project Rumba relies heavily on project Utilities, then if:
U←#.CarlisleGroup.Utilities
is executed inside every namespace in Rumba, calling a utility function from anywhere in Rumba is a simple as:
U.foo
This puts the full path to the utility project in one and only place in your application.