Options defined in CSS style sheets get a plain text field while they should get a dropdown list or number field

[bertfrees]

This worked fine in 1.5.0-beta.1.

For example:

In the CLI it still looks correct:

[marisademeglio]

The type attribute in the data returned by the web service appears to be wrong. For example, here is a request to /stylesheet-parameters where the type of hyphenation is a UID.

curl -X POST -d "@/Users/marisa/dev/request.xml" http://localhost:49152/ws/stylesheet-parameters
<?xml version="1.0" encoding="UTF-8"?>
<parameters xmlns="http://www.daisy.org/ns/pipeline/data">
<parameter 
  default="auto" 
  description="Hyphenation policy.&#xA;&#xA;The following CSS rule is included by default (where `$hyphenation` is the value of this option):&#xA;&#xA;~~~sass&#xA;:root {&#xA;  hyphens: $hyphenation;&#xA;}&#xA;~~~&#xA;&#xA;This means that words are hyphenated according to the specified policy, except where overridden by&#xA;more specific CSS rules. See the CSS specification for more info:&#xA;&#xA;- the [`hyphens`](http://braillespecs.github.io/braille-css/#the-hyphens-property) property&#xA;&#xA;In addition, special rules may apply at page boundaries, see the &#34;Hyphenation at page boundaries&#34;&#xA;option." 
  name="hyphenation" 
  nicename="Hyphenation" 
  ordered="false" 
  required="false" 
  sequence="false" 
  type="fd09145e-b2d1-4402-a89e-11429100b6a8"/>

....

[bertfrees]

This is due to a change that I forgot to mention (or maybe I thought it didn't matter because of certain assumptions I made about the GUI).

Actually the type attribute is not wrong. But while before, the value would always be either a predefined type (string/boolean/integer/etc.), or the ID of a type contained in the static list of data types that you could fetch with a single /datatypes call, now it can also be an ID of a temporary data type.

The data type definition is temporarily made available through /datatypes/fd09145e-b2d1-4402-a89e-11429100b6a8. I think it stays available one minute after the /stylesheet-parameters call.

[marisademeglio]

Ah ok ...

While we do look up custom datatypes by ID: https://github.com/daisy/pipeline-ui/blob/main/src/renderer/components/Fields/CustomField.tsx#L42

The actual fetching of all datatypes happens all at once (every 1000ms): https://github.com/daisy/pipeline-ui/blob/main/src/main/data/middlewares/pipeline.ts#L388

Would this temporary custom datatype be available at the /datatypes endpoint or is it only available at e.g. /datatypes/fd09145e-b2d1-4402-a89e-11429100b6a8?

[bertfrees]

It's not available at the /datatypes endpoint.

[marisademeglio]

Development note: I wanted to fetch the temp datatype from the main process but the IPC communication is not robust enough to prevent mixed messages on the front end (literally: one component listening for an IPC fetch response will hear the response of the fetch that another component requested, because the events are using the same channel name).

So I used the in-browser fetch, which works because we start the pipeline with CORS disabled, but this is not necessarily always the case, e.g. with hypothetical remote pipeline engine configs.

Not sure if there's a way to use dynamic channel names, @NPavie any ideas?