NonDesktop apps

My data will all be derived from .dbf files and is currently accessed from an ODBC connection.
I do not know Javascript and I do not know what is needed to convert my Lianja/VFP so that it can be dynamic HTML5/Javascript Code.

Currently all CRUD operations are primarily handled through virtual tables.
I do not understand how server side data access is not required.
1. How much of my current Lianja/VFP code can be used (there is lots of code)?
2. Can existing .prg files still be used?
3. If I create .rsp pages, how do I know what needs to be placed in it and what shouldn’t be?
4. If I don’t know JavaScript, isn’t it still required for client side programming?
5. The scripting language is set to ‘Inhert’. Does this need to be changed?
If I change the view of my app to preview in a browser, my menu items do not work (one of which shows/hides a search panel), the grid can’t display, the page doesn’t scroll and my data isn’t displayed.
How would you recommend proceeding in changing my app to be web usable as well (as best as you can without having it in front of you)?

look at the web app examples. Work through them to better understand what is going on client/server.

The client web app running in the browser dispatches requests to the cloud server using an odata url. Read the doc about odata on the website.

The cloud server handles odata requests, generates the SQL for them, executes it and sends the data back in industry standard JSON.
It handles native tables and virtual tables.

In a client/server application the UI is separated from the backend business logic procedures and the database access.

So, the delegates that are related to UI events must be written in JavaScript which is the core scripting language that a web browser understands.

The Lianja object model (LOM) is available to your JavaScript code just as it is in your Lianja/VFP code in your desktop application.
This is one of the ways Lianja achieves UI device independence.

The Lianja Web Framework provides most of the Lianja system object that you are familiar with in writing desktop apps, so Lianja.evaluate() etc is available to call server side business logic written in Lianja/VFP and (in v2.0) Lianja.evaluateJavaScript() for calling server side business logic written in JavaScript.

Client/server development requires you to separate UI from the business logic. The client needs to handle client specific functionality not be designed as one large monolithic application that does everything all in one place as you would in a desktop app.

Hint: if you have a page or section that is bound to the desktop app you can omit it from your web app by using UI personalities which are enabled or disabled in the attributes.

What I find amazing about Lianja is the myriad of ways to get things done.

For example, a beginner can use very little coding to get a fully functional web application done just by using the best practices.

He/she doesn’t need to now much about javascript, CSS, PHP (or .net), html etc.

Fully updatable data driven web applications.

Brilliant really.

But it doesn’t stop there. The more advanced users have tools build in the Lianja world to allow interaction between the Lianja objects and purely web based technologies. The showdialogs,evaluate and Odata come to mind.

But it goes further. If you are like me and like to tinker with all sorts of technologies, you can quickly appreciate the Lianja world as one that allows you to go as deep as you want into database web applications.

For example, I downloaded a Bootstrap theme that I liked, added my own rsp pages for the look and feel using Kendo UI.
I have created RSP pages that have a mix of SQL Server code and VFP code for a logic layer and return that all back the front end. All using the powerful cloud server for very quick response.

For this particular project, I am developing directly into the cloudserver apps root directory. Meaning, I am not using the Lianja IDE to create a fully Lianja supported project.
I am doing that, because in this particular project, it makes sense and being that the flexibility exists, I am happy to use it.

My point is to illustrate the incredible flexibility of the cloud server and the RSP pages.

Together, they can do anything you can think of.

Here is what my dev environment looks like.

Best practices for one App that runs on desktop and web and mobile. (As already stated in the doc link you provided).
1. Client code (delegates, custom sections, canvas section) should be JavaScript.
2. Server code can be Lianja/VFP (or JavaScript in v2.0).
3. You can call Lianja/VFP “Business procedures” that run on the server using Lianja.evaluate() (and Lianja.evaluateJavaScript() respectively in v2.0). So you can call validation, perform calculations and lookups on the server. Its seamless.
In the final release of v2.0 there is also an app.conf file which you can add to an App that “tells” the client what procedures/functions are handled by the server.
This provides transparent remote function calls that are made in the client that execute on the remote server.

ability to call server side procedures that are contained in libraries as follows.

// Client side JavaScript (notice the :: preceding myfunc()
var result = Lianja.evaluate("mylib::myfunc()");
// Server side Lianja/VFP in mylib.prg
proc myfunc()
    return "hello world"

We will be providing a way to register server side functions in the Web/mobile client so that they can be called as if they were JavaScript client side functions.

So for example you will be able to just do this in your client code.

// Client side JavaScript
var result = myfunc();

And myfunc() will be executed on the server.

I have a canvas section, with a textbox, used to set search criteria.
I have a form section bound to a virtual table. Data is loaded into a form section by requerying the section.
Next I need to populate a grid section (also bound to a virtual table) based on a value from the form section.
(Note: setting the relationship isn’t used because of multiple related fields).

This does not seem to be an issue in the desktop, although it is an issue in the web client do to asynchronous calls (which I believe is happening in this case). The form data most likely will not be loaded when the grid section is processed. I am using the value in the textbox to perform a separate query to get the value needed to populate the grid section (by requerying the secton). This is why I am attempting to figure out the best way to access the data.
How would you suggest I perform queries such as the one described with sqllookup?

You cannot use sqlxxx() functions in the client.
The registration form code is all there so you can study it.
It calls business procs on the server.

You do not need to do anything at all with JSON if you build a business app using best practices.

There is no such thing as “a table is already open” in a web client/server app as this is stateless.

You can call a server side lianja/vfp procedure to perform your lookup. If you are doing that the proc is running on the server NOT the client.

Pages are made up of sections that can be related together (as you already know).

If you call the “requery” method on a section and give it a query expression then the data will be looked up on the server asynchronously.
When the call completes if data is found to match the query the section will be refreshed with the data then any child sections will be refreshed based on the data relationship between the sections.

This is no different to desktop operation.

What is a primary key in SQL
A column NOT an expression

When you add a record to a child section the parent expression is used to maintain the child relationship.
An expression cannot be used to link the parent and child sections it is makes no sense.

If you want to do everything manually, fetch your data from your server side proc, populate the fields if you want to build things manually, then use requery() on the target child section to populate the child grid.

You can use the requery() method on a section to lookup records on the server and populate the section.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s