Diary
Opened this issue · 4 comments
Some thoughts on the project, nothing specific.
The full drill through from data to UI is a super powerful argument for public acceptance. At the moment the data and template are available in devtools plugin. What is missing:
- step by step guide on xslt debug
- video on the guilde
- inline debug
- declarative data source and request to work with web service data.
The guide is lowest fruit to pick, data source is most valuable.
Thinking about the mix of data source, data schema, and response variations as part of DWA and HTML/XSLT stack.
Why those have to be in all those stacks?
Beyond my gut fillings, there are some quite rational reasons. Struggling to formalize.
http-request
needs the parameters passed and available for request and following transformation.
While with explicit parameters like url
or method
everything is clear ( just use them as attributes ), other parameters do not fit into such declarative expression.
HTTP headers are sample of such. Due to multiple headers can be associated with request, expressing over single headers
attribute would be more JS-centric, and DOM-oriented transformation unfriendly. Besides the attribute, parameters can be passed in payload as header
with name
attribute and value as value
attribute or content:
<http-request>
<header name="x-version" value="1.0"></header>
<header name="Content-Encoding">utf-8</header>
</http-request>
To make it shorter headers can be wrapped into headers
<http-request>
<headers name="x-version" value="1.0">
<x-version>1.0</x-version>
<content-type>application/xml</content-type>
</header>
</http-request>
Since request could have multiple parameters and payload besides headers, elevating the headers to direct child level would mix with payload.
The headers can be expressed as attributes prefixed with header-
. I.e.
<http-request header-content-language="de-DE" header-encoding="utf-8" ></http-request>
The advantage of header-
prefixed attribute is missing the interference with payload which can be kept pristine in the component body.
Content-Type
is the special header which has to be used when interpreting the payload in order to apply as media-type
MIME type, as charset, as boundary