Web Deployment

[david.silmanBUSrUeQ]

Hey all

I know this might not be the right place for this post (and if so I apologise)

I'm trying to build for web and test it, but so far I've not been able to get it to move between substacks, using:

Code: Select all

open stack "stack name here"

just freezes the program and stops it from continuing

I'm sure I've just missed something but I have no idea where to start when it comes to web development.

Thanks
David

[Klaus]

Hi David,

in a browser you can only have ONE stack to get displayed! Check this about the NON future of the web plugin:
http://forums.runrev.com/phpBB2/viewtop ... ent#p68893

Advice: Do not use the current web deployment feature of Livecode: "It's dead, Jim!"


Best

Klaus

[david.silmanBUSrUeQ]

Ohh, well that's a bummer, on both counts

Thanks Klaus

Cheers
David

[FourthWorld]

Do you need to be able to distribute stacks across the Web to clients, or do you specifically need to do that in a browser?

If the former, you can do that with a standalone, which contains only the splash screen and enough code to run this:

go url "http://www.somedomain.com/stacks/mystack.livecode

That way you distribute the standalone to be installed only once, just as you'd have to do with the browser plugin, and from then on you can update the app at any time by just replacing the stack files on the server.

In the few cases where stakeholders truly need a browser-based solution, ultimately they become less comfortable once they learn that they still need to install the engine, in the form of a plugin. This is among the many reasons why browser plugins have fallen out of favor, leading to RunRev's decision to EOL their own browser plugin. Such clients need a truly browser-native solution, and since the only scripting language built into all browsers is JavaScript the choice for that has been made for us.

Fortunately most projects for which it would be acceptable to download and install a plugin can be handled with a standalone just as well, perhaps better when we consider:

- In both cases the engine must be downloaded and installed.

- In both cases the code and user interface is stored centrally on a server, so the user always gets the most recent version when they run the app.

- In both cases LiveCode Server can be used to provide the back-end logic using the same easy language.

- A standalone has a dedicated user interface optimized for the task at hand, while a browser is a general-purpose app that has a lot of controls which either have no use in such an app or may affect it adversely (how does one handle the Back button in such an app?). Multiple windows are a breeze in a standalone, as are any other UI elements your app may employ.

- If security is a high priority, using the standalone's secureMode property can make it more secure than any browser, leaving a true zero-footprint on the client.

- A browser-based solution will always be dependent on a live Internet connection, while a standalone could be crafted to include caching and synching to support an offline mode if desired.

In those cases where a truly browser-native solution is needed, JavaScript isn't hard to learn and there are plenty of good resources for getting started. But given the various trade-offs, in many cases a project can be well served with a standalone that downloads its stacks.

Two examples of this sort of thing in action are included in the LiveCode IDE:

- User Samples (see the icon in the toolbar)
- RevNet (see Development->Plugins->GoRevNet)

The latter was made by yours truly, currently in a transitional state while I'm finishing a new version of the download stack, but the scripts there are accessible and you're free to use anything there you find useful.

[david.silmanBUSrUeQ]

Great reply, lots of information, thanks a bunch

The problem was that some of the major companies we're designing for have specifically said that they won't buy the system till it runs browser based, as they don't want to install the same program across however many machines (talking hundreds maybe thousands here) as such we were hoping that the web deployment would allow the stacks to be run on their intranet and therefore accessible from all their machines simply, we're also developing for windows, mac, android and ipad, which is the reason we settled on livecode in the first place, as it will compile for each without any rewrites.

Thanks anyway
David

[FourthWorld]

Great reply, lots of information, thanks a bunch

The problem was that some of the major companies we're designing for have specifically said that they won't buy the system till it runs browser based, as they don't want to install the same program across however many machines (talking hundreds maybe thousands here) as such we were hoping that the web deployment would allow the stacks to be run on their intranet and therefore accessible from all their machines simply, we're also developing for windows, mac, android and ipad, which is the reason we settled on livecode in the first place, as it will compile for each without any rewrites.

The core of the issue is that LiveCode stack files aren't understood by any browser.

Even if the RevWeb plugin were still being supported, there would remain the requirement to download and install it, as with any browser plugin.

If a one-time install is acceptable, it doesn't matter whether it's specifically in the form of a browser plugin or a standalone (other than the many additional advantages of a standalone, as noted above).

But if a one-time install isn't acceptable, not even any browser plugin solution would satisfy their needs.

For such a narrow requirement we'd have to limit our options to browser-native solutions, and since JavaScript is the only scripting language built into browsers we have no choice in the matter.

There can still be a useful role in using LiveCode to develop some aspects of the site with, and to generate the HTML/CSS/JavaScript for the site. I've written project-specific tools for this myself, one of which produces a subscription-based site used by hundreds of hospitals around the world. For that project we do both the layout and content management in LiveCode, and have another LiveCode script which uses HTML templates we've written for it to generate the pages, assembling snippets of JavaScript needed for the interactivity as it goes.

And there's still a role for LiveCode on the server, which I also use on that medical decision-support site.

An article describing an earlier version of the toolkit we crafted in LiveCode for that project is here:
http://www.runrev.com/newsletter/april/ ... etter2.php

But if the project requires truly zero-install it will require JavaScript, but fortunately it's not hard to learn. And given that LiveCode is uncommonly adept at manipulating text, and web pages are ultimately just plain text, there are probably countless ways LiveCode can assist the process of developing and deploying the site.

[mwieder]

There's also the long-term possibility in the future once the engine goes open-source of defining HTML5 as an output platform. Don't count on this as a short-term solution, though.

[emdalton]

There's also the long-term possibility in the future once the engine goes open-source of defining HTML5 as an output platform. Don't count on this as a short-term solution, though.

This is precisely my hope, and I've gotten some encouraging replies from the RunRev staff that this is a direction they hope to go, as well.

From a technical point of view, would it be easier to have LiveCode compile to HTML5, or have the LiveServer render to HTML5? I could go either way, for my needs.

[FourthWorld]

http://forums.runrev.com/viewtopic.php? ... 103#p71103

[bpalmer]

I'm having difficulty finding the samples that Richard kindly mentioned. Can anyone point me in the right direction with a link or other directions?

I'm just learning LiveCode and I need to implement a system very similar to what has been described here.

[Klaus]

HI bpalmer,

in Livecode -> Menu "Development" -> Plugins - GoRevNet
And welcome to the forum!


Best

Klaus

[emdalton]

Today is the last day to contribute and help make our dream of Livecode->HTML5 a reality. Please consider donating if you can!

[karmacomposer]

I did and a bunch of people did and now HTML 5 will become a reality, which I will REALLY enjoy using since I do a lot of database work and I need a easy and reliable way to create an app that works in a browser and can utilize localhost so that I do not have to keep putting IP addresses in the exclusion list and especially not have to resort to using wildcards!

I cannot wait for HTML 5 to eventually be included in LiveCode (though I know it will take a while).

The previous web plugin just did not work properly for most of what I do.

Mike