Page MenuHomePhabricator

Normalize output interfaces
Open, Needs TriagePublic


Classes were developed from the most basic (selection and transformation steps) to the more complex (domain). It would now make sense to rethink the output interfaces so they are more easily handled by the consumer classes (above in the hierarchy). Ideally, they should more or less resemble what the top (domain) class returns.

Event Timeline

It may have happened that, in an effort to simplify the outputs from each object class, we may have ended with oversimplified outputs, leaving little room for changes in consumer classes up in the hierarchy.

For example, it has just happened to me that I wanted to add the label of the template used for a translation in the Web2Cit-Server output, to realize that template labels had not been included in the Web2Cit-Core output.

Domain's translate method output:

  • May include all translation templates in the same URL path pattern group as the target, regardless of whether they are applicable or not, and even regardless of whether they were tried or not. Not applicable translation templates may simply include the applicable=false property, and templates not tried may simply include an applicable=undefined property.
  • May be organized in targets. This way, we could have a targets property, including one or more translation targets, and each of them including one or more translation results, one per template (see previous point). The test method of the Domain object class may then simply add a test object to each target, and a score object to each result.

It has been suggested in T305163 and T317441 that template (and other) outputs may include an errors array including caught errors, such as translation step configuration or application errors.