-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is the Four Level Hierarchy for Scripts required? #1058
Comments
Didn't I open an issue for this already? |
I didn't search... |
It was #543 |
I can't find an explicit answer to my question in #543 it seems to mainly be about the conversion of the old include style to the new one. |
@plata how do we continue? Do we retain the four level structure or do we want to replace it with something else? |
I don't like the 4 levels because it produces strange directories like "Engines/Wine/Engine" but I do not want to decide this without @qparis. |
I agree that we require @qparis for a final decision, but we can only decide about something if we have a PR with a possible solution. So any ideas how to solve the issue without a four level hierarchy? :) |
I think this should be in #543 already but the idea is basically: do not structure the repository (and DTOs in Java) in category, application, script. Instead, manage only the scripts directly in a map (include path → DTO). To list e.g. all games do: |
Where should this |
During the load. It would replace the repository DTO hierarchy. |
I don't think that we can fully replace our current DTO hierarchy. For example we still require |
It is because the includes are structured like |
I don't think we can remove the DTO objects and their hierarchy. What we can do in my opinion is decoupling the scripts from the DTO hierarchy. The question is then how do we detect which script belongs to which |
We need the namespace hierarchy only for scripts which are listed from Java. For stuff like utils, it's completely irrelevant where they are located in the hierarchy and they do not have to follow the hierarchy. If we accept that some scripts must use this hierarchy, we can get rid of the concept of |
So we need to add additional methods to the Maybe something like this: class RepositoryDTO {
// responsible for fetching all scripts at construction time
// the fetched scripts are saved in a Map<String, File> object, where a script id is mapped to the file it links to
private final ScriptFetcher scriptFetcher;
// every application contains scripts
List<ApplicationDTO> getApplications();
// performs a selection of the applications based on the provided application id
List<ApplicationDTO> getApplications(String applicationId);
// every engine contains settings, verbs and tools
List<EngineDTO> getEngines();
// performs a selection of the engines based on the provided engine id
List<EngineDTO> getEngines(String engineId);
// the utils scripts
List<UtilDTO> getUtils();
// performs a selection of the utils based on the provided util id
List<UtilDTO> getUtils(String utilId);
} |
A DTO is just data class (i.e. json type). It should never have references to a code class |
Sorry, I've clicked on the wrong button |
Hmmm. Ok then a possible alternative is to "flatten" our DTO hierarchy. This can be done by removing the references between our DTO objects. Essentially this would reduce our DTO classes to only contain the information specified in the corresponding The references between the DTO classes (e.g. class RepositoryFetcher {
public List<ApplicationDTO> fetchApplications(IdQuery category);
public List<ScriptDTO> fetchScripts(IdQuery application);
public List<EngineDTO> fetchEngine(IdQuery query);
...
} When looking at the code snippet you will discover that I've used input parameters of type interface IdQuery {
String getId();
}
class ApplicationDTO implements IdQuery {
...
}
class ScriptDTO implements IdQuery {
...
}
class EngineDTO implements IdQuery {
...
}
class UserQuery implements IdQuery {
private final String id;
public UserQuery(String id) {
this.id = id;
}
public String getId() {
return this.id;
}
}
... |
Yes, that's what I had in mind. The thing I'm not quite sure about: Should the |
In my example above I assumed it knows about |
Yes. However, that's only a small point. First, we should decide if we want continue with the hierarchy or not. |
This is fine if you remove the structure, as long as the structure stays simple to navigate in |
Now that the scripts are working again (#1076) I think we should approach this issue next so that we can finalize our script repository structure. When we start working on this I think we also should include PhoenicisOrg/phoenicis#1813 in the scope of this issue. @plata what do you think? |
Makes sense. However, I do not find the time currently to do something about it. |
I'm thinking about to merge the wine implementation and object scripts in a single script in
Engines/Wine/Engine
. This in turn would lead to the engine script and json file being on the same level as theapplication.json
file.Is this allowed/do we support this?
The text was updated successfully, but these errors were encountered: