Is there anyway to use only Mustache syntax in Ractive templates?
ceremcem opened this issue · 7 comments
Description:
Lately I'm using Ractive to generate C source code on the server side and it went well so far.
Since every line, struct and function call counts while developing for an embedded platform (microcontroller), it becomes an crucial requirement to write the application code just as much as needed in the first place. That's why it might be an advantage to generate C source code with Ractive templates and provide a configuration data for generating necessary code for different scenarios, rather than trying to get the same thing by C preprocessor.
At this point, it would be handy to encapsulate all Ractive activities inside Mustache's, so it wouldn't likely to interfere with the target language.
Is it possible to initialize component instances with Mustache's and restrict anything outside Mustache's?
Versions affected:
All.
Platforms affected:
All.
Reproduction:
N/A
I'm not 100% sure what you're asking here, but it sounds like text-only mode? Where the parser is supposed to read direct text between mustaches and only parse mustache content. I think there are some outstanding whitespace issues with that that may be avoided to some extent by enable preserve whitespace. Is there something beyond that that you need the parser to do?
Unrelated, have you seen zig? It bills itself as a cleaned-up C, where one of the biggest warts is the completely unrelated preprocessor language, which is replaced by compile-time evaluation. It's probably not in any shape for production and may not have a live llvm backend for your arch, but I think it's going to be interesting for the embedded space.
Yes, I'm talking about text-only mode. I never tried initializing a component in text-only mode, that's why this confusing idea came out. What I understand is there is no way to initialize a component in text-only mode? That reproduction says the same.
I took a look at zig. It might be a nice language for it's own domain, but I didn't quite get the benefits. If I had a chance to move to another language (for embedded applications), DLang would be my choice. I'm looking forward to build my first application with DLang in a new project.
However, my case is a little bit more unfortunate. I really don't prefer C because it's too verbose, it doesn't support some other programming paradigms (OO, functional programming) that may help (and is helping for me) to build a maintainable application with reusable code. However, C is practically the only language in embedded world. Moreover, I've been using a RTOS that helps me abstracting some difficulties. That RTOS (ChibiOS) heavily uses C preprocessor to avoid function, struct and variable declaration because, again, every abstraction counts. However, the RTOS' abstractions are not enough and prevents us from writing reusable code.
I might nearly use an object oriented approach with pure C by abusing structs ("every struct is an instance" approach) but that bloats the application size, so I can't do it either.
Also, writing an application isn't the end of work. We may need support at any time, so we may need to share our code in the forum. If I pick another language, or some "auto generated" C code output of another language, things will get hairy. (Trust me, I'm a LiveScript user.)
So I decided to use a nice preprocessor language in in conjunction with C. Here I thought I could use Ractive.
It might sound like re-inventing C++ (the version back in the C-with-classes days), that's okay. I may want to generate Ractive templates from Ractive templates which in turn generate C codes, so it might sound like re-inventing Lisp. Those might not be Ractive's goal, that's also okay. But I feel like Ractive will do that job just fine with a few additions, like #3338 and #3346 (this) one.
I think I understand what you're trying to do a little better now. It sounds like we would need a way to include a component as a mustache rather than a tag. There's not really a clean way to differentiate between a tag and a component at parsing, as they look the same and the component is looked up at render time.
You could work around this issue by dropping your components into partials e.g. c source here {{>component}} more c source and then parsing the component partial without text-only mode as <mycomponent ... />.
I thought about this a little more, and was wondering how much of a component tag do you need to support? Do you need to create links or just pass along plain old sets? I could put together a partial function that would create the relevant template for you to do something like {{>component('name', { value: whatever, size: 10 + theSumOfSomeStuff })}} pretty easily. I'm guessing you don't need to link in any data for twoway binding if you're using this to render text, so that might be enough, though I could add link mapping argument to that as well without too much trouble, I think.
As you correctly guessed, there is no need to support twoway binding in such a use case and that function-like syntax would be awesome. Only maybe the count of parentheses reduced?
Here's an example of what that component partial helper would look like. There's a console log at the end that shows that it works in textOnlyMode, though you'd still need to process > and <, apparently.
That is more than enough. Thanks a lot!