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 <jans...@gmail.com> 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 <dk...@apache.org> 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 we >> 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 not >> 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: >> >> http://camel.apache.org/file2.html >> >> 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” or >> “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 >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> > > > -- > Cheers, > Jon > --------------- > Red Hat, Inc. > Email: jans...@redhat.com > Web: http://redhat.com > Twitter: jon_anstey > Blog: http://janstey.blogspot.com > Author of Camel in Action: http://manning.com/ibsen -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2nd edition: https://www.manning.com/books/camel-in-action-second-edition
