The current mechanism uses a control
file for static info and a control.pl
for requesting more information to complete the template. This format works for the command line but it would be complex to implement if we wanted to allow graphical interfaces to interact with NIC to generate projects from these templating system.
In this issue I'd like to propose a significant architectural change that would allow integration with both command line and graphical interfaces alike while slightly expanding the versatility of the NIC templating system.
Example of current architecture (NIC v2):
NIC/control
name "iphone/tweak"
prompt FILTER "MobileSubstrate Bundle filter" "com.apple.springboard"
constrain file "control" to package
constrain "theos" to link_theos
NIC/control.pl
my $default_kill = "SpringBoard";
NIC->variable("KILL_PROCS") = "";
my $kill_apps = NIC->prompt("KILL_APPS", "List of applications to terminate upon installation (space-separated, '-' for none)", {default => $default_kill});
if($kill_apps ne "-") {
NIC->variable("KILL_PROCS") = "INSTALL_TARGET_PROCESSES = ".$kill_apps."\n";
}
Instead I'd like to propose a YAML file
NIC/control.yml
---
name: tweak
platforms:
- iphone
constraints:
control: package
theos: link_theos
variables:
- FILTER:
prompt: "MobileSubstrate Bundle filter"
default: com.apple.springboard
- KILL_PROCS:
prompt: "List of applications to terminate upon installation (space-separated, '-' for none)"
default: SpringBoard
cancel: -
format: "INSTALL_TARGET_PROCESSES = {}"
Under this model, the name from the current model is split into platforms
and name
, allowing simple filtering. In cases where a template, like the tool one, supports multiple platforms, the user can choose which one to generate for.
Documenting NIC should come first so we can identify the internal/builtin variables and constraints and how they work, plus functionality like ignored variables.
This is by no means the final draft and I'm open to discussions.