Layer layouts?

nhofkes

Henrik, thanks for the link to the earlier thread with the multiple columns form - that is certainly going to be useful.
But in the situation that I referred to, I actually have two forms which should look as one, not one form to look as two... The two forms are for the parent BO and the child BO, respectively - I don't think that I can integrate that in one form (as there is a one-to-many relationship, not single), except perhaps with the work-around suggested by PointsWell (@PointsWell, thanks for the suggestion!).

PointsWell

nhofkes wrote
Henrik, thanks for the link to the earlier thread with the multiple columns form - that is certainly going to be useful.
But in the situation that I referred to, I actually have two forms which should look as one, not one form to look as two... The two forms are for the parent BO and the child BO, respectively - I don't think that I can integrate that in one form (as there is a one-to-many relationship, not single), except perhaps with the work-around suggested by PointsWell (@PointsWell, thanks for the suggestion!).

Yeah don't attempt the initial suggestion it won't work

Create Parent BO with 2 forms. Initial creation and EditInChild
Create Child BO with an owned by relationship to the parent, for display as for the owned by parent attribute change from Grid to Form. Select the Parent EditInChild form
Wherever you are wanting this to launch from edit a Child instance, the child will have the parent form and then the details for the child instance.

Be aware if two people open two different child records and edit the parent section of the child then save you will get contention errors for the second one to save. This is not a great way to work in a multi user system as you are moving the onus of change from the owning record to a child. The last alternative is to create another persisted BO that contains all the attributes from parent and child. When you want to edit child generate a new super record with all the editable details from parent and child plus references back to the real records. Allow edits and then save. Add the changes back to the referenced parent and child then delete the now unneeded super record. This would avoid contention as no one would actually be editing the parent until they save the record which would then be sequential rather than attempting concurrent edit on the parent. I would generally avoid opening editing and saving multiple records in the parent child chain at the same time as you are designing in potential error and a degraded user experience.

hpl123

nhofkes wrote
Henrik, thanks for the link to the earlier thread with the multiple columns form - that is certainly going to be useful.
But in the situation that I referred to, I actually have two forms which should look as one, not one form to look as two... The two forms are for the parent BO and the child BO, respectively - I don't think that I can integrate that in one form (as there is a one-to-many relationship, not single), except perhaps with the work-around suggested by PointsWell (@[deleted], thanks for the suggestion!).

Sure and as you probably know by now, you can do things in a lot of different ways in Aware and is one of it´s strengths. PS: I do agree with Pointswell about doing this isn´t the best UX + might cause problems with data integrity so if you can find some other solution that´s definitely better. A wizard with multiple steps is definitely a better solution if that works in your app or remodeling into the 1 form instead of 2 solution instead etc..

nhofkes

Okay, I will reconsider. What about the alternative of creating/editing the child BOs in the Parent BO where the child BOs are represented by a grid with inline editing? In my view that would make sense from a UX perspective. However, when I tried this earlier I found that it didn't work as the Child BO has shortcuts to other (peer single) BOs which are multiple levels deep and apparently the selection by way of inline editing only works if the shortcut is one level deep (as I read somewhere on this forum).

In principle I could create a temporary separate object with copies of the relevant data that would be used just for the purpose and then copy that back to the original BOs, as described by PointsWell, but I am hesitant because of the additional complexity and risk that something may get screwed up when copying data back and forth between BOs.

hpl123

nhofkes wrote
Okay, I will reconsider. What about the alternative of creating/editing the child BOs in the Parent BO where the child BOs are represented by a grid with inline editing? In my view that would make sense from a UX perspective. However, when I tried this earlier I found that it didn't work as the Child BO has shortcuts to other (peer single) BOs which are multiple levels deep and apparently the selection by way of inline editing only works if the shortcut is one level deep (as I read somewhere on this forum).

In principle I could create a temporary separate object with copies of the relevant data that would be used just for the purpose and then copy that back to the original BOs, as described by PointsWell, but I am hesitant because of the additional complexity and risk that something may get screwed up when copying data back and forth between BOs.

I am not fully read up on your requirements but sounds like it should possible and a lot better from a UX perspective and doing things like the temp objects is common place at least for me. Aware is powerful in that you can do things in so many different ways and initially when I started with Aware, I always thought "I HAVE TO have it / it HAVE TO work like this" but these days I instead think of the end objective/process and use various approaches like the temp objects etc. to achieve it. The overhead is in most cases non existent and you can have nightly cleanup processes that clean up etc. and works.

nhofkes

I noticed that when using the technique of layering layouts (using DISPLAY LAYOUT), you can't use the AwareApp.getPanelId function (as described here and here.

The aware JS code has a comment to this function: "Not to be used when a panel belongs to a perspective displayed using DISPLAY LAYOUT - see the next function for this". The next function is AwareApp.getLayoutPanelId(), which was introduced in version 8.0 build 2358 (reference: https://www.awareim.com/dokuwiki/doku.php/changelog/0000/8.n/8.0/2358) but is not documented in the AIM documentation and which does not seem to be used anywhere by Aware. When trying to use this function in my render script, I got a reference error. This is because the function has a line

var t = getPanelId(frameType, tabName, panelName);

This should have been:

var t = this.getPanelId(frameType, tabName, panelName);

I have now worked around this by using AwareApp.getPanelId() and then calling the following function with the resulting id:

function getLayoutPanelId(panelId) {
  let elem = $("#aware_app").find("[id='" + panelId + "']");
  if (elem.length == 1) {
    return panelId;
  }
  elem = $("#aware_app").find("[id*='" + panelId + "']");
  if (elem.length > 0) {
    return elem.attr("id");
  }
  return null;
}

aware_support

Thanks for finding a glitch in getLayoutPanelId - we will fix it

« Previous Page