Improve connector names returned by connector search #648
Conversation
nipunayf
added
the
Area/FlowModel
nipunayf
force-pushed
the
fix-connector-names
branch
from
d0d0b0e to
8172296
Compare
...r-core/src/main/java/io/ballerina/flowmodelgenerator/core/search/ConnectorSearchCommand.java
Outdated
Show resolved
Hide resolved
| @@ -168,7 +168,7 @@ | |||
| }, | |||
| { | |||
| "metadata": { | |||
| "label": "Persist.redis RedisClient", | |||
| "label": "Redis RedisClient", | |||
There was a problem hiding this comment.
is this correct? :)
There was a problem hiding this comment.
Yes, we need to keep "persist" in the name. However, also thought of removing "persist" from the search since we're not supporting persistence in the GA.
There was a problem hiding this comment.
But in that case we'll end up displaying similar names for 2 modules right? (ballerinax/persist.redis and ballerinax/redis).
if we're not supporting persistence in the GA, one option would be to remove all the persist related modules from the palette and the search itself (and add after the GA)
There was a problem hiding this comment.
| @@ -264,7 +264,7 @@ | |||
| }, | |||
| { | |||
| "metadata": { | |||
| "label": "Zoho.crm.rest Client", | |||
| "label": "Rest Client", | |||
There was a problem hiding this comment.
IMO having only the last part of the package name hierarchy may look ambiguous in many cases.
As an example, something like Zoho CRM Rest Client would be a better option for the above scenario.
Can't we improve our name generation logic accordingly (probably will have to extend the CONNECTOR_NAME_MAP)
There was a problem hiding this comment.
@hasithaa thoughts?
There was a problem hiding this comment.
Shall we make only the common one for now? Ideally this info should come from the library (or from the library team).
There was a problem hiding this comment.
Also, the package name appears under the label, so the information is still presented (not the best way tho).
There was a problem hiding this comment.
Shall we make only the common one for now? Ideally this info should come from the library (or from the library team).
Yes, getting display names from the packages themselves would be ideal.
Until we get there, wouldn’t it be better to add custom mappings for other modules too? (+1 to doing it in a separate PR).
The main reason is that while pro-code users understand package names better, low-code users may find them (especially hierarchical ones) hard to grasp
Purpose
This is done by: