in my UI screens, i sometimes have the requirement to instead of going directly from “browse” to “edit”, i need a screen in between. In other frameworks this is normally called something like “show” or “detail”. Often this is useful when the user should have the opportunity to get an overview of an entity before editing it.
One reason might be because the entity is just too big (with many 1:N & M:N relationships) to get a basic idea of it. So it should support the overview of the entity.
Another is, that there are a lot of actions that can be done on a particular entity. But these actions would take to much place in the browse screen. Also there is not a real need to directly do this things from the entities list. (Take this example of ms dynamics nav - contact detail screen for multiple actions on an entity).
Unfortunately CUBA doesn’t really support me with this UI pattern. Here are some examples, where i have problems when trying to do this manually:
Actions in the top level of the “show”-editor can’t be used together with “constraintCode” and “constraintOperationType”
programatic custom actions can’t really use BaseAction as a base class, because it implements “Action.HasTarget” which mean that it should be used in conjunction with a ListComponents (which is normally not present at the show editor).
“related entities” can currently not be used in a show screen (i think i already created an issue for that which got resolved in 6.5 - i think)
if i use the normal “test$Customer.edit” screen to be the show screen (because i want to stay as close to the CUBA UI pattern as close as possible) and add another button in the screen that opens the actual editor, the refresh on the table does not work anymore, because it has two hops
in the show screen there is not really a component (especially in the field group) that only displays a value in a really read only fashion (just enabled=false works pretty good though)
To overcome some of the above mentioned issues is to just create a invisible table in the “show” page where you load only this item in the datasource and select it programatically.
I attached a simplistic example of the screen flow. It does not show all the above mentioned problems and fixes, but just to get an idea.
I have not a real idea how this should look like, perhaps we can have a chat about it.
I would like to propose an alternative solution to your requirements. What about using the same screen for viewing and editing, just switching controls dynamically? When the screen is opened, it’s in read-only state, then user the presses Edit you can enable fields, switch tabs or frames, etc. For example:
public class CustomerEdit extends AbstractEditor<Customer> {
@Inject
private FieldGroup fieldGroup;
private Action commitAction;
@Override
public void init(Map<String, Object> params) {
commitAction = getActionNN(Editor.WINDOW_COMMIT);
commitAction.setEnabled(false);
}
public void edit() {
fieldGroup.setEditable(true);
commitAction.setEnabled(true);
}
}
Attached the modified project.
I understand that this approach has its drawbacks like more complicated logic in controllers, but unfortunately this browser > editor screen flow is quite hard to overcome in the current platform implementation. We’ll try to make it more flexible in the future.
thanks for looking at it. That might be a good solution. I have thought about that also, but as we try to keep our classes (especially the UI controller) as small as possible, this is not the first thing that i would think of. But it will definitively remove a lot of the problems from above.
Combining that with using frames for the different parts of the screen will enable us to separate the two but let it look like one screen from the frameworks point of view.
> this browser > editor screen flow is quite hard to overcome in the current platform implementation
yeah, i saw that from time to time. If you don’t stick to the “my$Customer.edit” screen, it will disable a lot of platform features like screen history, FTS search result list etc.
More flexibility is mostly better, but as the strict usage of the editor pattern allowed the FW to give some extra integration (like the ones from above) that would otherwise be hardly possible (if it does not take any assumption on the screen pattern).
As i wrote the question i wasn’t even sure if this is a good idea at all, because it will to some degree destroy the good integration and exchange it with looser coupling. But with the provided solution, at least for me i think it is a good trade off, that i’m fairly happy with (until the next problems arise, that i’m currently not aware of )
Good to hear that you agree with this workaround. In fact, we use dynamic reconfiguration of screens quite often in complex cases like Booking screen in our Sherlock taxi solution - such screens can be very dynamic by nature, adapting to the user’s input.
As for the screen naming conventions, I think they are not directly related to the problem of the rigid browser > editor flow. We could keep these conventions and at the same time make relations between screens more flexible. But it will probably require a major rework of datasources, standard actions and screens.
Following this idea, could there also be a more generic routine to enable/disable all edit controls? This way the same routine could be used in multiple editors without referencing all edit controls individually.
You can just iterate over getComponents() collection of a container or the whole Window and call setEnabled(false) or, if the component implements Editable, setEditable(false).
)