Dynamic use of PRIM_VIEW

This Q&A forum allows users to post and respond to "How Do I Do ....." questions. Please do not use to report (suspected) errors - you must use your regional help desk for this. The information contained in this forum has not been validated by LANSA and, as such, LANSA cannot guarantee the accuracy of the information.
Post Reply
dominique
Posts: 31
Joined: Mon May 29, 2017 4:16 pm
Location: St. Gallen, Switzerland

Dynamic use of PRIM_VIEW

Post by dominique » Thu Nov 29, 2018 7:57 pm

We use Views (#PRIM_VIEW) to display the main parts of the application. All instances of the views and reusable parts in the view were created during the startprocess of the webpage. For small pages I think that’s ok but not for larger applications because It increases the initial waiting time. Another disadvantage is that embedded reusable parts crashes if they need data in the createinstance which you have only after login.

Questions:
a) Does it makes sense to create the views dynamically or should this be avoided?
b) Is there another way to avoid the create instances on start?

What are your suggestions? What are your experiences about this question?

See attached example(quickexport)
QuickExportSample.zip
(17.62 KiB) Downloaded 52 times

jyoung
Posts: 642
Joined: Thu Jan 21, 2016 6:43 am
Location: Oklahoma City, OK USA

Re: Dynamic use of PRIM_VIEW

Post by jyoung » Fri Nov 30, 2018 1:22 am

I think its fine to create components dynamically. We don't use Views in the app as it was built pre SP2.
We dynamically create the views (Panels) and store them in a PRIM_KCOL for reference later.

I would argue that you don't do any data loading in CreateInstance. You can do data initialization, like setting default value etc. I would use the Initialize event or define your own method that gets called before you show your view.

The docs mention that using the "Initialize" event to load data will cause the screen to jump and to use the CreateInstance to do the loading.
https://docs.lansa.com/14/en/lansa016/p ... ialize.htm

I ran into the same issue that you did, so I don't necessarily agree with this.

We do something like this in one of our apps

Code: Select all

mthroutine name(ActivatePanel) access(*PUBLIC)
define_map for(*INPUT) class(#STD_STRNG) name(#panelId)
define_map for(*INPUT) class(#PRIM_BOLN) name(#forward)

#panelId := #panelId.UpperCase

#SYS_APPLN.TraceMessageText( ("ActivatingPanel PanelId: &1").Substitute( #panelId ) )

* deactivate the current active panel
if (#ActivePanelId.UpperCase <> #panelId)
if (#Panels<#ActivePanelId> *IsNot *NULL)

* deactivate the panel
#Panels<#ActivePanelId>.Deactivate

* let others know we deactivated it
#SYS_APPLN.TraceMessageText( ("Signaling PanelDeactivated panelId: &1").Substitute( #ActivePanelId ) )
signal event(PanelDeactivated) panel(#Panels<#ActivePanelId>)
endif
endif

* if the panel does not exist yet, create it
if (#Panels<#panelId> *Is *NULL)
#SYS_APPLN.TraceMessageText( ("Panel is null, creating new panel: &1").Substitute( #panelId ) )
set_ref com(#Panels<#panelId>) to(*CREATE_FROM #panelId)
endif

* activate the panel
#Panels<#panelId>.Activate
#Panels<#panelId>.SetDesign( #ActiveDesign )
#ActivePanelId := #panelId

* only add history to "forward" activations
if (#forward)
#COM_OWNER.AddToHistory( "PANEL" #panelId )
endif

* signal that we have activated the panel
signal event(PanelActivated) panel(#Panels<#panelId>) forward(#forward)
endroutine
The "Activate" method is what does the loading of the data etc. One thing to note (this may have changed with recent EPCs) is that the Design does not get triggered automatically when you create your components like this. So you may need to set the proper design after you have created the component.

Hope this helps.
Joe

dannyoorburg
Posts: 148
Joined: Mon Jan 04, 2016 9:50 am
Location: Australia

Re: Dynamic use of PRIM_VIEW

Post by dannyoorburg » Fri Nov 30, 2018 12:56 pm

Hi Dominique,

It all depends... :)

Personally I would prefer to keep the Views static, but that's really only so they show up at Design Time and the code stays as readable as possible.

If they don't do any work during CreateInstance, then all that happens is that all the View Instances will get constructed, including all Static Components they contain, and of course that all the required JavaScript will get downloaded from the Server at Startup. (NOTE: this happens in several concurrent server calls and IS the fastest way to get all JavaScript onto the client).

Only when I would start experiencing a slow startup with this model (and I haven't yet) would I consider dynamic creation of my views.


And I think I would simply create Static Define_Com's for my MenuItems, and Dynamic Define_Com's for my Views, and then implement the click event on the menu-item as follows.

Code: Select all

Evtroutine Handling(#MenuItemMyView.Click)

If (#MyView *Is *NULL)

#MyView <= *New #MyView

Endif

#MyView.Show

Endroutine
Hope that helps...

Cheers,
Danny

Post Reply