Thanks for persevering with me Jaque (et al). I think I get the subtlety now.
RevServer will not be a web server that interprets deployed stacks' UI elements as web pages. Stacks deployed to revServer are purely a convenient container for server-side scripts - to avoid the need to save the scripts out to text files. Any browser UI elements would be contained within a separate revlet stack that is deployed to the server as an application - to be downloaded into the LiveCode plug-in within the browser. So, development of client and server functionality is undertaken separately and as revServer ≈ PHP, the LAMP server stack becomes LAML - or, if arrays are sufficient for persistence, LAL. I get it but given my requirements, that begs another question - and another thread... Thanks again, Keith.. On 18 Feb 2011, at 19:02, J. Landman Gay wrote: > On 2/18/11 3:10 AM, Keith Clarke wrote: >> Thanks for the clarification Jaque. >> >> So, my expectations for the shipping version weren't too far off - as >> it would allow development using stacks (as with the desktop apps) >> and upon deployment to the server, a standard browser would be able >> to interact with the UI-specific, stack pages on the server, without >> the need for the rev web plugin. > > No, I'm afraid that's impossible unless you use revlets. Browsers don't know > anything about how to display stacks or their components. They wouldn't know > what to do with a stack, just as they don't know what to do with a Flash > file. All a browser knows is that it should direct those files to a specified > plugin. There is no native support for Flash files in a browser, just as > there is no native support for LiveCode stacks. I think you are confusing > client-side and server-side scripting. > > Support of stacks in irev just means that you will be able to insert the > script of a stack (and possibly other objects) into the message hierarchy so > you can use its handlers in your iRev commands. I didn't know it before, but > Bjoernke mentioned it might also allow you to reference and send images > stored in the stack for use in the browser (browsers do know how to deal with > images.) So that would allow you to store all your images in a single stack > instead of offloading them separately to an images folder on the server. > > The server product is much like PHP; it allows you to create dynamic web > content by using scripts that create HTML on the fly. It does nothing at all > with the browser display; it can't. The server can only send HTML back to the > browser, and it is up to the browser to figure out what to do with that. If > the browser doesn't recognize something, it looks for a plugin that can > display it; if there is no plugin, you get an error. If the content is HTML > or something else the browser does understand, it renders it and you see a > web page. > > The server product already does what it's supposed to, and it works well. We > are missing the ability to insert a stack script as a library, but that is > easily worked around by copying the script to a text file and including it > that way. We are also required at present to load all images onto the server > instead of storing them in a stack file, but that is the standard for web > development anyway. > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > > _______________________________________________ > 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 _______________________________________________ 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
