LC Server style survey: co-mingle code w/HTML?

[Richard Gaskin]

Alex Tweedly wrote:

 > On 06/12/2017 19:14, Richard Gaskin via use-livecode wrote:
 >>
 >> There's a difference in terms of the primary execution object, and
 >> how that effects the flow of both execution and the workflow.
 >>
 >> It seems I'm unable to articulate it clearly enough, but no worries.
 >> The bottom line is that LC Server scripts are incompatible with LC
 >> Script on the desktop, and when used with wrapped HTML there's no
 >> need for me to generalize my tools because they can't be used in that
 >> context.
 >>
 > I'm still unclear on what does (can?) and what doesn't (can't) be done
 > with LC Server scripts on the desktop.
 >
 > If I don't use mingled/wrapped HTML (which I certainly don't, afaik) -
 > could I use your tools for my LC Server scripts (nb - they do use
 > 'include's).
 >
 > In fact, to be even more specific - assuming "my" scripts are actually
 > revIgniter with a controller or two added by me, would it be possible
 > to use the tools ?

By what means would you execute those with LC Script on the desktop?

A few examples of incompatibilities between LC Script on the desktop and 
LC Server (designated by letter in case anyone wants to refer to any of 
these):

----------------------------------------------
EXAMPLE A

This:

   <?lc put "Hello world" ?>

...runs great when you pass a file with that to LC Server.  LC Script 
for the desktop won't know what do to with it.

You could run that as data through the merge function and it would work 
well, but that's a different execution sequence than passing a file 
directly to an engine.

----------------------------------------------
EXAMPLE B

The implicit merge LC Server uses is more complete than the 
explicitly-called merge function.  For example, the merge function 
doesn't handle conditionals cross non-code parts, e.g.:

   <?lc if a = b then ?>
      <p>Some data that happens to be HTML</p>
   <?lc else ?>
      <p>Some other data that happens to be HTML</p>
   <?lc end if ?>

That'll work in LC Server, but AFAIK is incompatible with LC Script on 
the desktop.

----------------------------------------------
EXAMPLE C

For the first dozen or so years of the desktop engine, you could pass it 
a text file with something like this in it:

   on startup
      put DoSomethingWith($REMOTE_ADDR) into tReply
      put "HTTP/1.x 200 OK" &cr& \
        Content-Length: "& len(tReply) &crlf&crlf& tReply
    end startup

With the introduction of LC Server the ability of the desktop file to 
handle plain text files containing code disappeared.  In its place only 
LC Server could handle those, and only when wrapped within the "<?"/"?>" 
tags.

----------------------------------------------
EXAMPLE D

Environment variables in the original desktop engine were handled 
directly as defined by Apache.  In LC Server they are copied into vars 
that are similar but not the same, e.g. the env var:

    $REMOTE_ADDR

...is available in LC Server as:

    $_SERVER["REMOTE_ADDR"]

----------------------------------------------
EXAMPLE E

A few years ago on of the team members recognized that it would be 
useful to be able to run simple text files containing scripts only with 
a bare engine.  Since LC Server is the only bare engine now executable 
by itself without having to be made into a standalone, and perhaps 
unaware of the long history of having been able to do this before, it 
was added but in an odd way, without any handler declaration, just raw 
statements, e.g.:

   get 1+1
   add 5 to it
   put SomeFunction(it) into tResult

   function SomeFunction p1
      return p1+100
   end SomeFunction

So code outside of a handler is a sort of implied handler, but to 
distinguish that code from anything in an actual handler the other 
handlers look like handlers.

This is unlike anything in any xTalk, and breaks the otherwise 
beautifully learnable consistency of "code lives in handlers".

----------------------------------------------
EXAMPLE F

Even more recently it was recognized that script-only stacks can be 
useful, so now you can have something almost like the original text 
files we used to use, but with the addition of one line at the top 
specifying that it's a "stack":

     stack "Some Stack Name"

     on startup
        DoSomething
     end startup

AFAIK this is not compatible with LC Server, at least not in terms of 
expecting the startup handler to fire if you pass that text file to it. 
I don't know if it'll choke on the "stack" declaration, but my 
understanding is that only code outside of any handler is used in the 
role of a startup handler.

You can, however, bring it into use as a library, provided you have some 
other execution object (an HTML file) use "start using".

----------------------------------------------
EXAMPLE G

With the LC Script desktop engine, "put" commands output to stdout at 
the time they're called.  With LC Server it appears "put"s are buffered 
and output as a single stream when processing of the page that has been 
completed.

----------------------------------------------

There may be other differences; these are just the ones off the top of 
my head.

Before LC Server there was one engine and it worked according to one set 
of rules:

- Execution began with a startup handler, which could be in either
   a text file or a script.

- If you wanted to mix HTML with LC Script, you could read those pages
   in an run their contents through the merge function.


When LC Server was introduced it follows a more PHP-flavored way of working:

- Execution begins in an HTML page, in which LC Script is embedded.

- A rough equivalent of merge is automatically applied to that page
   automatically, but using a form more complete than the merge function
   available to the desktop engine.


Having enjoyed many years of CGI development with the desktop engine 
before LC Server came along, I was initially excited by the prospect of 
a server-optimized engine.  And indeed it handles a few things nicely 
that we used to use a bit of custom code for (parsing POST, etc.).

But in practice I found that those conveniences were more than offset by 
not being able to run or debug code within the IDE.

So I returned to using the desktop engine, in the form of a standalone. 
Stylistically it's a bit different from working with LC Server, but very 
much akin to what we used to do before LC Server.

But my interest isn't about maintaining old workflows.  It's about being 
able to write, run, and debug efficiently.

I can honestly say that much of the work I've been doing would have been 
far more expensive to produce if I'd been limited to having to use LC 
Server.

Imaging baking a pie.  Then imagine baking a pie in a bottle.  ;)

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com