String consts from HTML or SQL files lazarus / 21-General ---------------------------------------------------------------------- ydd · 2021-01-04 18:27 I need to use many files with HTML or SQL templates. Now I load them at run-time and need to keep near executable. I want to compile them into executable, but keep editing these files in external HTML or SQL editors - with highlight & options to validate or run. I know that I can use Lazarus Resources (https://wiki.freepascal.org/Lazarus_Resources) and load content using TResourceStream. But I'm sure that using string consts will work much faster and be easier to use. So what I need: - enum all *.htm & *.sql files in directory of current unit - create file with string consts (const name should be based on template file name) - include this file into project - when any of *.htm & *.sql is changed - file should be regenerated - OS - Windows & Linux Is something like this already available in FPC/Lazarus? Maybe there is better idea? Or I should create on my own solution, run it manually or connect using Project Options / Compiler Commands, Execute before? ---------------------------------------------------------------------- MarkMLl · 2021-01-04 18:33 I think that the standard answer would be to put the strings into resource files, but you'd get a far better class of response if you told people what OSes etc. you were expecting to run. MarkMLl ---------------------------------------------------------------------- ydd · 2021-01-04 18:39 Quote from: MarkMLl on January 04, 2021, 07:33:42 pmI think that the standard answer would be to put the strings into resource files I know about such solution, but idea with string consts - is much better, faster. Also if const is not used - it will not be compiled into executable Quote from: MarkMLl on January 04, 2021, 07:33:42 pmbut you'd get a far better class of response if you told people what OSes etc. you were expecting to run. updated, Windows & Linux ---------------------------------------------------------------------- MarkMLl · 2021-01-04 18:58 I'm sure that you noticed that there was a recent thread regarding multiline strings in standard FPC source, where it was made abundantly clear that the core developers didn't like the idea. While you could obviously use Perl etc. to parse HTML/SQL into custom Pascal source files, I'm pretty sure you won't get much official encouragement. My own preference would be to be able to embed SQL etc. into high- level language sources, and this is of course fairly standard in various development environments: but I'm very much in a minority. At the same time I have grave misgivings about introducing yet more complexity into the syntax, e.g. coopting double-quoted strings for multiline text. MarkMLl ---------------------------------------------------------------------- ydd · 2021-01-04 19:56 Quote from: MarkMLl on January 04, 2021, 07:58:23 pmI'm sure that you noticed that there was a recent thread regarding multiline strings in standard FPC source for me it is clear - that the way how multi-line string consts are implemented in FPC - is not good, for example in PHP - they are much better Quote from: MarkMLl on January 04, 2021, 07:58:23 pmMy own preference would be to be able to embed SQL etc. into high-level language sources, and this is of course fairly standard in various development environments I agree. Also important is syntax highlight, and for html - highlight that closing tag is missing main reason why I decided to move sql & html to external files - is highlight ---------------------------------------------------------------------- Rainbow6 · 2021-01-05 17:51 Quote from: MarkMLl on January 04, 2021, 07:58:23 pmMy own preference would be to be able to embed SQL etc. into high-level language sources, and this is of course fairly standard in various development environments: but I'm very much in a minority. Hi Mark, you mean something like a SQL pre-processor with „EXEC SQL“? That would be great - I‘m using this every day with RPG, and it is so much easier for database access than any API can be. If there would be any effort to implement something like that, I would be glad to participate - even when I‘m not the best Pascal programmer, I can help with standard syntax or docs. Kind regards, Daniel ---------------------------------------------------------------------- marcov · 2021-01-05 17:58 Quote from: ydd on January 04, 2021, 07:27:09 pmMaybe there is better idea? Yeah, use resources. A single file to constant is available as bin2obj and/or data2inc. So then you either have to expand those to support multiple files, and find some way to rerun them each time. But as said, just use resources, that is what they are meant for. ---------------------------------------------------------------------- Handoko · 2021-01-05 18:25 Quote from: ydd on January 04, 2021, 07:27:09 pmOr I should create on my own solution, run it manually ... I had similar problem too, not HTML nor SQL format but graphics files. The graphics files needed to be compiled into the binary but they're frequently changed when developing the program. I did not use TImageList because those images are different in sizes. So I wrote a module to convert binary files into hexstring and the opposite. Then I wrote a small tool to convert any image I select to const hexstring in Pascal format. That file was loaded as a normal unit in the main project, so I can simply recompile the project to refresh the images that are 'hardcoded' in the binary. In your case, you do not need to convert the data to hexstring. You can simply write the tool to convert the data to a Pascal format file. I did not consider using resources because my way is simpler than using resources. I meant I do not need to remember which files need to be refreshed on the project setting. The downside is I had to spend some time for writing that function but that was good for learning. ---------------------------------------------------------------------- MarkMLl · 2021-01-05 19:43 I both sympathise with OP- since after all it's his project and he understands his workflow- and don't want to upset the core developers. I think that if I were doing this I'd put SQL queries etc. in the source demarcated by something that the compiler would tolerate, and write a preprocessor to extract stuff from the original files into resource files without attempting to change the original. Based on one of the wiki examples: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i procedure exampleproc;var  Image: TImagebegin  Image := TImage.Create;  Image.Picture.LoadFromLazarusResource('image'); // note that there is no need for the extension{$ifdef USERRESOURCE_image } The content of the image resource is defined here in arbitrary format. {$endif USERRESOURCE_image } end;  Obviously USERRESOURCE_image is never defined in the context of the Pascal compiler and IDE, it's there as a tag that an external preprocessor can recognise. Frankly I'd prefer it if there were some properly-agreed here-document mechanism, or at least an agreed $directive that could be used to tag stuff for an out-of-IDE preprocessor. MarkMLl ---------------------------------------------------------------------- ydd · 2021-01-19 02:18 Quote from: MarkMLl on January 05, 2021, 08:43:35 pmI think that if I were doing this I'd put SQL queries etc. in the source demarcated by something that the compiler would tolerate, and write a preprocessor to extract stuff from the original files into resource files without attempting to change the original. Based on one of the wiki examples: I like your idea very much, thanks! And already implemented simple parser. I will test it more for real usage. And post here the results! ---------------------------------------------------------------------- MarkMLl · 2021-01-22 21:31 I can't come up with a better solution than {$ifdef USERRESOURCE_image } etc., since even if we were to ask the developers for a directive that identified a block of "here-document" text it would- from their POV- be equivalent to an $ifdef so there is really very little point. Marco (or anybody else still reading): what are the restrictions on the token that follows $ifdef, i.e. length and acceptable characters? Is there anything that can appear in that token, for example <> or {} characters, that can't easily be set by a $define etc. making certain sequences a safe choice for external preprocessors? MarkMLl ---------------------------------------------------------------------- lucamar · 2021-01-22 22:11 Quote from: MarkMLl on January 22, 2021, 10:31:45 pmMarco (or anybody else still reading): what are the restrictions on the token that follows $ifdef, i.e. length and acceptable characters? Is there anything that can appear in that token, for example <> or {} characters, that can't easily be set by a $define etc. making certain sequences a safe choice for external preprocessors? IIRC, the token must be a valid Pascal identifier, precisely because it has to be setable by a {$define...} (and I guess also to simplify parsing). ---------------------------------------------------------------------- MarkMLl · 2021-01-23 09:40 Quote from: lucamar on January 22, 2021, 11:11:33 pmIIRC, the token must be a valid Pascal identifier, precisely because it has to be setable by a {$define...} (and I guess also to simplify parsing). Thanks for that, but OTOH the classic preprocessor directives (until declared() came along) were broadly outside the scope of Pascal itself... I've had fun in the past getting code working which had to compile with two different compilers which had completely different directive forms. Whatever, "make it a Pascal identifier" sounds fairly safe and unambiguous. MarkMLl