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

[Brian Milby]

Human readable conversion would be easier if multi-line strings were
supported (without the manual splitting currently needed). This would allow
a single put statement between LC blocks of code and no need to fuss about
quote characters.

Then you would only need to worry about handler definitions. The rest would
just get wrapped in a default handler. Have not looked at included though,
so not sure how that plays in yet.

When I was reading earlier replies I was thinking of using an array instead
of properties for the HTML blocks. Not sure if there is much difference in
the two though.

For debugging, I’m guessing that you (Mark) are saying that a mapping of
converted line to source line would be maintained so that when errors are
flagged the dev could be presented the correct line in source. I’m guessing
that this would also work for stepping through code.
On Sat, Dec 9, 2017 at 7:29 AM Mark Waddingham via use-livecode <
use-livecode at lists.runrev.com> wrote:

> On 2017-12-09 13:40, Alex Tweedly via use-livecode wrote:
> > Would it not be easier to transform the text blocks in to a (series
> > of) "put" statement(s) ?
> > Being "put"ted  is exactly what is going to happen to the text in the
> > non-code blocks, so why not just do that.
>
> Are you sure they would be put'd? ;)
>
> The use-case I was inferring was one of 'emulation of LC server inside
> the IDE'. Richard wasn't all that specific about the tooling he has for
> LiveCode CGIs, but I have assumed that the tooling *does* abstract
> output - after all, 'non-targeted put' in the IDE puts things in the
> message box - which is great for looking at, but not so great if it is
> going to be fed into something like a browser for display.
>
> Since we are talking about emulation (in this case basically 'compiling'
> a LC server script to a LiveCode Script to be able to run it outside of
> LC Server), the actual intermediate script which runs the same as the
> original doesn't have to be readable by humans. After all - when
> debugging you don't look at the machine code generated by a compiler but
> at the original source instead. The error positions and such can be
> easily mapped by using a sideline array which maps line/row indexes in
> the intermediate script back to the original - i.e. the intermediate
> script is just an implementation detail.
>
> Of course, the thing here is that mechanism which allows an emulation
> also allows a conversion (i.e. forever leaving the LC Server style
> behind) - the difference is just how the inline text / and
> server-specific commands (e.g. put output, put unicode, put header etc.)
> are translated. In that case, I agree that pre-processing the text
> blocks and churning them out as a sequence of 'envPut <string>' would
> make much more sense (envPut here because, as discussed above, 'put' is
> not *necessarily* suitable).
>
> Another option would be to turn 'put' into a 'put ... after ...' and
> then return the string (this would then be very much 'merge'-like).
> Again, the variability here is just how *that* specific command is
> converted - which could easily be made an option of the compiler script
> which does the conversion.
>
> Anyway, would what I suggested (in terms of a LCServer->LCScript
> compiler written in LCS) be a useful thing?
>
> For those concerned about performance (although performance in an
> emulator is perhaps less of a concern than production), then there is no
> real need to be. The compiling process can be done ahead of time, and
> the cost is only once-per-server-script file - the compiled version is
> an LiveCode Script so would have the same performance characteristics as
> the original. Even if you wanted to use such a thing in a dynamic case
> (e.g. merge like), then chances are each template file would be being
> used more than once, so you actually gain performance after the initial
> compile.
>
> In this case, a C++ solution would offer no real advantage - in fact a
> huge disadvantage in terms of development time, maintenance and
> adaptability.
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode