Here is an example of nested layouts.
The "parent" layout in green has 3 content panels.
Left panel - no content - right spacer
Center panel - container for the child layout
Right panel - no content - left spacer
The "child" layout in red has 3 content panels
Left panel - container for main form
Center panel - no content - I didn't outline it in the screenshot, but it's for a small spacer between the other panels
Right panel - container for progress tracking - several queries stack on top of each other.
It took a lot of experimenting, but I was able to use this approach to get in the ballpark of the base layout. Then I added custom CSS hacks to clean it up.
Layer layouts?
-
- Posts: 619
- Joined: Wed Jun 17, 2015 11:16 pm
- Location: Omaha, Nebraska
- Contact:
Re: Layer layouts?
VocalDay Solutions - Agility - Predictability - Quality
We specialize in enabling business through the innovative use of technology.
AwareIM app with beautiful UI/UX - https://screencast-o-matic.com/watch/crfUrrVeB3t
We specialize in enabling business through the innovative use of technology.
AwareIM app with beautiful UI/UX - https://screencast-o-matic.com/watch/crfUrrVeB3t
Re: Layer layouts?
Beautiful design John, congrats.johntalbott wrote: ↑Mon Dec 07, 2020 8:24 pm Here is an example of nested layouts.
The "parent" layout in green has 3 content panels.
Left panel - no content - right spacer
Center panel - container for the child layout
Right panel - no content - left spacer
The "child" layout in red has 3 content panels
Left panel - container for main form
Center panel - no content - I didn't outline it in the screenshot, but it's for a small spacer between the other panels
Right panel - container for progress tracking - several queries stack on top of each other.
It took a lot of experimenting, but I was able to use this approach to get in the ballpark of the base layout. Then I added custom CSS hacks to clean it up.
aim_nested_layout2-75.png
Henrik (V8 Developer Ed. - Windows)
Re: Layer layouts?
Thanks for the example images of the apps with multiple layouts, they look very good.
Is it also possible to use this approach to display two forms at the same time? (in two separate panels). More in particular, I am considering this approach as an alternative to my earlier attempt to display the form of the child BO within the form of the parent BO as described here.
The forms would then not be nested, but I could place them immediately next eachother (horizontally or vertically) which is probably good enough. It would avoid the popups in any event.
I guess I would then need to find a way to ensure that the form of the parent BO is not saved before the form of the child BO is saved - or even better, to have only one save button (presumably on the Parent BO) and make the fields on the child BO autosave and, if necessary and possible, force a save of the child BO if the parent BO is saved.
Is it also possible to use this approach to display two forms at the same time? (in two separate panels). More in particular, I am considering this approach as an alternative to my earlier attempt to display the form of the child BO within the form of the parent BO as described here.
The forms would then not be nested, but I could place them immediately next eachother (horizontally or vertically) which is probably good enough. It would avoid the popups in any event.
I guess I would then need to find a way to ensure that the form of the parent BO is not saved before the form of the child BO is saved - or even better, to have only one save button (presumably on the Parent BO) and make the fields on the child BO autosave and, if necessary and possible, force a save of the child BO if the parent BO is saved.
Niels
(V9.0 build 3241 - MariaDB - Windows)
(V9.0 build 3241 - MariaDB - Windows)
Re: Layer layouts?
Yes, this approach can most likely be used. I am not entirely read up on your initial attempt but if you have 2 content panels next to each other, you can have a process that displays whatever you want either via a layout or simple display of a BO or similar. When it comes to the parent not being saved before child, not sure how to solve that but you can hide buttons for the child form in various ways and then if you can do some autosave or forced save then your solution might work. You can also just have 1 form, 2 sections/columns with different stuff in them and style it a bit so it looks like it´s 2 forms but is in only one eg. something like this: https://www.awareim.com/forum/viewtopic ... 153#p53153nhofkes wrote: ↑Wed Dec 09, 2020 9:48 am Thanks for the example images of the apps with multiple layouts, they look very good.
Is it also possible to use this approach to display two forms at the same time? (in two separate panels). More in particular, I am considering this approach as an alternative to my earlier attempt to display the form of the child BO within the form of the parent BO as described here.
The forms would then not be nested, but I could place them immediately next eachother (horizontally or vertically) which is probably good enough. It would avoid the popups in any event.
I guess I would then need to find a way to ensure that the form of the parent BO is not saved before the form of the child BO is saved - or even better, to have only one save button (presumably on the Parent BO) and make the fields on the child BO autosave and, if necessary and possible, force a save of the child BO if the parent BO is saved.
Henrik (V8 Developer Ed. - Windows)
Re: Layer layouts?
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!).
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!).
Niels
(V9.0 build 3241 - MariaDB - Windows)
(V9.0 build 3241 - MariaDB - Windows)
-
- Posts: 1463
- Joined: Tue Jan 24, 2017 5:51 am
- Location: 'Stralya
Re: Layer layouts?
Yeah don't attempt the initial suggestion it won't worknhofkes wrote: ↑Wed Dec 09, 2020 7:31 pm 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!).
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.
Re: Layer layouts?
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 wrote: ↑Wed Dec 09, 2020 7:31 pm 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!).
Henrik (V8 Developer Ed. - Windows)
Re: Layer layouts?
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.
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.
Niels
(V9.0 build 3241 - MariaDB - Windows)
(V9.0 build 3241 - MariaDB - Windows)
Re: Layer layouts?
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 wrote: ↑Thu Dec 10, 2020 1:27 pm 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.
Henrik (V8 Developer Ed. - Windows)