Layer layouts?

[hpl123]

Hi all,
I wonder if it´s possible to "layer" layouts i.e use 1 perspective/layout with a content panel which has an command to display another layout? (possibly multiple i.e multiple content panels each displaying some layout). Anyone done this and any performance issues or concerns?

[PointsWell]

Hi all,
I wonder if it´s possible to "layer" layouts i.e use 1 perspective/layout with a content panel which has an command to display another layout? (possibly multiple i.e multiple content panels each displaying some layout). Anyone done this and any performance issues or concerns?

I missed this months ago.

Yes, I use this repeatedly.

VP
|-Content Panel to display form
|-Content Panel displays layout

The form in the first content panel contains a form with buttons and these call DISPLAY LAYOUT and allows me to use different layouts in second content panel, each of these child layouts may have different layouts to show different information based on the initial BO at the very top level.

Ideally I would like the ability to be able to link these layouts back to each other directly to maintain the BO in context rather than have to reference back to a LIRU but I haven't managed to convince support of this idea.

[hpl123]

Hi all,
I wonder if it´s possible to "layer" layouts i.e use 1 perspective/layout with a content panel which has an command to display another layout? (possibly multiple i.e multiple content panels each displaying some layout). Anyone done this and any performance issues or concerns?

I missed this months ago.

Yes, I use this repeatedly.

VP
|-Content Panel to display form
|-Content Panel displays layout

The form in the first content panel contains a form with buttons and these call DISPLAY LAYOUT and allows me to use different layouts in second content panel, each of these child layouts may have different layouts to show different information based on the initial BO at the very top level.

Ideally I would like the ability to be able to link these layouts back to each other directly to maintain the BO in context rather than have to reference back to a LIRU but I haven't managed to convince support of this idea.

Awesome, thanks. I use layouts as "pages" of my apps and is a very powerful way of working with Aware and knowing this, I can also use layouts as "elements". I wonder if the only thing a display layout action does is "inject" the HTML from the defined into the target container? (i.e ONLY the HTML defined in the layout so NOTHING else creating a lag like extra menu divs from the layouts perspective etc. etc. etc.)

[hpl123]

Hi all,
I wonder if it´s possible to "layer" layouts i.e use 1 perspective/layout with a content panel which has an command to display another layout? (possibly multiple i.e multiple content panels each displaying some layout). Anyone done this and any performance issues or concerns?

I missed this months ago.

Yes, I use this repeatedly.

VP
|-Content Panel to display form
|-Content Panel displays layout

The form in the first content panel contains a form with buttons and these call DISPLAY LAYOUT and allows me to use different layouts in second content panel, each of these child layouts may have different layouts to show different information based on the initial BO at the very top level.

Ideally I would like the ability to be able to link these layouts back to each other directly to maintain the BO in context rather than have to reference back to a LIRU but I haven't managed to convince support of this idea.

Smart way of utilizing layouts by the way.

[Jaymer]

I’d love to see a practical example of this “pages” vs “elements” idea (Ie. Video). I normally do VPs with multiple panels but not with a button to do a display layout.
So normally the same panel always displays the same kind of information.
I think Bruce does some more complicated ones so he may be using this strategy, but I haven’t really needed it to be this in-depth.
A visual example might let me see the potential of this compared to a simpler way of doing it.

[hpl123]

I’d love to see a practical example of this “pages” vs “elements” idea (Ie. Video). I normally do VPs with multiple panels but not with a button to do a display layout.
So normally the same panel always displays the same kind of information.
I think Bruce does some more complicated ones so he may be using this strategy, but I haven’t really needed it to be this in-depth.
A visual example might let me see the potential of this compared to a simpler way of doing it.

Well, I´m no video guy and don´t have the tools to create a video but here is how I use the "pages" concept. If you look at the image below, this is 1 page of one of my apps and as you can see everything on the page is a content panel (everything marked with red is a content panel) i.e I don´t use the top,left,right,footer etc. frames, I just use the main frame for everything and then inside that frame I use the responsive nested configuration and just build my entire page. All pages in the Fokalpoint app which I am showing here is a layout and I have 38 pages in the app covering all of the different modules etc. of the app together with a lot of popup functionality for most things like forms etc. i.e the layout is the main page and then I use popups for everything else. This approach works very well but of course has its downsides as well and this is one of the ways I develop apps. I also do the "traditional" way with left frame for menu, top frame for top bar, use tabs etc. etc. for other apps and is one of the great things about Aware, we have so many ways of doing things. The DISPLAY LAYOUT functionality is awesome but I have only used it previously to show 1 page that has a lot of content panels in it and not say 1 page/layout which has various commands in the content panels which in turn show some other layout and I was unsure if that was even possible. I think there are many other use cases for the DISPLAY LAYOUT functionality so good to hear and see what others are doing.

fpjournal.png (141.5 KiB) Viewed 18184 times

One of the big questions I have is related to what the DISPLAY LAYOUT really does (same question stated above): I wonder if the only thing a display layout action does is "inject" the HTML from the defined into the target container? (i.e ONLY the HTML defined in the layout so NOTHING else creating a lag like extra menu divs from the layouts perspective etc. etc. etc.). If that is the case, DISPLAY LAYOUT could in theory be used for almost anything and even for small minor things like populate some HTML like in Vlads latest More/Less example in the CRM sample app. Anyone knows?

[BLOMASKY]

I think Bruce does some more complicated ones so he may be using this strategy, but I haven’t really needed it to be this in-depth.

Naaa, Bruce is not sophisticated enough to do this. I do have many VPs where there is an "almost" empty HTML cell with the auto-refresh set to some process which will conditionally display a form or query in the cell, but I have never found a use-case to have it display a layout. This does give me some ideas maybe....

Bruce

[PointsWell]

I'd be happy to put together some images later.

Before I do that I will explain the use case that is behind my design.

I have different contact types
Companies, which have different types
People, who can be individuals, employees, suppliers

I have a number of subordinate BOs to Contact, addresses, contact methods (tel no, email addresses, web links), Companies might have direct employees, Companies might have subsidiaries and parents and these parents/subsidiaries have lists of employees.

Initially I had a simple layout of two horizontal content panels and showed a form on top and a query in the lower panel. This was inflexible as each subordinate BO had different display requirements, e.g. Addresses should probably also show with contact methods, so the lower content panel would have to show at a minimum two further content panels, while Companies would show a company parent hierarchy, employees for the Company in context and then contact details for the employee that is in context. That requires 3 content panels in the subordinate panel.

These requirements can't be met with the simple two horizontal panels.

As a side note, the details in the subordinate panel need to remain relevant so if you select a Company, then select the company hierarchy details then change the selected contact to a person then you need to not show a company hierarchy chain but revert to Contact Cards (Addresses and Contact Methods)

To the question of menus being called, this is a bit of a red herring as I only have menus associated with the Home VP. None of the other VPs ever get used as VP they are just a means of holding all of the related Layouts together. The Home VP acts as a frame into which the layouts are inserted like a slide.

Home VP
| menu
|- Show Contacts
|- Show Contracts
| one Content Panel

ContactVP
| ContactHome - (Layout with two horizontal content panels ContactForm ContactSubordinate)
| ContactCards (Layout with two vertical content panels, Addresses and Contact Methods)
| ContactCompanyHierarchy (Layout with three vertical content panels CoHierarchy, InContextEmployees, InContextContactMethods)

Selecting Contact from the HomeVP menu injects the ContactHome Layout from ContactsVP into the Home VP Content Panel
The ContactParent layout has two parts FormPanel and DetailsPanel
The FormPanel displays the form for the contact, the form has buttons at the bottom. The buttons have processes to set LIRU.LastContactPanel to a value and then injects the relevant subordinate Contacts layout into the ContactSubordinate content panel)
The last used Detailspanel is stored as a string in LIRU and the Details panel initial value is driven by a process EXEC STRING 'DISPLAY LAYOUT '+LIRU.LastContactPanelViewed (the actual process is more complicated and includes a chain to make sure if the Contact is a person it selects an alternative default layout if the initial layout was a company related one). This means that the user will return to the last Contacts details view when they last used the screen, so if they look at ContactCards then close the screen and then return to it, then it shows ContactCards when the relaunch it.

This requires a series of different refreshes at different levels.
The ContactDetails panel has a refresh to check if Contact type (Person v Company) changes and that the ContactDetails panel is relevant to the Contact Type

The individual detail panels require refreshes on the sub panels, for example addresses for a company are in a different format to addresses for an employee which are different for individual not company related Contacts.

I've since developed the concept further to instead of placing the Contacts into a HomeVP content panel I now launch it as a different tab within the HomeVP, this allows the user to switch between Contacts and Contracts without losing their place.

To the question of what DISPLAY LAYOUT is doing and is it consuming menus from the source VP, I can't answer, but it doesn't make any difference for my purposes as there are no menus and headers on the ContactVP as everything is maintained on the top layer HomeVP, the ContactVP is only a binder to hold all of the Contact related layouts.

There are a number of steps that I am having to do that could be handled more elegantly with some modifications in AIM, for example the subordinate content panels could inherit their BO context from the parent layout, or from another another query eg CompanyHierarchy selected Company affects the InContextEmployees which affects the InContextContactMethods in the layout showing
Companies-> Employees-> ContactMethods

At the moment the filters are applied from left to right, so you can change the Company selected and drive the output to Employees and have the first record select and then drive the ContactMethods filter. This is fine until you
Select a company with employees and the first employee has some contact method but if you then
Select a second company with no employees there is no record to in the employees section with which to force the output to the contact methods and overwrite the previously selected contact method

I am currently achieving this by refreshing all the queries to the right when it's leftmost neighbour is updated it feels very convoluted and I am diverging from the original question now

[hpl123]

Discussing the "pages" approach with Jaymer and thought I´d share it here instead as it might help others:

Jaymer: Maybe I have developed for so long in a particular style, but I’m unable to see how my app could be improved by this new methodology. Said another way - I don’t see what’s wrong with the way I’m doing it.

Henrik: Well, not sure the one way is necessarily better than the other. I started using this approach mainly due to difficulties getting an external admin template integrated into Aware. The problem for example was when having the admin template menu in the left bar, the menu didn´t work properly e.g the hoover expand menu didn´t work and many other small things like that. Except for this, Aware has some quirks with it´s different frames and I just found it difficult to work with when trying to do more advanced stuff than the plain ol' Aware default (sample application copy) app.

The beauty of doing it with "pages" is you get easier control over all things on the page. Not sure how familiar you are with HTML/CSS etc.? If you do it like I do it, you get easier control and access to everything on your page and I think of it like a "mini DOM" not affected by everything else Aware does. If you look at the DOM of a regular Aware app it´s a mess (doesn´t mean bad coding from Awaresoft but rather so much stuff in the DOM) and a lot of different things here and there and with a layout, you get a "mini-DOM" which basically is the layout and then everything inside that layout follows the bootstrap grid/column system and you can easily build, style, script etc. the "mini-DOM" and it´s elements.

There are many downsides to this approach as well as I wrote above and I see it as app specific i.e the traditional way is good for some apps and the layout pages way for others. Going the layout pages way is A LOT of extra work to get everything working so if you have something working the traditional way, I see no reason to change it unless you want to do something like integrate an external admin template and that is what I usually do. The Fokalpoint app is for example based on the Smartadmin template: https://smartadmin-angular-5.firebaseap ... /analytics and when I integrate an external admin template, I redesign the entire Aware app with a custom theme to match (or improve) the admin template styling and then integrate all parts of the admin template so I for example get access to everything in the admin template e.g menu systems, breadcrumbs, notifications, all "widgets" in the admin template e.g charts, "cards" etc. etc. etc.. What I usually do (and I have done this myself a couple of times and also for multiple other developers) is select an admin template e.g from Wrapbootstrap: https://wrapbootstrap.com/category/temp ... -templates and then I integrate the entire template and basically any admin template can be integrated and then you get an awesome UI and UX (I mean, the admin template designers are often pros at UI/UX design and integrating and basing an app design on their admin template/work is a shortcut to get good UI/UX without needing to reinvent the wheel. I do however study UI/UX as well so I often do small changes based on my experience and what I know about UI/UX) + you still have MOST of the RAD capabilities of Aware. Best of both worlds. NB: If you want to integrate an admin template, you don´t have to do it like I did it for the Fokalpoint app with everything in the MAIN frame i.e an layout is a full page. You can also still do this while using the other frames e.g TOP, LEFT etc. and I have done that before as well. It depends on the admin template and how that is coded/works and how it can be integrated in Aware and as it is an integration of 2 rather large and complex "things", there are always some difficulties to solve and workarounds you have to do.

[hpl123]

I'd be happy to put together some images later.

Before I do that I will explain the use case that is behind my design.

I have different contact types
Companies, which have different types
People, who can be individuals, employees, suppliers

I have a number of subordinate BOs to Contact, addresses, contact methods (tel no, email addresses, web links), Companies might have direct employees, Companies might have subsidiaries and parents and these parents/subsidiaries have lists of employees.

Initially I had a simple layout of two horizontal content panels and showed a form on top and a query in the lower panel. This was inflexible as each subordinate BO had different display requirements, e.g. Addresses should probably also show with contact methods, so the lower content panel would have to show at a minimum two further content panels, while Companies would show a company parent hierarchy, employees for the Company in context and then contact details for the employee that is in context. That requires 3 content panels in the subordinate panel.

These requirements can't be met with the simple two horizontal panels.

As a side note, the details in the subordinate panel need to remain relevant so if you select a Company, then select the company hierarchy details then change the selected contact to a person then you need to not show a company hierarchy chain but revert to Contact Cards (Addresses and Contact Methods)

To the question of menus being called, this is a bit of a red herring as I only have menus associated with the Home VP. None of the other VPs ever get used as VP they are just a means of holding all of the related Layouts together. The Home VP acts as a frame into which the layouts are inserted like a slide.

Home VP
| menu
|- Show Contacts
|- Show Contracts
| one Content Panel

ContactVP
| ContactHome - (Layout with two horizontal content panels ContactForm ContactSubordinate)
| ContactCards (Layout with two vertical content panels, Addresses and Contact Methods)
| ContactCompanyHierarchy (Layout with three vertical content panels CoHierarchy, InContextEmployees, InContextContactMethods)

Selecting Contact from the HomeVP menu injects the ContactHome Layout from ContactsVP into the Home VP Content Panel
The ContactParent layout has two parts FormPanel and DetailsPanel
The FormPanel displays the form for the contact, the form has buttons at the bottom. The buttons have processes to set LIRU.LastContactPanel to a value and then injects the relevant subordinate Contacts layout into the ContactSubordinate content panel)
The last used Detailspanel is stored as a string in LIRU and the Details panel initial value is driven by a process EXEC STRING 'DISPLAY LAYOUT '+LIRU.LastContactPanelViewed (the actual process is more complicated and includes a chain to make sure if the Contact is a person it selects an alternative default layout if the initial layout was a company related one). This means that the user will return to the last Contacts details view when they last used the screen, so if they look at ContactCards then close the screen and then return to it, then it shows ContactCards when the relaunch it.

This requires a series of different refreshes at different levels.
The ContactDetails panel has a refresh to check if Contact type (Person v Company) changes and that the ContactDetails panel is relevant to the Contact Type

The individual detail panels require refreshes on the sub panels, for example addresses for a company are in a different format to addresses for an employee which are different for individual not company related Contacts.

I've since developed the concept further to instead of placing the Contacts into a HomeVP content panel I now launch it as a different tab within the HomeVP, this allows the user to switch between Contacts and Contracts without losing their place.

To the question of what DISPLAY LAYOUT is doing and is it consuming menus from the source VP, I can't answer, but it doesn't make any difference for my purposes as there are no menus and headers on the ContactVP as everything is maintained on the top layer HomeVP, the ContactVP is only a binder to hold all of the Contact related layouts.

There are a number of steps that I am having to do that could be handled more elegantly with some modifications in AIM, for example the subordinate content panels could inherit their BO context from the parent layout, or from another another query eg CompanyHierarchy selected Company affects the InContextEmployees which affects the InContextContactMethods in the layout showing
Companies-> Employees-> ContactMethods

At the moment the filters are applied from left to right, so you can change the Company selected and drive the output to Employees and have the first record select and then drive the ContactMethods filter. This is fine until you
Select a company with employees and the first employee has some contact method but if you then
Select a second company with no employees there is no record to in the employees section with which to force the output to the contact methods and overwrite the previously selected contact method

I am currently achieving this by refreshing all the queries to the right when it's leftmost neighbour is updated it feels very convoluted and I am diverging from the original question now

Thanks for the detailed description and sounds fairly similar to what I do with pages e.g "HOME VP" with layouts (pages) slide in (except I have everything on the page and don´t use the other frames). You have more advanced stuff going on on each layout though and is interesting. I´m gonna play some with these concepts. I would also like better context etc. functionality as I also sometimes have the context not transfer over between different things (can´t remember details of exactly when/where) and I use LIRU a lot as an additional context tool and I just upgraded to 8.5 so now I´m gonna look at the new SESSION object instead for things like that.

Regarding the DISPLAY LAYOUT injection and what it does, I THINK this is what it does i.e just inject whatever is in the layout into the target container.

It would be nice to see some images of your app.

[PointsWell]

It would be nice to see some images of your app.

1 Panel Layout

Screen Shot 1 Panel layout.png (91.94 KiB) Viewed 18069 times

So there is a Parent layout for Contacts
The parent panel has three content panels
The yellow one contains a query to select the Contact, it then drives its output to the green content panel and displays a form.
The blue content panel can contain many different subsidiary layouts.

The form in the green content panel drives its output to the blue panel in the form of LIRU.LastView = COxxx DISPLAY LAYOUT COxxx FROM_VP CONTACTS

In the image above it is just showing a layout that contains a query.

2 Panel Layout

Screen Shot 2 Panel Layout.png (102.78 KiB) Viewed 18069 times

This version is showing Contact cards for the Contact in focus. It needs two columns.

The final version is showing a three column layout for company hierarchies.

3 Panel Layout

Screen Shot 3 Panel Layout.png (91.21 KiB) Viewed 18069 times

When I select a new contact in the yellow grid it triggers a refresh on the blue panel and checks if it is a person or a company and that the LIRU.LastView is relevant to the Contact in focus.

This approach works for me because it reduces redundancy, I could create a static layout for every page I want to display, but it would be an awful lot of pages to maintain. The other grossness that it produces is page reloads, white screen flashes. In this layout the blue content panel only refreshes if there is an inconsistent layout for the contact being viewed. If the layout is consistent with the Contact in focus then the queries within the layout being displayed in the blue content panel just refresh. I could just use a single form with tabbed panels for all of the sub screens, but that would be much less flexible in terms of what I can show in that panel and also it would default to the initial tab so the user was looking at ContRacts then selected a different Contact they would have to click the ContRact tab again.

Other tools that I have used allow for you to link your data to other panels. So blue panel listens to green panel for changes and green panel listens to yellow. This is a more dynamic arrangement and embeds the BO in context to a screen element rather than a database attribute. The reason that I don't like the LIRU or session variable is because as an example

CONTACT has
1-m Addresses
1-m Contracts
m-1 Employer has 1-m Employees has 1-m Addresses etc etc
(it is actually way more complex a hierarchy)

If I stick Contact into LIRU then turn on SQL tracking in the logger it loads a metric sht ton of data into context.
If you delete the object from the LIRU and check the SQL tracking it still runs the SQL, it just runs it WHERE ID=NULL

I instead only put ID values into the LIRU - which is a pain as it then requires that I need to go find that Contact each time.

[hpl123]

It would be nice to see some images of your app.

Screen Shot 1 Panel layout.png

So there is a Parent layout for Contacts
The parent panel has three content panels
The yellow one contains a query to select the Contact, it then drives its output to the green content panel and displays a form.
The blue content panel can contain many different subsidiary layouts.

The form in the green content panel drives its output to the blue panel in the form of LIRU.LastView = COxxx DISPLAY LAYOUT COxxx FROM_VP CONTACTS

In the image above it is just showing a layout that contains a query.

Screen Shot 2 Panel Layout.png

This version is showing Contact cards for the Contact in focus. It needs two columns.

The final version is showing a three column layout for company hierarchies.

Screen Shot 3 Panel Layout.png

When I select a new contact in the yellow grid it triggers a refresh on the blue panel and checks if it is a person or a company and that the LIRU.LastView is relevant to the Contact in focus.

This approach works for me because it reduces redundancy, I could create a static layout for every page I want to display, but it would be an awful lot of pages to maintain. The other grossness that it produces is page reloads, white screen flashes. In this layout the blue content panel only refreshes if there is an inconsistent layout for the contact being viewed. If the layout is consistent with the Contact in focus then the queries within the layout being displayed in the blue content panel just refresh. I could just use a single form with tabbed panels for all of the sub screens, but that would be much less flexible in terms of what I can show in that panel and also it would default to the initial tab so the user was looking at ContRacts then selected a different Contact they would have to click the ContRact tab again.

Other tools that I have used allow for you to link your data to other panels. So blue panel listens to green panel for changes and green panel listens to yellow. This is a more dynamic arrangement and embeds the BO in context to a screen element rather than a database attribute. The reason that I don't like the LIRU or session variable is because as an example

CONTACT has
1-m Addresses
1-m Contracts
m-1 Employer has 1-m Employees has 1-m Addresses etc etc
(it is actually way more complex a hierarchy)

If I stick Contact into LIRU then turn on SQL tracking in the logger it loads a metric sht ton of data into context.
If you delete the object from the LIRU and check the SQL tracking it still runs the SQL, it just runs it WHERE ID=NULL

I instead only put ID values into the LIRU - which is a pain as it then requires that I need to go find that Contact each time.

Very cool indeed and nicelooking app design. I see your point with the difficulty in optimizing what Aware does in the background and will be good to know when playing around with these things. I haven´t looked at the SQL logs for my way of doing things (just upgraded from 8.2 to 8.5 so haven´t had easy access to this before) and dread doing it, not sure what I will find. I use LIRU and SystemSettings and 1 special SystemSettingsModule BO for each module in my app and it´s over 10 of those and each of these are then linked to SystemSettings so a lot of stuff could be happening in the background.

[Jaymer]

it´s over 10 of those and each of these are then linked to SystemSettings so a lot of stuff could be happening

...cringes...

Thats an understatement!
According to that analysis thread I wrote (and Sean said this recently too), when any BO record is loaded, AIM ALSO reads every single-reference connected record - automatically, cause it doesn't know if you're going to need a field in a future rule [in that process] or not.
So if you're in Module A, its reading all the peer links for modules A-J.
BUT
Those "additional" reads are ONLY if you have shortcuts defined to modules A-J.
A link from SystemSettings to a BO with NO shortcuts DOES NOT appear to do these extra reads (I JUST DID THIS testing)(NOTE: my brief test was done by editing the SystemSetting BO (in a form) and examining the MS SQL Profiler. I did not take more time to see how processes were acting.)

[hpl123]

it´s over 10 of those and each of these are then linked to SystemSettings so a lot of stuff could be happening

...cringes...

Thats an understatement!
According to that analysis thread I wrote (and Sean said this recently too), when any BO record is loaded, AIM ALSO reads every single-reference connected record - automatically, cause it doesn't know if you're going to need a field in a future rule [in that process] or not.
So if you're in Module A, its reading all the peer links for modules A-J.
BUT
Those "additional" reads are ONLY if you have shortcuts defined to modules A-J.
A link from SystemSettings to a BO with NO shortcuts DOES NOT appear to do these extra reads (I JUST DID THIS testing)(NOTE: my brief test was done by editing the SystemSetting BO (in a form) and examining the MS SQL Profiler. I did not take more time to see how processes were acting.)

Scary stuff and I generally don´t have shortcuts in these but good to know and I will dig into this some. How can one analyse and see of this happens on MySQL, is there a profiler for MySQL and/or is this achievable via the new SQL logging parts of the Aware logs?

The main reason I did this was, each module in this particular app is very complex and has many moving parts etc. and at first I had it all in SystemSettings but it just grew and grew so I opted for this solution instead thinking it be better performance wise. I don´t really have any noticable performance issues BUT of course, id the server load and transactions etc. are larger and happens more often, it affects the overall capacity of the server.

Jaymer, which analysis thread are you talking about, do you have a link? Thanks

[Jaymer]

can't help you w/MySQL

Thread here