Fix issue in app-pvtable for PV that contains dot in the name the last part of the name is removed

[katysaintin]

Fix issue in app-pvtable for PV that contains dot in the name (should happen with a custom datasource)
Replace last field only if it is a known EPICS fields .
All EPICS fields are in UpperCase andhas a maximum length of 4 characters ex : VAL EGU SCAN ...
Else .DESC is added to the name for example : MyPVName.Information will be MyPVName.Information.DESC for description
and MyPVName.Information.EGU will be MyPVName.Information.DESC for description too .

Improvement on PVTable , the description cell will display the DESC pv name in tooltip behind the description value.

[kasemir]

Not sure how this will work. A value (VType) can be a DisplayProvider. A PV will never be a DisplayProvider.

The following check of currentValue instanceof DisplayProvider makes sense, but thePV instanceof DisplayProvider should be removed

[katysaintin]

Please , it is the only way I found to manage EnumVType for Boolean value for my own datasource Muscade. VEnum and VBoolean Type are not implemented DisplayProvider , and the description is only defined for VNumber .. while a DESC field is a common field for EPICS, so I don't know how to consider the description for bo or bi ?
MuscadePV implements DisplayProvider , and it's simplify the code, avoiding test such as if datasource type is equals "ca" or not equals "sim" "loc" ...
The other point is, that create a DESC PV is complexify a lot , the code of the custom source.
Have you got a suggestion for me to solve my problem. Furthermore this test is not impacting the functionnement.

Thank you for the suggestion, else could I approve my pull request ?
Thank you for your understanding.
Katy

[kasemir]

@shroffk: Looks like the description was added to the wrong part of the VType and/or EPICS normative types. DisplayProvider started out with units and the min/max values for display, control, alarms. Those only apply to numeric data, not strings, enumerated, booleans. Then the description was added because PVAccess happens to provide it, but you're correct, in principle there's a description for bool/enum/string, not just numerics.

Alright, the PV Table cannot fix what's broken in channel access/pv access/normative types/vtypes. Still, maybe add a comment to the thePV instanceof DisplayProvider:

// DisplayProvider is an optional interface for VType values,
// not PVs, but the Muscade datasource happens to implement
// DisplayProvider for enum and bool PVs, so check for that here 

[shroffk]

I agree that this seems like something not handled well by VType... primarily cause the description is available differently in ca vs pva

What I think would be the best way to address this would be to remove the description from the display.

// DescriptionProvider interface
public interface DescriptionProvider {
    // Method to get a description
    String getDesc();
}

// DisplayProvider interface extending DescriptionProvider
public interface DisplayProvider extends DescriptionProvider {
    // Method to get a display
    Display getDisplay();
}

So, enums, bool, strings can implement just the DescriptionProvider and not have to provide a display which makes no sense for these types.

I am afraid how much impact such a change would have on our codeabse

[kasemir]

Yes, a DescriptionProvider would be a better approach.
Agree that this would be a painful change that also extends into the normative types/PVAccess, because it has the same idea for "display" information.
Let's defer that by about 5 years.

[katysaintin]

Hello @kasemir and @shroffk ,

I'm totally agree with you about DescriptionProvider interface addition in core-pva .
I think it is the proper way to solve my issue.
And I also agree with that the impact on epics vtype clients could be problematic.

Thank you for your help, I'm OK with the comment , for clarifying the situation.
@shroffk I will make a pull request on core-epics vtype submodule.
Have a good day and thank you again.

Katy

[katysaintin]

@shroffk: Looks like the description was added to the wrong part of the VType and/or EPICS normative types. DisplayProvider started out with units and the min/max values for display, control, alarms. Those only apply to numeric data, not strings, enumerated, booleans. Then the description was added because PVAccess happens to provide it, but you're correct, in principle there's a description for bool/enum/string, not just numerics.

Alright, the PV Table cannot fix what's broken in channel access/pv access/normative types/vtypes. Still, maybe add a comment to the thePV instanceof DisplayProvider:

// DisplayProvider is an optional interface for VType values,
// not PVs, but the Muscade datasource happens to implement
// DisplayProvider for enum and bool PVs, so check for that here 

@shroffk & @kasemir
I add the comment you ve ask in previous comment.
Is ok for you , in waiting for VType's modifiations ?

Thank you again for your help :)

[shroffk]

I opened a Issue ticket with epicsCoreJava
epics-base/epicsCoreJava#141

@kasemir In the meanwhile, would it be OK if we added changes with the above comments.... maybe even add a TODO so that we know we should refactor this in the future based on the outcome of the above Issue?

[kasemir]

Yes, I think this PR is fine when there's a comment on thePV instanceof DisplayProvider, explaining why that interface that's meant for VType data could appear here, something like

// DisplayProvider is an optional interface for VType values,
// not PVs, but the Muscade datasource happens to implement
// DisplayProvider for enum and bool PVs, so check for that here