I’ve made a lot of progress on this and put up a preview of the current state. Only components in the latest branch are done (not dataformats, eips, languages, other, and not other versions).
The arrangement of, in particular, API data didn’t make much sense to me so I reorganized it so relevant information is all together, and added a lot of in-page links. There are a couple of glitches… - “debugging code” showing e.g. "pascalcasescheme: Twilio” - For some reason lists don’t display properly in the first row of tables. At https://camel-preview-1.s3.us-west-2.amazonaws.com/components/latest/twilio-component.html#_path_parameters_2_parameters compare the apiName row and the methodName row. https://camel-preview-1.s3.us-west-2.amazonaws.com/components/latest/twilio-component.html is the most complex page, and can be compared to the current site at https://camel.apache.org/components/latest/twilio-component.html. I haven’t published the updates needed to the Asciidoctor extension that does the generation, so a PR is not yet feasible. There are some other effects of upgrading to the latest Antora 3 alpha that I’ll discuss in another email. David Jencks > On Aug 7, 2021, at 2:55 AM, Zoran Regvart <zo...@regvart.com> wrote: > > Hi David, > Thanks for this, I think this is a good thing as it would help in cutting > down the need to touch adoc files in build/regen. The only concern I have is > with the edge cases, some of those are a bit convoluted (IIRC components in > the “other” category have this a bit different). But going with the JSON > files from the catalog should be correct… > > +1 from me in trying this approach > > zoran > -- > Sent from mobile > >> On 6. Aug 2021, at 18:40, David Jencks <david.a.jen...@gmail.com> wrote: >> >> Following on Claus’s work on >> https://issues.apache.org/jira/browse/CAMEL-16844 >> <https://issues.apache.org/jira/browse/CAMEL-16844> I investigated a >> different approach to generating the tables of component and endpoint >> options. Some time ago I wrote an Asciidoctor extension that queries a json >> document and renders the results in various ways. Using this, it looks like >> the tables can be generated during the Antora build using something like >> this: >> >> >> == Component Options >> >> [cols="2,5,^1,2",options="header",separator=|] >> |=== >> | Name | Description | Default | Type >> |=== >> >> jsonpathTable::example$json/ahc-ws.json['nodes$.componentProperties.*', >> '*${path[2]}* (${value.group}),${value.description},${value.default || >> ""},${value.type}'] >> >> == Endpoint Options >> >> === Path parameters >> >> [cols="2,5,^1,2",options="header",separator=|] >> |=== >> | Name | Description | Default | Type >> |=== >> >> jsonpathTable::example$json/ahc-ws.json['nodes$.properties[?(@.kind=="path")]', >> '*${path[2]}* (${value.group}),${value.description},${value.default || >> ""},${value.type}'] >> >> >> === Query Parameters >> >> [cols="2,5,^1,2",options="header",separator=|] >> |=== >> | Name | Description | Default | Type >> |=== >> >> jsonpathTable::example$json/ahc-ws.json['nodes$.properties[?(@.kind=="parameter")]', >> '*${path[2]}* (${value.group}),${value.description},${value.default || >> ""},${value.type}'] >> >> >> This is not entirely complete, as the counts and a bit of text is left out. >> >> I think this block (when completed) could be put in a partial with the json >> file name as an attribute set in the including file. Then the component >> .adoc would have only text specific to the particular component, and the >> layout of the tables could be changed for all components by changing the >> included partial. >> >> This would require exposing the json files from which the tables are >> constructed in the Antora examples folder. I’d suggest using the Antora 3 >> symlink facility to do this and to avoid copying the component .adoc files. >> >> Does this seem like an approach worth investigating further? If so I’ll work >> on a PR. >> >> David Jencks
