Thanks for the response and reminder of your post, Richard. I read the 'first edition' but now understand more of the fundamental differences between LiveCode and web concepts (which I know slightly, but not much better)! ;-)
I accept that there is far more to a web app than a set of forms, but then again, I don't see the need to map everything LiveCode to Javascript. Web apps tend to use MVC architectures or similar, so that developers can lock their intellectual property in the relative safety of the server. So, LiveCode Server would contain the main Model and Controller code and therefore most of the app wouldn't touch the client. The LiveCode language isn't currently designed to manage web pages. However, it's flexibility means that it could be easily extended with the necessary objects and functions (either in the core functionality or via a library or external). Page controller functions could manage those cards to be rendered as pages, adding template capabilities, DOM, layout management, markup for the contained UI elements and support for Ajax calls. See this Salesforce.com Visual Force Developer's guide to see how the Salesforce Apex language (analogous with LiveCode Server scripting) was exposed and extended for managing web pages http://www.salesforce.com/us/developer/docs/pages/index.htm IMHO LiveCode could be applied in a similar fashion to extend itself - indeed, this is the to do list! As I see it, with LiveCode Server in the back-end - with LiveCode page management functions in place - the only elements that would need to be mapped to HTML/CSS/Javascript would be the UI. And we have that to do list, too, as it's the elements currently banned from an LC Sever stack! So, if the LiveCode server stack contained cards (maybe in a designated 'pages' substack) that allowed UI components, the card UI controls could be associated with standard HTML blocks and CSS, with property mapping. Cards designated as pages could be complete 'LiveCode Pages' or divs to be rendered within pages of a web site managed outside of LiveCode. OK, there would need to be some Javascript glue for static pages, but the basics that could be a generic LiveCode Javascript or jQuery library. And of course, once this support for static pages was in place, the real challenge of recreating the rich app experience of LiveCode 'moving UI parts' could begin. However, meanwhile - and crucially - LiveCode developers could start delivering native LiveCode web apps into the Cloud and Enterprise space, where the browser plugin is generally not available. Best, Keith.. On 22 Sep 2011, at 15:39, Richard Gaskin wrote: > Keith Clarke wrote: > > > But even if it isn't easy, if RunRev don't grasp the nettle on > > this, developers who must deploy standards-based rich apps into > > cloud and locked-down Enterprise environments will be forced > > elsewhere, which would be a shame. > > I wrote about this last year: > <http://lists.runrev.com/pipermail/use-livecode/2011-June/157979.html> > > Like too many of my posts that's a long one, but it represents pretty much > everything I came up with that's relevant to the discussion, and I've been > thinking about this a long time since two of my biggest projects are all > about the web and are based in LiveCode. > > In short: > > There are two sides to this, client and server. > > On the server side RunRev has already provided what may be the most > cost-effective solution for that with RevServer. > > But the client is a whole other game, fully immersed not only in a very > different language but also in a deeply well-defined object model that, in > many respects, bears little resemblance to LiveCode's. > > We use LiveCode because a good scripting language lets us build things more > quickly than we could do in a lower-level language like C. > > But JavaScript is not a low-level language. It's almost as high-level as > LiveCode, and as well integrated into the object model it supports as > LiveCode is with its own. > > But the object models are very different. > > Attempting full translation of LiveCode to JavaScript would not be > impossible, but very expensive. IMO, when you consider the limitations > inherent in such a task, it's probably much more expensive than just learning > JavaScript. > > That said, there are many opportunities for using LiveCode to generate some > portions of the client-side experience for the web. A starting point was > outlined here in 2006: > <http://lists.runrev.com/pipermail/use-livecode/2006-June/083956.html> > > I haven't used the RB/web implementation, but I'd be surprised if it did full > RB->JavaScript translation; my guess is that the server side is very much > like RevServer and the client side is like the ToolBook approach I outlined > in 2006. > > We can have that too, and we needn't wait for anything from RunRev - anyone > with sufficient time and motivation can build this today. > > But somewhere along the way you'll eventually find limitations between what > LiveCode can do on the desktop and what a translation to a different object > model will be able to do on the web. There's more to apps than forms. > > And for those you'll want to use JavaScript. > > Fortunately, it's kinda fun to learn and there are orders of magnitude more > resources for that than we have for all the things we've learned about > LiveCode. > > Dive in, the water's fine. > > -- > Richard Gaskin > Fourth World > LiveCode training and consulting: http://www.fourthworld.com > Webzine for LiveCode developers: http://www.LiveCodeJournal.com > LiveCode Journal blog: http://LiveCodejournal.com/blog.irv _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
