The changes are online now:
https://camel.apache.org/camel-quarkus/latest/reference/index.html -- P
On 18/08/2020 00:22, Peter Palaga wrote:
I implemented some of the ideas discussed in this thread in
https://github.com/apache/camel-quarkus/pull/1534
In particular, the above PR lets the List of extensions page show an
alphabetically sorted list of extensions instead of using Camel concepts
(components, languages, ...)
The lists of supported components, languages, data formats, etc. are
still there but were moved to new dedicated pages. We can revisit the
question whether we need these pages once we have links from Camel
component pages to Camel Quarkus extension pages.
Thanks,
-- Peter
On 02/06/2020 15:07, Peter Palaga wrote:
On 01/06/2020 19:22, David Jencks wrote:
Hi Peter, that all makes sense!
I think I’m left with 2 1/2 questions :-)
- Would it be useful to have a page with a table of extensions,
presumably arranged alphabetically? (this is what the current page
title implies and doesn’t provide).
+1 from my side
— If so, would it be useful to have this list also in the nav (I I
think you said people wouldn’t often use it, but if it’s collapsable
and easy to do, it might still be worth it).
+1
- If we can enhance the main camel component etc pages to link to at
least the quarkus extension containing them (when present), do the
current tables in camel-quarkus listing the supported components etc
and linking to the extension page containing them provide significant
value or are they confusing?
For reasons I mentioned earlier in this thread, my preference is to
change the existing
https://camel.apache.org/camel-quarkus/latest/list-of-camel-quarkus-extensions.html
to contain a table of extensions (like you mentioned above) instead of
the split into the Camel categories.
But I am still open to hear reasons why we should do something else
rather than this.
Thanks,
-- P
Thanks!
David Jencks
On Jun 1, 2020, at 1:50 AM, Peter Palaga <ppal...@redhat.com> wrote:
Hi David, inline...
On 01/06/2020 06:55, David Jencks wrote:
I’ve been studying the camel-quarkus website wondering about
generating the table of extensions and I have some questions….
The page is named “list of extensions” but that’s not what it
actually is. It has tables of components, data formats, and
languages, with links to the extension they are in. I find this
confusing.
You are right, it is confusing.
What are users likely to find most useful? Are they likely to
think of the components, data formats, and languages they need and
want to know what extensions are needed to run in camel-quarkus? Or
are they going to search directly for extensions? Or both?
I pondered on that too and here is the result:
* The structure on the Camel Quarkus side does not matter in most
cases because the extensions are mostly 1:1 to their respective
Camel bits.
* The extension pages need to exist because they are required as a
target for the "extension guide" link from https://code.quarkus.io/
So the question is whether we need both or extension pages only.
* Some extension pages contain Camel Quarkus specific config
options, limitations and/or other info that is relevant to all
included Camel components, languages and data formats. It is
important that users see that Camel Quarkus specific info. Esp.
googling for "camel quarkus <camel-bit-name>" should bring a page
listing that Camel Quarkus specific info. I cannot see a way how to
deliver that info (without too much repetition) within a structure
defined by Camel concepts.
* Based on the above, I think we should not impose the Camel
structure on Camel Quarkus. I think Camel structure should be kept
in its original and natural location, i.e. in the Camel Components
reference area. At the same time, we should try to enhance the
components, language and data format pages there to contain info on
which platforms (SB, Karaf, WildFly, Quarkus) the given bit is
supported. Something like
| This [ component | language | data format ] is supported on
| * http://link.to/the-given-spring-boot-starter-page[Spring Boot]
| * http://link.to/the-given-karaf-bundle-page[Karaf]
| * http://link.to/the-given-camel-quarkus-extension-page[Quarkus]
| ...
| Please refer to the above links for the given platform's specific
| information.
If it’s the former, I think having separate index pages for the
types of “thing” would be a good idea, to match the main camel
website. Then there’s the question of what you get to when you
select a “thing”. The extension pages don’t seem to me to be a very
good match for clicking on a “thing” in an extension. I think it
would make more sense to show a wrapper around most of the main
camel “thing” page, the wrapper indicating something about the
extension that provides the “thing”. Leaving out the information
not useful for camel-quarks would be a good idea too… I think this
includes the “main” camel maven coordinates.
I find this option cumbersome, thus -1 for me.
As part of this question, is Spring Boot relevant to camel-quarkus?
No
On the other hand, if users are more likely to be looking for
extensions directly, then actually having a table of extensions
would be a good idea. The list of extensions could also show up in
the nav as a collapsible level 2 list.
Users rarely use navigation, they rather come via Google. What
matters is whether the page they were brought to contains the
information they look for.
Furthermore, would it be good to have links from the main camel
“thing” pages to the quarkus extension providing them?
Definely +1
What do others think?
Thanks,
-- Peter
