From c937137dda665453f653e99c8a2e5bcf3e07634c Mon Sep 17 00:00:00 2001 From: Martin Polanka Date: Tue, 31 Jan 2017 22:28:34 +0100 Subject: [PATCH] job config in api --- Rewritten-docs.md | 40 ++++++++++++++++++++++++++++++++-------- 1 file changed, 32 insertions(+), 8 deletions(-) diff --git a/Rewritten-docs.md b/Rewritten-docs.md index 8e1d0ce..5e17080 100644 --- a/Rewritten-docs.md +++ b/Rewritten-docs.md @@ -3136,11 +3136,11 @@ The `User` entity class contains data about users registered in ReCodEx. To allow extending the system with additional authentication methods, login details are stored in separate entities. There is the `Login` entity class which contains a user name and password for our internal authentication system, and -the `ExternalLogin` entity class, which contains an identifier for an external login -service such as LDAP. Currently, each user can only have a single authentication -method (account type). The entity with login information is created along with -the `User` entity when a user signs up. If a user requests a password reset, a -`ForgottenPassword` entity is created for the request. +the `ExternalLogin` entity class, which contains an identifier for an external +login service such as LDAP. Currently, each user can only have a single +authentication method (account type). The entity with login information is +created along with the `User` entity when a user signs up. If a user requests a +password reset, a `ForgottenPassword` entity is created for the request. A user needs a way to adjust settings such as their preferred language or theme. This is the purpose of the `UserSettings` entity class. Each possible option has @@ -3380,9 +3380,33 @@ does not have to worry about it. ### Job Configuration Parsing and Modifying -@todo how the YAML is parsed -@todo how it can be changed and where it is used -@todo how it can be stored to a new YAML +Even in the API the job configuration file can be loaded in the corresponding +internal stuctures. This is necessary because there has to be possibility to +modify particular job details, such as the job identification or the fileserver +address, during the submission. + +Whole codebase concerning the job configuration is present in the +`App\Helpers\JobConfig` namespace. Job configuration is represented by the +`JobConfig` class which directly contains structures like `SubmissionHeader` or +`Tasks\Task` and indirectly `SandboxConfig` or `JobId` and more. All these +classes have parameterless constructor which should set all values to their +defaults or construct appropriate classes. + +Modifying of values in the configuration classes is possible through *fluent +interfaces* and *setters*. Getting of values is also possible and all setters +should have *get* counterparts. Job configuration is serialized through +`__toString()` methods. + +For loading of the job configuration there is separate `Storage` class which can +be used for loading, saving or archivation of job configuration. For parsing +storage uses the `Loader` class which does all the checks and loads the data +from given strings in the appropriate structures. In case of parser error +`App\Exceptions\JobConfigLoadingException` is thrown. + +Worth mentioning is also `App\Helpers\UploadedJobConfigStorage` class which +takes care of where the uploaded job configuration files should be saved on the +API filesystem. Can be also used for copying all job configurations during +assignment of exercise. ### Solution Loading