Skip to content
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

Add field path to custom condition functions #1159

Open
simonolog opened this issue Apr 25, 2024 · 2 comments
Open

Add field path to custom condition functions #1159

simonolog opened this issue Apr 25, 2024 · 2 comments

Comments

@simonolog
Copy link

Consider this blueprint situation:

  • replicator field
  • set with a select field and another replicator
  • within the nested replicator is a set with a text field
  • the text field should be shown or hidden based on the input of the select field in its "parent" set
    • this is currently not possible!
  • so far we can refer to either fields on the same "nested level" or on the root blueprint level (via the root keyword) (see here)

field_conditions

This is clearly a case for a custom condition function. However, so far custom condition functions get the following parameters: params, target, targetHandle, values, root, store, storeName, which still does not give any indication on where the current field would be in a nested structure.

Looking into the code it should be possible to pass on the field path (so the information as to where the currently observed field is) to a custom condition function, so I could add my own logic and consider every (upwards) relation. For the example above that would be pagebuilder.0.nested_replicator.0.inner_text_field. Using the store or the root object, this would allow me to access whatever level I would like to consider.

@duncanmcclean
Copy link
Member

Have you seen statamic/cms#9385?

@simonolog
Copy link
Author

Have you seen statamic/cms#9385?

Yes I had seen it, but actually forgot about it (fun fact: it was opened by one of my team members 🙈😄). Anyway, the approach in statamic/cms#9385 only covers the "parent" case, while the approach of passing on the complete field path would allow for more than just one level up.

I mean, there would be nothing wrong with adding both if you'd ask me. The parent keyword would be more accessible and usable for simple field conditions, while adding the field path would extend the possibilities of custom functions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants