-
-
Notifications
You must be signed in to change notification settings - Fork 328
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
Disable lexing for specific fields #840
Comments
I tried that but couldn't find any easy way for now. We could either have a new markup like: foo: <<<'ESCAPED' ... ESCAPED or something like that and then in the lexer/parser bypass that expression. An alternative which is already available is to leverage the faker providers to return the string you want which won't be evaluated |
That's the only existing 'solution' I can find so far, It looks to me as reversing the problem though; having to add Alice/Faker directives to all the things I don't want Alice or Faker to touch. In both cases I would still have to alter all the fields the lexer raises exceptions for, which would still mean more then a thousand cases. |
Unfortunately yes. It was pure luck that it was working fine in 2.x :/ |
How can I escape everything in general? I have a string like:
I tried
|
You could put your string as a returned value of a faker data provider for now |
An other workaround, which worked (for me):
what didn't work was (not even with different levels of escaping the backslash):
|
@floplus I would open a dedicated issue for that one. It looks like a bug that can be dealt with. Also I think regardless of the progress of that issue meanwhile we could add a doc entry for it |
We also need to disable the lexer when a field contains the $ symbol |
@tifabien what do you mean? |
@theofidry oops I was to vague sorry. I meant that we got also an error when in your fixture you set for example something like
|
|
Thanks @theofidry, I'll escape it but is it something new with alice 3.x because I didn't have to escape it with the previous 2.x version? |
Then it's a user-land BC break and this could be fixed. I think it's reasonable to expect |
To use an array in a json string, you can use this workaround.
|
I'm currently also having issues with strings being lexed when they shouldn't. Adding them all as What is the currently recommended way to solve it? Is there any documentation about it anywhere? How can people help? |
@yakobe most strings should be escapable with That said there is a release coming where alice just let the string be a string if it's an invalid expression (instead of currently bailing out) |
@theofidry that would be awesome. Any idea when it is due? Or is there a pull request i can follow or something? |
I need to test out #938 and then it will be ready to tag |
Thank you! Solves my problems perfectly 👍. |
any updates @theofidry ? it would be nice to get it merged |
I’ll check it out once I’m back from holidays.
…On Fri 26 Apr 2019 at 08:30, Tito Miguel Costa ***@***.***> wrote:
any updates @theofidry <https://github.com/theofidry> ? it would be nice
to get it merged
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#840 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABHPVAN3UKX3OMP2BFTWOZLPSI5KFANCNFSM4EIBJLZA>
.
|
Is that out? I'm still getting the problem with something like
It works with
But this means escaping (with <identity()>) every string in my generated files. So simply loading the string when it fails would be preferable. |
I first attempted that but it turned out it was too flimsy: a lot of people ended up with strings where they did not expect it because the error was silenced. There is currently no proper escaping. The identity can work to some extend, but there is a few cases e.g. with nested calls that might not work. In any case, I think it's something that would be better solved with #998 |
this feature would be really important, because escaping all links in a multiline markdown text can't be the right solution.
an idea would be to have an exclude list for such things. fiddeling around with the yaml format feels counterproductive for me. having a separate file like: App\Entity\Item:
- text or setting it in php in the fixture loader could be a solution. |
Maybe you can achieve it via the parameters which are used as is and not parsed |
Yes, it's _possible_, but using parameters to achieve this is terribly
messy and convoluted. Or maybe I'm missing something, can you provide an
example of how to do that, one that
The inability to escape field values is the biggest reason I can't use this
bundle, so would be thrilled if that were added.
Thanks.
…On Mon, Aug 10, 2020 at 3:44 PM Théo FIDRY ***@***.***> wrote:
Maybe you can achieve it via the parameters which are used as is and not
parsed
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#840 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEXIQMHAJJH7UMB746PJ5DSABEYRANCNFSM4EIBJLZA>
.
|
When loading the fixtures, you can always pass objects & parameters, their keys making them accessible from the fixtures. I agree it's not the best experience for sure, and if you use it extensively maybe a loader decorator could help to make your usage simpler. I explored a few ways, but I couldn't come with a really robust an nice way, hence I why I think #998 is really the way forward |
#998 is not really helpful, if i would like to use php for fixture definition i simply would stick to doctrine fixtures (i use alice for "real" fixtures and also for development fixtures). the main benefit using alice for me, next to have a faker integration, is that i can let non programmers write some fixtures. it is unhandy enough that i have to use in the end it looks like that: App\Item:
item_template (template):
visible: false
rank: 50
item_1 (extends _item_template):
__construct:
name: myname
from_date: '<date_create_immutable(2018-01-01)>'
client: '@client_7'
visible: true
text: >
lorem ipsum
__calls:
- addImagesFromArray:
-
-
name: headline
file: screenshot_website.jpg
-
name: headline
sub_headline: subheadline
file: anotherfile.jpg is quite ugly to read for a non developer, the double array of the much cooler would be something like the following (just wip thought not a real final solution. should only line out what i mean) config.yaml or config.php (does not matter as the config has to come from a develeoper) App\Item:
map_fields_to_constructor: true
unparsed_fields:
- text
- name
- visible
call_mapping:
images:
method: addImagesFromArray
xyz: #some kind of parameter mapping, where i can define the array/data defined in `images` should be used as one parameter, or each image should be its own parameter,... items_fixture.yaml App\Item:
item_template (template):
visible: false
rank: 50
item_1 (extends _item_template):
name: myname
from_date: '<date_create_immutable(2018-01-01)>'
client: '@client_7'
visible: true
text: >
lorem ipsum
images:
-
name: headline
file: screenshot_website.jpg
-
name: headline
sub_headline: subheadline
file: anotherfile.jpg |
Still not possible to disable string parsing/lexing? |
Can you point me to the documentation on how to do that? I'm still not following, and not being able to store values with special symbols ($, %, etc.) is a show-stopper. |
I'm trying to upgrade from v2 to v3 due to an issue with being unable to escape a string value that was interpreted as a variable. However I now find myself in the exact opposite situation of having to escape all the html tags, percent signs, brackets etc. For some of my classes this is simply not viable as it would mean i would have to add thousands of backwards \ slashes to my fixtures and falling back to v2 would be my only real option.
The only solution I see is to disable the parsing/lexing of certain fields of particular classes which I know will never hold variables functions or references Alice should worry about. The problem is that I have no idea how to achieve this or if it's even remotely possible.
Any ideas or help would be greatly appreciated
The text was updated successfully, but these errors were encountered: