brailleapps / braille-utils.api Goto Github PK

This api should probably be merged with dotify.api (but perhaps it too should subsequently be renamed). The reason for this is that there is not enough distinction between the apis to motivate separate packages considering project overhead and team size. Also, bringing these apis together might benefit the development of this api as it is currently somewhat behind in code style etc.

Things to do before merging:

• APIs that are not fit for this new location should be deprecated, namely the validator interface (#2)
• All projects that depend on this should be prepared to be updated to Java 8 (as they will have to use Java 8 once they start using the new api) (brailleapps/issues#9)
• Release a minor/service version (because some things have been deprecated since the last release)
• Rename README.md to readme.md (or do the merge on Linux, or change readme.md in dotify.api to README.md)
• Release a clean major version (see #8)
• Fix #9
• Add a notice that the API has been deprecated (see for example dotify.task-api)
• Release a final version

This is probably going to be replaced by the new interface in dotify.task-api. See ologolo/streamline-api#7

In EightDotFallbackMethod, the supported fallback methods are:
mask, replace, remove.

Add support for "fail" option as fallback method. If this method is chosen, an
exception should be raised if a character in the 2840-28FF range is encountered.

The get/setFeature methods are overused (in fact, they are relied on for normal operation, most notably for getting/setting a Table), this is confusing for new users of the API. The Embosser interface implies that some features can be set (via various "supports"-methods), but the relationship between this interface and EmbosserFeatures is completely implicit.

The get/setFeature should remain, but only for non-API use, meaning features not defined by the API.

Embossers are required to publish internal tables in order to be used with it.
Instead, the embossers could provide the list of internal tables directly.
These could be set by identifier.

The current mechanism is only used if the embosser allows other tables and
should be set using a Table instance.

Currently, the embosser manufacturer is often included as part of the model name in order to get all models from a particular manufacturer next to each other in a UI. This works fine for Braillo and Index, but it doesn't work as well for manufacturers with long names (who typically do not start their model names with the company name as Index and Braillo does). Separating these two would improve user interface experience.

This class uses an odd pattern, perhaps refactor this to use a more regular builder?

• Remove the inheritance of EmbosserProperties from EmbosserWriterProperties
• Require non null identifier in AbstractFactory

CustomPaperCollection should use the enum singleton pattern

The javadoc for EmbosserFeatures contains descriptions with question marks.

Support add and remove papers in PaperCatalogService. CustomPaperCollection should not be used directly.