camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: "advanced" label for params?
Date Thu, 10 Sep 2015 14:00:43 GMT
> Using the word advanced is imho not always the best word for uncommon
> options. Maybe some good english word for "uncommon / seldom / rare"
> can be used.

The main reason I suggested “Advanced” is that that is what Apple seems to use in it’s
gui for similar things.   If you are on a Mac, go to your Settings app and open up the “Security
& Privacy” settings.   There is an “Advanced…” button.   Likewise in the “Internet
Accounts”.   There were a few other places I saw this as well while poking around the various
OS X applications preferences panels.     

Of course, this could be something Apple has localized to my US version of OSX.   No idea.
  :-)     No idea what MS does in Windows.


> On Sep 10, 2015, at 2:30 AM, Claus Ibsen <> wrote:
> Hi
> Yeah it was the idea to add more labels to the options. The idea is
> that you can append more labels separated by comma, eg
> "consumer,common,security"
> "consumer,common"
> "consumer,networking"
> "consumer,security"
> And if a component is only consumer or producer then that would be
> implied, and you do not need to have "consumer" or "producer".
> Though as we know naming is hard in IT so sometimes it can be a bit
> hard to find a good name and categorize all those options.
> And there is also some inherited options like synchronized /
> exchangePattern that most people do not use, but what label should
> they have?
> Using the word advanced is imho not always the best word for uncommon
> options. Maybe some good english word for "uncommon / seldom / rare"
> can be used.
> If we get all that done eventually then all the components is
> documented out of the box and is also tooling friendly and using the
> same grouping of the options, as well documentation (its just the
> javadoc) eg all the stuff there is out of the box in the json file.
> On Thu, Sep 10, 2015 at 2:00 AM, Jon Anstey <> wrote:
>> Yeah, I like the idea of an "advanced" label for non-common options. I've
>> often been overwhelmed myself at the list of options for some components
>> :-) I imagine it also clutters up UIs for the sake of showing options only
>> a small number of people may ever use.
>> Cheers,
>> Jon
>> On Wed, Sep 9, 2015 at 2:23 PM, Daniel Kulp <> wrote:
>>> I’m working with the UI folks in Talend to enhance the tooling that we
>>> provide.   Right now, we have various components with specific parameters
>>> exposed.  This “kind of works”, but as new parameters are added in Camel
>>> have to keep things up to date and such.    We’re trying to switch to using
>>> the json stuff that is generated at build time (great stuff, BTW) so that
>>> all the parameters that are available is presented to the users.
>>> Currently, there are labels for “consumer” and “producer” and anything
>>> labelled one of those is common between the two.   That’s a great start.
>>> However, while testing with some users, we’ve run into a usability
>>> problem:  some of the components have soooooo many parameters, many of
>>> which would rarely ever be used, that trying to find the useful stuff that
>>> they care about is harder than it should be.   For example, take a look at
>>> the file component:
>>> There are 7 “common” options, but for the consumer, there are then an
>>> additional 51 options.  It’s really too many to present in a single list
>>> and not have the user go “what?!?”.
>>> Would there be any objections to adding an “advanced” label to options
>>> that are generally not normally used by say 90% of the use cases?   I know
>>> that determining whether something is “advanced” or not can start heading
>>> down the path of bike shedding and the whole “what’s advanced for one user
>>> isn’t for another” and all that, but I think we need to have something to
>>> help out with this.   Another thought was an additional  “advanced=true”
>>> “userlevel=1” or similar attribute to denote this, but the label
>>> functionality is already there and it seems to be perfect for this.
>>> I did quick look to see how many options we have.   I parsed/processed all
>>> the component json files (didn’t look at the models or data format) and
>>> there are over 10,000 options.   It’s a huge task to go through each of
>>> them, but if we can agree on a path forward, we can start tackling some of
>>> the more used components and then see how that works.   File, http, jetty,
>>> jms/sjms, etc…    Longer term, this info could be used to provide more
>>> useful component pages for the docs, putting the more useful stuff at the
>>> top.
>>> Thoughts?  Objections?  Other ideas?
>>> --
>>> Daniel Kulp
>>> -
>>> Talend Community Coder -
>> --
>> Cheers,
>> Jon
>> ---------------
>> Red Hat, Inc.
>> Email:
>> Web:
>> Twitter: jon_anstey
>> Blog:
>> Author of Camel in Action:
> -- 
> Claus Ibsen
> -----------------
> @davsclaus
> Camel in Action 2nd edition:

Daniel Kulp -
Talend Community Coder -

View raw message