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

[Mark Waddingham]

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