LC Server - Smart Interactive Fields?

[Rick Harrison]

Hi Richard,

I was afraid you’d say that!  LOL

I think I’m stuck with JavaScript then according
to what you’ve explained here, and for what I 
need to do.  A web app just won’t cut it.

Thank you for investing your time into the verbose explanation.
I’m sure other users in addition to myself will find it useful.

Thanks again,

Rick

P.S.  I think LiveCode could make more money if they
        invested somewhat more into these other technologies.

> On Apr 22, 2017, at 2:29 PM, Richard Gaskin via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Rick Harrison wrote:
> 
> > I was wondering if anyone has come up with a way to create
> >  “Smart Interactive Fields” in LiveCode server without
> > having to use javascript?
> >
> > For example:  The user types in a number in the wrong format
> > into a field and the field is smart enough to interactively tell the
> > user with a tool-tip or other pop-up instruction that says the
> > correct format is $999.99 or perhaps automatically corrects
> > the problem for them.
> >
> > Any ideas?
> 
> Browsers have only one language built in, and of course that's JavaScript.
> 
> Anything that responds to user actions, such as keyboard and mouse events, will require JavaScript.
> 
> Any server CGI, such as LiveCode Server, has a role limited to the server: a request comes in over the wire, it performs some task, and then returns data.
> 
> How that data is requested from within the user's browser, and what the browser does with the data once it comes back from the server, is a task you'd handle in JavaScript.
> 
> 
> Options:
> 
> a) LC's HTML export
> -------------------
> If you have a license for LC's HTML Export option, or are working on a GPL-governed work where the HTML Export included in the Community Edition would be a good fit, you may consider that.
> 
> With this option, the LC engine is made available to your site as a JavaScript library, which then reads your stack and handles things within it's own canvas somewhat similar to running with a standalone engine, but within a portion of the browser window.
> 
> Be aware, though, that it's still in development, and may or may not yet support the features you need.
> 
> Personally, I'm big on quick-loading pages, and even with compression the entire LC engine is a rather sizable chunk of JavaScript to download, unpack, and initialize before it can render the page.
> 
> There may be ways to eventually bring that down to fit into the 6-second rule, but at the moment it takes longer than that.
> 
> 
> b) JavaScript
> -------------
> Dive in, the water's fine.
> 
> It's not a bad language at all, and very useful.  For anyone who programs only in LC and is looking to pick up a second language, IMO JvaScript is an ideal choice because it covers the use-case LC covers the least well at the moment, web browsers.
> 
> Extra bonus points that once you learn it you can write scripts for Node.js and other tools that use JavaScript as their foundation.
> 
> This book is fun and easy to work through to get started:
> 
> Head First JavaScript
> http://shop.oreilly.com/product/9780596527747.do
> 
> 
> c) RIA - Rich Internet Application
> ----------------------------------
> A standalone made in LC can deliver nearly every benefit of delivering an app in a browser, exchanging not only data with a server but even stacks as well.
> 
> An RIA lets you deliver an application with an interface dedicated to the workflow your app supports, with many options for integrating with the local OS far more than a browser app could dream of.  And users never need to worry about accidentally obliterating what they're working on if they accidentally hit the Back button.
> 
> I've waxed about RIAs often enough on this list that I won't take up more bandwidth here on the subject except to answer any questions and to offer this observation for now:
> 
> When it comes to delivering an application over the Internet, many folks here say:
> 
> "Customers don't want an app!  It has to be delivered in a browser!"
> 
> Let's set aside for a moment that no one using XCode, Visual Studio, Xamarin, or most other app dev tools ever considers exporting web pages a requirement for those tools at all.
> 
> Let's look instead at the sentiments expressed here regarding mobile apps:
> 
> "Customers don't want a web app!  It must be delivered as a native app!"
> 
> :)
> 
> There are strengths and weaknesses of both OS-native apps and browser apps.
> 
> What's "best" depends on a lot of factors that will differ from app to app and business model to business model.
> 
> On mobile, Facebook offers a limited web app with a feature-rich native app.
> 
> On desktop, Evernote offers a limited web app with a feature-rich native app.
> 
> On mobile PayPal offers a limited native app, with a more feature-rich web app on the desktop.
> 
> There is no single "best", no magic pony of "one size fits all".
> 
> If all you need is a web page and not a web app (murky distinction, I know, but worth distinguishing), then you really have little choice but to use the only language available in that environment: JavaScript.
> 
> But if you need to deliver serious functionality for non-trivial use, RIAs can do that with a better user experience and usually far faster development time than trying to cram serious work into the confines of a browser window.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> Ambassador at FourthWorld.com                http://www.FourthWorld.com
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode