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

BUG: Property convert not used when accessing values like data.image in eel #77

Open
mhsdesign opened this issue Nov 14, 2023 · 3 comments

Comments

@mhsdesign
Copy link
Contributor

mhsdesign commented Nov 14, 2023

This patter doesnt work currently

  properties:
    image:
      type: ImageInterface
      ui:
         showInCreationDialog: true
  options:
    template:
      properties:
        imageCaption: '${data.image.copyrightNotice}'

as data.image is not converted. The dump looks like:

array(2)
  '__identity' => 4567890,
  '__type' => 'ImageVariant' 

related: #61

version: 2.x

@lorenzulrich
Copy link
Contributor

@mhsdesign Thanks for adding this issue. I was using version 2.1 when I tested this.

@mhsdesign
Copy link
Contributor Author

mhsdesign commented Feb 18, 2024

I found a (non breaking) solution for this. That will be core part of Neos9 and i know how to back-port it ;)

Using the raw data from the neos ui which is not deserialised was a mistake as shown by this example.
Im not sure if it would be wise to just change data.* to be always deserialised as this can be really breaking for some cases where now manual deserialisation was implemented.

Instead non breaking solution would be do deprecate data and introduce something like a new namespace like elements.* or props.* or even directly allow the elements as first level variable like image and myOtherElement which will always hold the deserialised values.

For simple types like strings data.myString will equal myString but for objects this will show a difference, as you will be able to write ${data.image.copyrightNotice}.

Neos 9 will make internally a distinction between "property"-like elements and "reference"-like elements edit: no we decided differently, so nothing speaks against just exposing it always as myReferenceElement or myObjectElement. What do you say?

The only downside i can imagine is that maintaining a template might not be that easy if you cant simply string replace all data.foo strings in yaml as you have to be more careful, or also detecting usages might be harder for the eye?

@mhsdesign
Copy link
Contributor Author

mhsdesign commented Mar 15, 2024

@grebaldi and me opted in for elements.image and will deprecate data.*

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