LiveCode Forums.

Sorry if this is redundant, I couldn't find anything that answered this in the forum.

I understand why the "standalone build for web" has been dropped.
Within this discussion it seems that people imply the lc server will do everything that the standalone builder would.

I have not been able to duplicate anything even close to the web pages generated out of the old method.

A specific example, how do I code within the <?lc ...........?> to display a button that say takes input from a field and processes it, posts it to a cgi script back on the server.

I have the post and cgi processing down, I just need to know where to find the info to learn how to code an input button like a good old stack button that will appear on a web page. I don't know php or java, just good old livecode scripting. Is there a place to point me to get me started?

Thanks as always to the best community of coders EVER !

With LC Server, buttons and fields... are just HTML objects.


For instance :
When the user clicks on the button, the form will be sent (POST) to the "menu.lc" LiveCode Server file.

Thank you Bangkok for your reply.
I have the form method and post in hand.
I used a poor example.

Suppose a typical runrev STACK had a button named "YES" and another named "NO".
I'd like the name of the button to appear inside of the buttons and control the graphics of the buttons as well.
There is a field named "answer"

The script of the "YES" button would be:

on mouseUp
put "YES" into field "answer"
end mouseUp

The script of the "NO" button would be:

on mouseUp
put "NO" into field "answer"
end mouseUp

This is trivial but how do you do this with coding and the LC server?

Is there a way of mimicing this sort of dynamic WEB PAGE behavior with the LC Server and some specific code on the html of the page?

Thank you again.

Pbower

Hi Pbower,

although the name "Livecode Server" suggests something different,
the LC server can NOT serve any visual representation of a stack!
See it as PHP with an easy and readable syntax

You need to to script everything in HTML & Co. as Bangkok said.


Best

Klaus

pbower wrote:I understand why the "standalone build for web" has been dropped.
Within this discussion it seems that people imply the lc server will do everything that the standalone builder would.

I've not come across such a discussion, and I'm afraid that's incorrect: the old Standalone Builder option was for delivering CLIENT-side materials, while LiveCode Server is a SERVER-side solution.

With client-server systems, each side has a unique role: a server provides the content the client will display, but that content must be in a form the client software can understand.

If the client is a Web browser, there's only one interactivity language all web browsers support: JavaScript.

With dark irony, there's an upside to having only one choice for providing interactivity for the browser: we needn't spend any time evaluating alternatives to decide which language to learn, because there aren't any alternatives.

The content a Web browser can understand and display must be HTML, augmented with styling provided in CSS and with interactivity provided with JavaScript. No viable alternatives exist for this, so anyone interested in delivering apps specifically within a Web browser have no choice but to learn at least the basics of those three components. Thankfully they're enormously well documented, and reasonably self-consistent, and with each only a handful of things is necessary to learn to get started, so they're not all that hard to learn.

That said, in many cases it can be quite useful to use the Web's HTTP protocol to deliver native LiveCode stacks with all the benefits of a Web browser app in terms of central storage, instant updates, etc., by switching the client from an ordinary Web browser to a custom app built with LiveCode.

Doing so can be as simple as this one-liner in the client standalone: In the LiveCode IDE, see Development->Plugins->GoRevNet as one example of this sort of thing - aside from the first stack that displays the download progress, all the stacks and data you see that point on are delivered from several different Web servers.

A custom Web-savvy standalone is easy to build, and provides some advantages a Web browser can't, including a UI dedicated to what you're app does (obviating the need to handle such disruptive distractions of how to handle the Back button or other controls browsers include for things that may not be relevant to your app), and even using the secureMode option to deliver an experience that's actually more secure than any Web browser can be.

As with the old browser plugin RunRev once experimented with as delivery option for the Web, a custom standalone also requires a one-time install. And like the old plugin, once installed it can download and run any stacks you put on your servers, but with fewer constraints and much more flexibility than the plugin could deliver.

But all that only addresses the client side.

On the server side, LiveCode Server has a role very similar to PHP, in providing a language that lets you process instructions sent to the server to generate data the server will then pass back to the client.

When the client is a Web browser, the data returned must be HTML so the client can display it (or if called from an AJAX routine, it may be XML or other format suitable for that discrete operation).

When the client is a LiveCode-based standalone, LiveCode Server can deliver data in any format your client can use. I frequently have server routines that deliver simple tab-delimited lists that LC-based clients use by just putting the data into a list field for quick and easy display in one step.

In a world that's increasingly realizing the benefits of dynamically-generated, user-specific content, LiveCode Server is finding a useful role in a wide range of client-server apps, both with Web-based clients and with clients built as custom standalones with LiveCode.

But the two roles, client and server, are very different from one another, and for all of LiveCode Server's usefulness it can't turn an ordinary Web browser into something that can understand LiveCode stack files.

To answer your original question about how your layout would be expressed in HTML/CSS/JavaScript, copy this to a text file and name it "Example.html", then drop it on your browser: Although a very simple example, it illustrates a few key concepts you'll learn as you begin making interactive Web pages:
- CSS defines the visual attributes for elements on the page, very similar to many LiveCode properties.
- The page's head element can contain scripts your objects can call, similar to how we use handlers in LiveCode objects to call handlers in the card script.
- The head/title element is very similar to the stack title property in LiveCode.
- In CSS, "#" is used to denote styles for a specific object using its ID, while "." denotes styles that apply to classes of objects. Here we've put all of the common attributes into a class called "Btn", and put the only unique attribute (the left) for each button into the CSS definitions for those objects.
- Referring to objects in JavaScript is tedious compared to LiveCode, most commonly done with the document method getElementById, whereas in LC we just use things like "field 1". That type of stuff is annoying at first, but becomes second nature over time so it's not as bad as it may seem at first.

All three of the types of things used here (HTML, CSS, and JavaScript) are potentially deep subjects, but by playing with this example you can learn some of the basics. And given the similarity between CSS properties and LC properties, you may begin to see how LC can be used to generate layouts in HTML for Web browsers. The great thing about HTML is that it's ultimately all just text, and LiveCode is unusually adept at manipulating text.

The hardest part will be the interactivity, JavaScript. It's very different from LiveCode, but like LiveCode once you learn a few basic techniques you can recombine those to build ever more interesting apps. And like LiveCode, there's always something new to learn, and plenty of examples in the community of other users of the language to help solve nearly any problem you may come up against.

The hardest part with learning JavaScript is that some browser vendors (most notoriously Microsoft) have a cavalier disregard for widely-published standards, so from time to time you can expect to implement browser-specific forks for some CSS and JavaScript stuff, whereas in LiveCode we're usually insulated from the whims of platform vendors.

Still, if you need to deploy to the browser you'll need to pick up this stuff anyway, and the world is full of learning resources for them.

And if your project can lend itself to using a LiveCode standalone as the client, it's all that much easier.

I can't believe how wonderful all of you folks are.
Thank you, thank you for your detailed answers.

I reiterate : you are the BEST COMMUNITY of CODERS EVER !!!!

There really is a lineage of excitement and generosity that started with Hypercard and has carried through to this day.
Very few things in the computer world can live up to that.

Pbower