Stand-alone app for save-and-restore search results#3279
Stand-alone app for save-and-restore search results#3279georgweiss wants to merge 3 commits intomasterfrom
Conversation
...nd-restore/app/src/main/java/org/phoebus/applications/saveandrestore/FilterViewInstance.java
Show resolved
Hide resolved
| SaveAndRestoreApplication saveAndRestoreApplication = (SaveAndRestoreApplication) appDescriptor; | ||
| AppDescriptor saveAndRestoreAppDescriptor = ApplicationService.findApplication(SaveAndRestoreApplication.NAME); | ||
| if (saveAndRestoreAppDescriptor != null && saveAndRestoreAppDescriptor instanceof SaveAndRestoreApplication) { | ||
| SaveAndRestoreApplication saveAndRestoreApplication = (SaveAndRestoreApplication) saveAndRestoreAppDescriptor; |
There was a problem hiding this comment.
The cast can be made type-safe by changing the the if-statement to
if (saveAndRestoreAppDescriptor instanceof SaveAndRestoreApplication saveAndRestoreApplication) { ...
There was a problem hiding this comment.
How is it not type-safe the way it stands?
There was a problem hiding this comment.
if (x instance of ABC)
{
ABC abc = (ABC) x;
is type-safe.
.. except one could have typos and accidentally do this:
if (x instance of ABC)
{
XYZ abc = (XYZ) x;
In the newfangled syntax, the type is only written once
if (x instance ABC abc)
There was a problem hiding this comment.
As a downside, the new syntax is ugly.
While at it, the null-check isn't necessary. if (x instanceof XXX) is false for x=null, so can be shorter and more readable .. which does free up space for the new ugly syntax
There was a problem hiding this comment.
@georgweiss: You are right that casting (in Java) is type-safe. However, a runtime-exception will be thrown if the cast doesn't succeed, and the compiler doesn't check that the runtime exception is caught.
With the pattern matching construct the compiler can give better guarantees: in the body of the then-clause of the if-expression it is known that the cast succeeded and that the variable has the correct type. If the cast didn't succeed for some reason, this can, e.g., be handled in an else-clause (where the variable that was bound in the then-clause isn't bound). This allows the programmer to handle all cases and for the compiler to type-check the program without any risk of ClassCastException from the cast at runtime.
In simple cases such as this, the main advantage is to guard against typos as @kasemir pointed out. In more complicated cases it can help the programmer to know that all cases that can arise have been covered in the code.
| AppDescriptor saveAndRestoreAppDescriptor = ApplicationService.findApplication(SaveAndRestoreApplication.NAME); | ||
| if (saveAndRestoreAppDescriptor != null && saveAndRestoreAppDescriptor instanceof SaveAndRestoreApplication) { | ||
| SaveAndRestoreApplication saveAndRestoreApplication = (SaveAndRestoreApplication) saveAndRestoreAppDescriptor; | ||
| SaveAndRestoreInstance saveAndRestoreInstance = (SaveAndRestoreInstance) saveAndRestoreApplication.getInstance(); |
There was a problem hiding this comment.
This cast can be made type-safe by changing the return type of SaveAndRestoreApplication.getInstance() to SaveAndRestoreInstance instead of AppInstance.
|
|
||
| AppDescriptor filterViewAppDescriptor = ApplicationService.findApplication(FilterViewApplication.NAME); | ||
| if (filterViewAppDescriptor != null && filterViewAppDescriptor instanceof FilterViewApplication) { | ||
| FilterViewApplication filterViewApplication = (FilterViewApplication) filterViewAppDescriptor; |
There was a problem hiding this comment.
As above, this cast can be made type-safe by changing the if-statement to: if (filterViewAppDescriptor instanceof FilterViewApplication filterViewApplication) { ...
| AppDescriptor filterViewAppDescriptor = ApplicationService.findApplication(FilterViewApplication.NAME); | ||
| if (filterViewAppDescriptor != null && filterViewAppDescriptor instanceof FilterViewApplication) { | ||
| FilterViewApplication filterViewApplication = (FilterViewApplication) filterViewAppDescriptor; | ||
| FilterViewInstance filterViewInstance = (FilterViewInstance) filterViewApplication.getInstance(); |
There was a problem hiding this comment.
As above, this can be made type-safe by changing the return type of FilterViewInstance.getInstance() to FilterViewInstance.
| import org.phoebus.applications.saveandrestore.ui.SaveAndRestoreController; | ||
| import org.phoebus.ui.javafx.ImageCache; | ||
|
|
||
| import java.util.function.Consumer; |
| import org.phoebus.applications.saveandrestore.model.Node; | ||
| import org.phoebus.applications.saveandrestore.model.NodeType; | ||
| import org.phoebus.applications.saveandrestore.ui.SaveAndRestoreBaseController; | ||
| import org.phoebus.applications.saveandrestore.ui.SaveAndRestoreController; |
| import org.phoebus.applications.saveandrestore.ui.SaveAndRestoreController; | ||
| import org.phoebus.ui.javafx.ImageCache; | ||
|
|
||
| import java.util.function.Consumer; |
| import org.phoebus.applications.saveandrestore.ui.SaveAndRestoreController; | ||
| import org.phoebus.ui.javafx.ImageCache; | ||
|
|
||
| import java.util.function.Consumer; |
| import org.phoebus.applications.saveandrestore.model.Node; | ||
| import org.phoebus.applications.saveandrestore.model.NodeType; | ||
| import org.phoebus.applications.saveandrestore.ui.SaveAndRestoreBaseController; | ||
| import org.phoebus.applications.saveandrestore.ui.SaveAndRestoreController; |
3 participants
As per user request:
When an action is opening a save-and-restore filter, the regular save-and-restore UI should not be used. Instead a dedicated app/view should launch to display only the search result associated with the filter.
The new app reuses same view as the existing search and filter view in the main save and restore app. It offers same functionality with respect to the context menu. Refactoring was necessary to achieve a result where - in the spirit of resource spending control - the UI and its controller is reused between apps.