http:// localhost/ lansa14 / dem / xedmain.html ? lang=eng & developer=yes
What does this mean?
In bold, from left to right, we’ve got:
- system id
- partition id
- webpage id
- language parameter
- development parameter
How is this information used?
This URL is inspected by the LANSA Web Plugin, it uses the system/partition id to retrieve the generated HTML from the Application Server.
NOTE: The generated HTML is really a template, it has some substitution markers, which are used by the Web Plugin to substitute the system and partition id into its response HTML. The HTML needs it so that additional resources, like the JavaScript that is required to make it run, can be requested through similarly formatted URLs.
It will eventually return something like this:
Code: Select all
<!DOCTYPE html>
<html lang="en" style="height:100%">
<head>
<meta charset="utf-8" />
<meta name="mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-touch-fullscreen" content="yes">
<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
</head>
<body style="height:100%; margin-left:0px;margin-right:0px;margin-top:0px;margin-bottom:0px">
<script src="/lansa14/lansa_14_0_1_0/lansa.js"></script>
<script>
(function(LANSA){
if(!LANSA){document.write("Failed to load lansa.js");return}
LANSA.init({part:"dem",sys:"lansa14",lang:{def:"ENG",code:{"FRA":"fr-FR","JPN":"ja-JP"}},splash:{limg:"spin",mtxt:{"ENG":"Loading...","FRA":"Loading...","JPN":"Loading...","LLL":"Loading..."}}});
LANSA.showPage("XEDMAIN");
}(window["LANSA"]))
</script>
<noscript>This page requires JavaScript.</noscript>
</body>
</html><script src="/lansa14/lansa_14_0_1_0/lansa.js"></script>
...
LANSA.init({part:"dem",sys:"lansa14", ...
Where you see the system/partition id being made available inside the HTML.
So, to execute a Visual LANSA Web Application, it needs to start with HTML like this, which contains the system and partition id so it can request additional resources back of the application server.
Of course, this HTML doesn't necessarily have to be delivered through the process described above.
If your website goes into production, and you like to make it available through a classic http://www.mysite.com/index.html, you can do that. You can grab the HTML as provided by the Plugin, copy it into an index.html and put it on your Web Server. Now your web application is up and running with a simple URL (http://www.mysite.com), and you no longer rely on the URL to provide the application server details, instead it's hard-coded into the HTML.
What about the language parameter?
You’ll notice the HTML specifies which languages are supported, as well as which language to use if NO language parameter is present on the URL. So you generally don’t need it unless you've re-directed users to run your page in a non-default language.
What about the developer=yes parameter?
“developer=yes” is (of course) purely for development.
How the browser-caching behaves depends on whether or not your Web Page uses the Application Cache (see the Offline Support Tab).
WITH a cache manifest, the browser will ONLY refresh resources if the cache manifest file itself has changed, which you accomplish by re-compiling the Web Page.
WITHOUT a cache manifest, the browser will refresh resources based on all the standard rules to do with expiry headers etc..
“developer=yes” is a trick to bypass the browsers caching at development time, so you don't have to remember to re-compile the containing Web Page every time you make a change to a reusable part.
In production you DO want caching (specifically if you start making offline capable applications). Make sure re-deploy the cache manifest file, if you use one, even if you're just changing a reusable part.
I hope this is helpful, let me know if there are any questions. I'm very interested in any additional thoughts on deploying to a production system and configuring the URL's.
Danny