-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pipelining inside expressions #84
Comments
The things we come up with as humans writing template files. 😆 So yeah, the parser is probably failing on the first version. The second one, though, looks correct (I use blocks and yields a lot in our projects). What's the error? Does it fail on the first line or the second? Does the label variable contain the translated content? Also, you may want to try the plain old function invocation syntax which should work inside the yield as As for the first version and making it work: I don't think I want to (sorry about that). 🙈 As a member on a team having to grasp that statement… it doesn't look very readable. Add to that, that as you've written it the parser couldn't easily distinguish between when the pipeline ends and the next parameter begins (yes, the next parameter is a Just to be clear on who I am: I try to help people out with syntax and questions but haven't actually done any work on the engine (parser, lexer etc.) and I always defer to José. Sorry about that. |
edit:
Even if this works this once again brings the inconsistency in template writing. |
I stand by my comment. Having written a lot of templates I really really don't want to make the first version work. There's just too many things going on. With #89 you will also be able to break up the yield into multiple lines and put |
Even though that you don't like the translate version example... there is the same issue if one want's to use "default" in pipelinig fashion. e.g I'll say it here again like in another issue. This is the inconsistency with pipelinig that should be fixed. |
I see your point. I'll put it on the list. The problem that I see there is that it'll probably blow up even if I make the command understand pipelining. Just out of curiosity, is this just the example or wouldn't you be able to use Go's default return value of an empty string when accessing non-existant map keys? 🤔 I'll start with a failing test case and then we can iterate on that. Maybe it's worth it to drop the prefix version of pipelining ( |
Below are 4 examples and before reading an answer try to figure out which ones should work.
Answering the 2nd question Now for the trick question: I'd say that also test2 should work as it has a default value (e.g there should be no need for an isset inside a block, and or |
i'd like to use pipelinig inside a yield expression to pass a translation to a block
{{yield inputField(id="email", name="email", type="email", label="login.form.label.email"|T:"Email",map(),"account", icon="fa-envelope", required=true)}}
the parser seems to die inside "label"
I have also tried to use alternate syntax:
{{ label := "login.form.label.email"|T:"Email",map(),"account"}}
{{yield inputField(id="email", name="email", type="email", label=label, icon="fa-envelope", required=true)}}
which also seems to not work. (it reports the same error)
The text was updated successfully, but these errors were encountered: