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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
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
