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

[Mark Waddingham]

I must confess I'm slightly puzzled by this thread...

If you want to write web-apps like PHP - i.e. intermingling code with 
HTML output, then use LiveCode Server. If you don't want to do that, 
then just don't?

LiveCode Server supports stacks so you can do:

<?lc send "startup" to stack "foo" ; go stack "foo" ?>

In LC Server, which would give you a very similar situation to just 
running stack "foo" in a -ui standalone engine but with the added bonus 
of using the server-specific variants of 'put output'

Also the LiveCode Community Standalone engine has been able to take a 
stack on the commandline for years - on Mac you have to get at the 
engine from within the bundle  (i.e, .../Contents/MacOS/Standalone -ui 
<stack>) which is irksome, but blame Apple for that (its one of the 
downsides of folder-type app structures, although a minor one compared 
to the benefits they bring).

If you want commercial features, then yes - you do need to build a 
standalone which has a bootstrap stack in it - but if we didn't do that 
then anyone could take the commercial standalone engine and use it 
without a license so that ain't gonna change.

At some point it would be nice to unify the server/non-server engines 
but that isn't very high on the priority list at the moment (indeed, it 
sits really quite far down...).

Warmest Regards,

Mark.

On 2017-12-07 01:48, Richard Gaskin via use-livecode wrote:
> 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.  ;)

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps