Running in VLF and VL for Web

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
atostaine
Posts: 408
Joined: Wed Jan 20, 2016 7:38 am

Running in VLF and VL for Web

Post by atostaine » Fri Sep 16, 2016 4:34 am

I can write RP's that target both windows and VL for Web. VL For Web has to use server module. How can I wrap my server module so that based on the execution platform the app calls a server module or a windows RP (or server function)?

I recall talking about this before and I think Stewart mentioned it would be possible by wrapping the server module and other modules with the same ancestor? I haven't figured out how to do it yet. Anyone have a skeleton example I can use?

We have an existing VLF-WIN application, we would like to code a few things that can run on web or in VLF-Win.

Thanks
Art Tostaine

LANSAGuru
Posts: 67
Joined: Thu Mar 24, 2016 5:31 am

Re: Running in VLF and VL for Web

Post by LANSAGuru » Fri Sep 16, 2016 8:51 am

This has two parts.
On the server side you would have

Function A
Server_Module B
RP C

You would call either of Function A or B depending on platform and then A and B would both call C and then pass back a response. The reason for this is so all of the business logic is in one place, and only one place. A and B in this scenario are simply thin exchange layers.

====================

Client Side
Filters and Command Handlers both have different ancestors. So using the same UI (shared RP say) would be interesting as only a subset of controls are usable on both platforms. It could be done however, but in practice I think you would need to build some if not most of the UI twice. There have been some recent discussions on this topic.

====================

Now for the data side, this can be done.
You need

RP A - this is called by BOTH the Form side and the VL Web side. It is compiled for both platforms.
RP B - this is called only by the Form side and contains call_server_function. It is compiled only for Windows.
RP C - this is called only by the Web side and contains server module invocation. It is compiled only for Web.
RP AA - this is the ancestor for all three parts and defines the interface. It is compiled for both platforms.

AA (Ancestor) - defines the data being passed
---------------------------------------
Function Options(*DIRECT)
Begin_Com Role(*EXTENDS #PRIM_OBJT)
Mthroutine Name(callit)
Define_Map For(*input) Class(#std_text) Name(#data) Mandatory('')
Endroutine
End_Com

A (Router)
---------------------------------------
Function Options(*DIRECT)
Begin_Com Role(*EXTENDS #AA)
Define_Com Class(#AA) Name(#myHandler) Reference(*DYNAMIC)
Mthroutine Name(callit) Options(*REDEFINE)
If (#CPUTYPE = WEB)
Set_Ref Com(#myHandler) To(*CREATE_FROM 'C') Com_Error(*SET_NULL)
Else
Set_Ref Com(#myHandler) To(*CREATE_FROM 'B') Com_Error(*SET_NULL)
Endif
#myHandler.callit Data(#data)
Endroutine
End_Com

B (Windows Side)
---------------------------------------
Function Options(*DIRECT)
Begin_Com Role(*EXTENDS #AA)
Mthroutine Name(callit) Options(*REDEFINE)
CALL_SERVER_FUNCTION LOGIC
Endroutine
End_Com

C (Web Side)
---------------------------------------
Function Options(*DIRECT)
Begin_Com Role(*EXTENDS #AA)
Mthroutine Name(callit) Options(*REDEFINE)
Define_Com Class(#SERVER-MODULE.FindAll) Name(#doit)
#doit.Execute
Endroutine
End_Com

Note:
the Ancestor centralizes the data references.
the shared mthroutine includes the data references
the dynamic creation of a reference to objects depending on platform

The form and web page would both simply reference the router (A) and call the method callit in this example.

There are probably several variations on this theme.

It would be interesting to see some other interpretations on this theme, so hopefully there will be some other responses.

atostaine
Posts: 408
Joined: Wed Jan 20, 2016 7:38 am

Re: Running in VLF and VL for Web

Post by atostaine » Wed Sep 21, 2016 6:12 am

Thanks I just got back into this. I'm looking forward to testing it out.

Art
Art Tostaine

MarkD
Posts: 625
Joined: Wed Dec 02, 2015 9:56 am

Re: Running in VLF and VL for Web

Post by MarkD » Wed Sep 21, 2016 8:23 am

A key concept here may be understanding that you can pass working lists around in VL components. In VL components they are defined as #PRIM_ACOL collections and you pass them around as references to that collection, but you also can pass them to server modules (Web) or remote procedures (windows) as normal DEF_LIST working lists and they can access them using the normal ADD_ENTRY, SELECTLIST, etc commands.

User avatar
Stewart Marshall
Posts: 417
Joined: Thu Nov 05, 2015 5:25 pm

Re: Running in VLF and VL for Web

Post by Stewart Marshall » Wed Sep 21, 2016 8:49 am

Hi Art

The idea of switching between Windows and Browser implementations seems attractive at first glance, but I think it's probably more trouble than it's worth in terms of making the UI. There are simply too many differences between Windows and browsers. e.g. Modal vs modeless windows, synchronous vs asynchronous server access, control differences, operating system access, local device access and so on.

However, the idea is not entirely without merit from a data perspective. If we limit the scope to the data model, it is entirely possible to make something that determines the platform it's running on, loading the data accordingly.

I'm yet to make a sample to demonstrate this, but I'll bump it up the list

Regards
Stewart Marshall

Independent IT Consultant
www.marshallfloyd.com.au

atostaine
Posts: 408
Joined: Wed Jan 20, 2016 7:38 am

Re: Running in VLF and VL for Web

Post by atostaine » Fri Sep 23, 2016 5:10 am

Stewart: Yes I understand. I could see where we might want to have two GUI's for some new development and one set of I/O components.

I look forward to seeing your examples.

Art
Art Tostaine

atostaine
Posts: 408
Joined: Wed Jan 20, 2016 7:38 am

Re: Running in VLF and VL for Web

Post by atostaine » Mon Nov 07, 2016 11:48 am

With LansaGuru's example, don't I have to duplicate I/O code in my server function and my function?

Sorry if I'm not grasping the concept. But for a simple example of filling a list with employees, isn't my Select from_file, Add_entry, EndSelect in two places?

Thanks!
Art Tostaine

User avatar
Stewart Marshall
Posts: 417
Joined: Thu Nov 05, 2015 5:25 pm

Re: Running in VLF and VL for Web

Post by Stewart Marshall » Mon Nov 07, 2016 12:57 pm

Hi Art

This really comes down to how abstract you want to be.

Directly accessing a server database from a Windows application is something that LANSA can do, but it's not necessarily best practice. SELECT code is generally better placed in a function on the server that returns a working list.

Once that abstraction is made, you're left using SELECTLIST, ADD_ENTRY in desktop and browser.

However, you still have the requirement to use CALL_SERVER_FUNCTION or a SrvRoutine in a ServerModule. So, if you then want to go the next step, you can bury this behind another level of abstraction such as a data model. The data model can provide access to collections of data e.g. Customer, Order and so on. The data model will create a loader for the appropriate platform at runtime.

I prefer data model based applications. I find they make coding complex UI far simpler, but they're not for everyone and they do require a little getting used to.
Stewart Marshall

Independent IT Consultant
www.marshallfloyd.com.au

HamadSheikh
Posts: 27
Joined: Fri Mar 18, 2016 3:49 am
Location: USA
Contact:

Re: Running in VLF and VL for Web

Post by HamadSheikh » Tue Nov 08, 2016 4:47 am

I would agree with Stewart on this one. There is little gained by mixing up the two executions and such implementations can easily become maintenance nightmares for new developers who inherit the application code. Especially since all the LANSA training and examples follow a clean path as far as such executions are concerned. Having to duplicate I/O code would be the least of my worries when designing with such an approach. Platform differences would become a bigger concern over time as things on the Web have been progressing far faster than those on the Windows Client side over the past few years. I would suspect that such a "mixed" approach would soon fall into a single "favorite" execution (say web) and the other would simply be ignored after a while. Just my humble opinion. Design should be simple, elegant, fast and easily maintained.

Post Reply